Telerik’s Padding Oracle Just Became an RCE — And the Exploit Is Public
- The Mess: Telerik UI for ASP.NET AJAX now has a public working exploit chain turning a padding oracle into unauthenticated remote code execution. The bugs were patched in July. The exploit dropped today.
- The Damage: A vulnerable RadAsyncUpload deployment can let an unauthenticated attacker execute code with the privileges of the IIS application pool.
- The Fix: Upgrade to Telerik UI for ASP.NET AJAX 2026.2.708 or later and investigate exposed systems if they were running an affected version.
The patch isn’t new.
The exploit is.
Progress fixed a chain of vulnerabilities in Telerik UI for ASP.NET AJAX in July. On September 7, security researchers at TantoSec published a working exploit, a technical breakdown and the telerik-rau-exploit tool.
That changes the risk calculation.
The affected component is RadAsyncUpload, a file-upload control used by ASP.NET applications. Vulnerable versions range from 2010.1.309 through 2026.2.519. Version 2026.2.708 fixes the relevant issues.
The Oracle Comes First
The chain starts with CVE-2026-13182, a padding-oracle vulnerability.
RadAsyncUpload encrypted client-side state using AES-CBC without sufficient integrity protection. The server then responded differently depending on whether manipulated ciphertext failed during decryption or during JSON parsing.
That tiny difference becomes an oracle.
An attacker can repeatedly query the application and use those responses to recover information about protected metadata without knowing the encryption key.
And once the attacker can forge that metadata, the next bug becomes useful.
Then .NET Gets Involved
CVE-2026-13181 affects the handling of AsyncUploadTypeName.
The forged upload metadata can influence type resolution and cause Telerik to resolve an attacker-controlled .NET type. Progress rates the vulnerability as high severity, and its advisory confirms that it can lead to remote code execution.
The chain can then be used to load an attacker-controlled DLL.
The result is code execution under the privileges of the IIS application pool.
Not a login bypass.
Not a reflected XSS.
Server-side code execution.
There Is a Catch
This isn’t a universal “all Telerik installations are instantly owned” situation.
The public exploit requires conditions that aren’t present in a default installation.
The vulnerable application needs to use RadAsyncUpload, and the specific attack chain requires the application to meet additional configuration conditions. TantoSec’s demonstration also required a large number of oracle requests — roughly 127,000 requests in the researchers’ lab, taking about an hour before rate limiting.
That matters.
But it doesn’t make the bug harmless.
Internet-facing ASP.NET applications with old Telerik components are exactly the kind of forgotten infrastructure that tends to remain exposed long after the development team has moved on.
The Timing Variant Makes It Worse
There is another related issue: CVE-2026-13183.
If detailed error messages are hidden, timing differences can still leak whether the manipulated data passed one stage of processing or another.
That creates a timing oracle.
The cryptographic oracle doesn’t disappear just because the error messages do.
Progress fixed the broader Telerik security release with version 2026.2.708, which addresses CVE-2026-13181 through CVE-2026-13190 and additional security issues.
What Defenders Should Look For
The public exploit means patching is only half the job.
Progress warns that successful exploitation may leave no obvious trace in standard ASP.NET error logs. Security teams should therefore look for suspicious behaviour around IIS and the upload subsystem.
Particularly interesting signals include:
w3wp.exespawningcmd.exeor other unexpected processes,- unexpected
.aspxfiles appearing in the web root, - suspicious DLLs written into upload-related temporary directories,
- unusual requests targeting the RadAsyncUpload handler,
- outbound connections from the IIS worker process.
These indicators matter because an attacker who reaches code execution doesn’t need to stop at the vulnerable application.
The IIS server becomes the beachhead.
Patch Status
Progress released the fix on July 8, 2026, with the security advisories following later in July. The patched version is:
Telerik UI for ASP.NET AJAX 2026.2.708
Progress recommends upgrading rather than relying on configuration changes alone.
For systems that cannot be upgraded immediately, Progress provides mitigations including disabling the async upload handler where it isn’t required and changing affected cryptographic configuration. But these should be treated as temporary measures, not a substitute for the patched release.
Bugstoday Opinion
This is exactly the kind of vulnerability that gets dangerous after the vendor ships the patch.
The CVEs have existed since July.
Most organizations probably didn’t rush to investigate them.
Now there is a working exploit, a technical write-up and tooling that turns a collection of cryptographic and type-resolution mistakes into a practical attack chain.
That’s the moment defenders need to stop asking:
“Is this CVE being exploited?”
and start asking:
“Why would we wait until it is?”
Telerik’s history with RadAsyncUpload already includes serious exploitation of older vulnerabilities. The new chain doesn’t have confirmed exploitation in the wild yet — but the attack path is now public.
The window between patched and weaponized just got smaller.
Patch it before somebody turns the PoC into a scanner.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- Progress Telerik — Critical Security Bulletin: Multiple Vulnerabilities Chained to Remote Code Execution
- Progress Telerik — CVE-2026-13181 advisory
- Progress Telerik — CVE-2026-13182 advisory
- Progress Telerik — Release 2026.2.708 security fixes
- TantoSec — technical research and public exploit
- The Hacker News — September 7, 2026 technical reporting




