Telerik UI Padding-Oracle Bug Chained to Unauthenticated RCE — Public Exploit Released

A TantoSec proof-of-concept turns an AES-CBC "padding oracle" in Telerik UI for ASP.NET AJAX into unauthenticated remote code execution — but only against applications in a specific non-default configuration, and Progress patched the chain in July. There are no confirmed reports of exploitation in the wild.

Security firm TantoSec has published a working exploit chain targeting vulnerabilities in Telerik UI for ASP.NET AJAX that can allow an unauthenticated attacker to execute remote code on the server hosting a vulnerable application.

Progress Software patched the flaws in July, and exploitation requires a non-default configuration — but the release pairs a detailed write-up with a ready-to-run tool and two payloads, putting a complete attack path in public hands for the first time.

The underlying flaws are not new. Progress shipped the fix in version 2026.2.708 (2026 Q2 SP1) on July 8 and published the CVEs and advisory on July 22.

What changed on September 7 is the disclosure of the method and the tooling: TantoSec's Marcio Almeida walked through the full chain and released a command-line tool, telerik-rau-exploit, along with two mixed-mode DLL payloads — one that writes a web shell to disk and one that runs entirely in memory.

The chain affects the RadAsyncUpload file-upload control in versions 2010.1.309 through 2026.2.519, according to Progress's advisory; 2026.2.708 and later are fixed.

The most serious of the bugs, an unguarded type-resolution flaw tracked as CVE-2026-13181, carries a CVSS score of 8.1 ("high"); its "high" attack-complexity rating reflects the configuration prerequisites described below rather than any difficulty in exploitation once they are met.

Running an affected version is not enough to be exploitable. TantoSec says the chain has "preconditions that are not met by a default installation": a page must render a RadAsyncUpload control whose server-side handler reads the upload result, and the application must be configured with an explicit, non-default encryption key for the control — which, in a twist, is a setting Telerik recommends as hardening. Sites on an affected version without both conditions are not exploitable through this chain.

Where those conditions hold, the payoff is code execution with the privileges of the IIS application pool. The entry point is a padding oracle (CVE-2026-13182): because the control encrypts its client-side state with AES-CBC and no integrity check, the server responds differently to tampered data depending on whether the decrypted bytes have valid padding or merely fail to parse as JSON.

That difference lets an attacker decrypt — and, with a technique TantoSec built around the control's fixed encryption seed, forge — the encrypted upload configuration without ever knowing the key.

The same forgery allows the attacker to name an arbitrary .NET type, which the control resolves without an allowlist (CVE-2026-13181) and deserializes into a gadget that loads a DLL from a location the attacker controls.

The uploaded DLL is a mixed-mode assembly that runs native code as soon as it loads. It is not instant: TantoSec's end-to-end run took roughly 127,000 oracle requests — about an hour against a lab target, and longer against a rate-limited server.

If the application hides detailed error messages, the oracle can still be read through response timing, a variant tracked as CVE-2026-13183.

There are no confirmed reports of the 2026 flaws being exploited in the wild, and none appears in CISA's Known Exploited Vulnerabilities catalog as of September 7.

One attack-surface-management vendor, IONIX, states on its site that it is "tracking ongoing exploitation attempts," but it gives no dates, volumes, or other specifics, and does not distinguish exploitation from ordinary internet scanning of the handler.

The component itself has a long history of real-world attacks — but through older bugs, not these. A 2019 deserialization flaw in the same handler, CVE-2019-18935, was chained with a 2017 encryption weakness and exploited by ransomware crews and nation-state actors, including in a 2022 breach of a U.S. federal agency, and was still being exploited as recently as 2025.

That track record is why an unauthenticated code-execution path in this handler draws attention, even though the new bugs have no confirmed exploitation.

Two further points bound the story. Progress's July bulletin actually covers two separate attack chains: the RadAsyncUpload chain TantoSec detailed, and a distinct remote-code-execution chain in the RadPersistenceManager and RadDockLayout components (CVE-2026-13185, -13186 and -13190), credited to CODE WHITE's Markus Wulftange and Progress, for which no public exploit has been released.

And within the RadAsyncUpload chain, a fourth bug involving a predictable default key (CVE-2026-13184) applies only to an alternative attack mode the released demonstration did not use.

What to do

Upgrade to Telerik UI for ASP.NET AJAX 2026.2.708 (2026 Q2 SP1) or later, which replaces the flawed AES-CBC scheme with authenticated encryption and closes the entire chain.

Progress calls upgrading its only official recommendation and warns that a stronger custom key does not help, because the oracle never needs the key.

For sites that cannot upgrade immediately, Progress points to several interim steps:

• Set customErrors to RemoteOnly or On, which forces an attacker onto the slower timing-based variant.
• Disable the upload handler entirely (Telerik.Web.DisableAsyncUploadHandler set to true) if RadAsyncUpload is not required.
• Remove any custom encryption key so the control falls back to the ASP.NET machine key with AES and HMAC, or generate strong machine keys manually rather than at runtime.

Because Progress warns that successful exploitation "leaves no obvious trace in standard ASP.NET error logs," defenders should hunt behaviourally rather than for error signatures: the IIS worker process (w3wp.exe) spawning cmd.exe, a new or unexpected .aspx file in the web root, or a mixed-mode DLL written under the upload control's temporary folder or App_Data.

TantoSec reported the issues to Progress on May 22; the fix shipped on July 8, and the CVEs followed on July 22. Almeida credited colleague Justin Steven for the timing-oracle variant.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.