“The chain has preconditions that are not met by a default installation,” TantoSec’s write-up says — but when those preconditions exist, a publicly released proof-of-concept turns an AES-CBC padding oracle in Telerik UI for ASP.NET AJAX into unauthenticated remote code execution.
The technical chain: padding oracle to code execution
Security firm TantoSec published a full exploit chain on September 7 that combines an AES-CBC padding oracle with an unguarded type-resolution bug in the RadAsyncUpload control. The padding oracle (tracked as CVE-2026-13182) arises because the control encrypts client-side state with AES-CBC without an integrity check; servers respond differently when tampered data yields valid padding versus when it fails to parse as JSON. That side channel lets an attacker decrypt — and, using a technique tied to the control’s fixed encryption seed, forge — the encrypted upload configuration.
Forging the configuration enables naming an arbitrary .NET type, which the control resolves without an allowlist (CVE-2026-13181) and deserializes into a gadget that loads a DLL from an attacker-controlled location. The DLLs in TantoSec’s demonstration are mixed-mode assemblies that run native code immediately on load. A complete end-to-end run in the lab required roughly 127,000 oracle requests — about an hour on a permissive target and longer against a rate-limited server. If detailed error messages are suppressed, the oracle can still be read through response timing (CVE-2026-13183), credited in part to Justin Steven.
Scope, prerequisites, and limits
The chain affects RadAsyncUpload in Telerik UI for ASP.NET AJAX versions 2010.1.309 through 2026.2.519, per Progress’s advisory; version 2026.2.708 and later are fixed. Progress assigned CVE-2026-13181 a CVSS score of 8.1 ("high") but noted its "high" attack-complexity rating reflects configuration prerequisites rather than intrinsic exploit difficulty once those prerequisites are met.
- An affected version alone is not sufficient. TantoSec and Progress both emphasize two non-default requirements: 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 — a setting Telerik recommends as hardening.
- Where those conditions are absent, the RadAsyncUpload chain is not exploitable. A fourth bug (CVE-2026-13184) involving a predictable default key applies only to an alternative attack mode the public demonstration did not use.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogPatch, advisories, and public tooling
Progress shipped a fix in version 2026.2.708 on July 8 and published the CVEs and advisory on July 22. Progress’s official guidance: upgrade to 2026.2.708 or later, which replaces the flawed AES-CBC scheme with authenticated encryption and "closes the entire chain." Progress also warns that a stronger custom key does not help, "because the oracle never needs the key."
On September 7, TantoSec’s Marcio Almeida released a command-line tool, telerik-rau-exploit, plus two mixed-mode DLL payloads — one that writes a web shell to disk and one that runs entirely in memory — putting a complete attack path and working exploit code into public hands for the first time. Progress’s July bulletin also covers a separate RCE chain affecting RadPersistenceManager and RadDockLayout (CVE-2026-13185, -13186 and -13190) credited to CODE WHITE's Markus Wulftange and Progress; no public exploit for that chain has been released.
Interim mitigations and operational detection
For sites unable to upgrade immediately, Progress recommends specific interim steps: set customErrors to RemoteOnly or On (forcing the attacker onto the slower timing-based variant); disable the upload handler entirely (Telerik.Web.DisableAsyncUploadHandler set to true) if RadAsyncUpload is not required; or 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.
Progress warns successful exploitation "leaves no obvious trace in standard ASP.NET error logs," so defenders should hunt behaviorally for signs of compromise: 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.
What this means for technologists, procurement leaders, and defenders
- Technologists and security teams: prioritize upgrading to Telerik UI for ASP.NET AJAX 2026.2.708 or later; apply the interim mitigations where upgrade is delayed and hunt for behavioral indicators because log signatures may be absent.
- Procurement and enterprise IT: verify which deployed applications render RadAsyncUpload handlers that read upload results and whether non-default encryption keys were configured; these configuration details determine whether systems are exploitable.
- Defenders and incident responders: expect exploitation attempts to be noisy at the network and timing layers (hundreds of thousands of oracle requests) but quiet in standard ASP.NET logs; IONIX says it is "tracking ongoing exploitation attempts" but provides no dates or volumes.
One detail sharpens the risk calculus: the RadAsyncUpload handler has a documented history of real-world misuse. An older deserialization flaw, CVE-2019-18935, was chained and exploited by ransomware groups and nation-state actors, contributing to a 2022 breach of a U.S. federal agency and remaining exploited as recently as 2025. That record explains why an unauthenticated RCE path in the same handler draws attention even though 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.
The immediate, practical action is clear and narrow: apply Progress’s 2026.2.708 fix or, if you cannot, follow the prescribed mitigations and hunt for behaviorally anomalous activity. The broader question — whether public exploit tooling will prompt opportunistic scanning to turn into confirmed intrusions — is one defenders must answer with prioritized patching and active detection.
