Public Telerik RadAsyncUpload Exploit Chains Padding Oracle to Unauthenticated RCE

A working exploit chain targeting Progress Telerik UI for ASP.NET AJAX was released publicly on September 7, 2026, turning several RadAsyncUpload weaknesses into unauthenticated remote code execution.

Security firm TantoSec published the command-line tool telerik-rau-exploit alongside two mixed-mode DLL payloads. One writes a web shell to the target server, while the other executes entirely in memory.

The attack is not universal. It requires a particular, non-default application configuration in addition to a vulnerable Telerik version. However, where those conditions exist, an unauthenticated attacker can recover or forge encrypted upload metadata, select an arbitrary .NET type, and cause IIS to load malicious code.

Progress fixed the chain in Telerik UI for ASP.NET AJAX 2026.2.708, also identified as 2026 Q2 SP1. The release shipped on July 8, before the CVEs and advisory were published on July 22.

Exploitation Requires Three Deployment Conditions

Progress identifies Telerik UI for ASP.NET AJAX versions 2010.1.309 through 2026.2.519 as affected by the RadAsyncUpload chain. Version 2026.2.708 and later contain the fix.

NVD records CVE-2026-13181, CVE-2026-13182, CVE-2026-13183 and CVE-2026-13184 more broadly as affecting releases before 2026.2.708.

Running a vulnerable version is not enough for the released exploit. According to TantoSec, all three of these conditions must be present:

• The application renders a RadAsyncUpload control.
• Server-side application code reads or otherwise processes the upload result.
• The control uses an explicitly configured, non-default encryption key.

The custom-key requirement is notable because Telerik has recommended custom encryption settings as a hardening measure. Simply rotating that key or replacing it with a stronger value does not stop this attack: the padding oracle operates without learning the key itself.

Applications that lack either of the required application-level behaviors are not exploitable through the published RadAsyncUpload chain. Administrators should therefore examine actual control use and configuration rather than relying exclusively on package inventories.

The attack also generates substantial traffic. An end-to-end laboratory run required approximately 127,000 oracle requests and took around one hour. Rate limiting or slower production infrastructure could extend that period, creating a possible detection opportunity.

How the Padding Oracle Becomes Code Execution

RadAsyncUpload protects client-side state with AES in CBC mode but does not add an integrity mechanism capable of detecting ciphertext manipulation before processing.

When a server receives modified encrypted metadata, its behavior differs depending on the outcome. Data with invalid cryptographic padding follows one path, while data that passes padding validation but fails during JSON parsing follows another.

That distinction creates a padding oracle. By repeatedly altering ciphertext and observing the application’s responses, an attacker can infer information about protected upload metadata.

Disabling detailed error responses does not necessarily remove the signal. Processing-time differences may still reveal whether padding was accepted, producing the timing-based oracle tracked as CVE-2026-13183. TantoSec credited Justin Steven with this variant.

TantoSec also developed a method using the control’s fixed encryption seed to forge an encrypted upload configuration without recovering the configured encryption key. The resulting configuration can set an attacker-selected .NET type.

RadAsyncUpload resolves that type without enforcing an allowlist. The object is then deserialized into a gadget that retrieves and loads a DLL from an attacker-controlled location.

The published payloads are mixed-mode assemblies containing managed and native components. Native code runs as the DLL is loaded, with the identity and permissions of the IIS application pool. The attacker may consequently access application files, secrets and other resources available to the worker process.

Four CVEs Form the Released RadAsyncUpload Chain

The disclosed weaknesses cover the cryptographic oracle, metadata forgery and final code-execution stage.

Vulnerability	Function in the attack	CVSS
CVE-2026-13181	Attacker-controlled AsyncUploadTypeName processing permits unsafe .NET type resolution and RCE	8.1
CVE-2026-13182	Distinct decryption and JSON-processing failures expose an AES-CBC padding oracle	7.5
CVE-2026-13183	Response-time differences preserve the oracle when detailed errors are hidden	7.5
CVE-2026-13184	A predictable default integrity key can enable metadata forgery in an alternative attack mode	7.5

CVE-2026-13181 carries the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Its high attack-complexity rating reflects the necessary deployment conditions, rather than a need for authentication or user interaction.

CVE-2026-13182 and CVE-2026-13183 both have the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. They provide information-disclosure primitives that support later manipulation.

CVE-2026-13184 has the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. It applies when Telerik.Upload.ConfigurationHashKey is missing and machineKey has not been explicitly configured, potentially leaving upload-metadata integrity dependent on a predictable default key. This alternative route was not used in the released demonstration.

A Separate Telerik RCE Chain Also Received Fixes

Progress’s July bulletin also addressed an independent unauthenticated RCE path affecting applications that use cookie-based storage in RadPersistenceManager or RadDockLayout.

That chain includes CVE-2026-13185, CVE-2026-13186 and CVE-2026-13190. All three have CVSS scores of 8.1 and the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

CVE-2026-13185 involves deserialization of attacker-controlled cookie content. Exact affected-version information, CWE classifications and technical records for CVE-2026-13186 and CVE-2026-13190 are not known.

The research was attributed to CODE WHITE researcher Markus Wulftange and Progress. No public exploit for this second chain has been released.

Patch First, Then Hunt for IIS-Level Indicators

Progress’s official recommendation is to install Telerik UI for ASP.NET AJAX 2026.2.708 or later. The corrected implementation replaces the vulnerable CBC construction with authenticated encryption and closes the full RadAsyncUpload path.

Where immediate deployment is impossible, Progress lists several temporary measures:

1. Set ASP.NET customErrors to RemoteOnly or On. This hides explicit error differences, although attackers may still use the slower timing oracle.
2. Set Telerik.Web.DisableAsyncUploadHandler to true if RadAsyncUpload is unnecessary.
3. Remove the custom upload encryption key, allowing the control to use an ASP.NET machine key with AES and HMAC.
4. Alternatively, configure strong machine keys manually instead of generating them at runtime.

These controls should be treated as interim risk reduction, not substitutes for the fixed release.

Standard ASP.NET error logs may not provide clear evidence of successful exploitation. Defenders should inspect endpoint, filesystem and web-request telemetry for:

• w3wp.exe launching cmd.exe or other unexpected child processes.
• New or modified .aspx files under an application’s web root.
• Mixed-mode DLLs appearing in RadAsyncUpload temporary directories.
• Unexpected DLL creation under App_Data.
• Sustained malformed requests to the RadAsyncUpload handler.
• Large request sequences consistent with roughly 127,000 oracle probes.
• Repeated encrypted-metadata failures or timing-oriented experimentation.

An in-memory payload may leave fewer filesystem artifacts, making worker-process behavior and network telemetry particularly relevant.

No Confirmed 2026 Exploitation, but Telerik Has KEV History

As of September 7, none of the 2026 Telerik vulnerabilities described here appeared in CISA’s Known Exploited Vulnerabilities catalog. There are also no confirmed reports that the new chain has been used successfully in the wild.

Attack-surface management company IONIX says it is tracking exploitation attempts, but has not provided dates, volumes or technical evidence separating targeted exploitation from routine scanning. The claim remains unverified.

Telerik’s upload component nevertheless has a documented exploitation history. CVE-2019-18935, a critical RadAsyncUpload deserialization flaw rated 9.8, entered CISA’s KEV catalog on 2021-11-03. U.S. federal agencies received a remediation deadline of 2022-05-03, with instructions to apply vendor updates.

That older vulnerability was used in ransomware campaigns and by nation-state actors, including in a U.S. federal agency breach in 2022. Exploitation reportedly continued into 2025. Those incidents do not demonstrate exploitation of the new CVEs, but they show that exposed Telerik handlers remain attractive targets.

Another vulnerability associated with Telerik and Progress, CVE-2026-8037, entered KEV on 2026-08-07. The public release of a complete RadAsyncUpload exploit now gives defenders a separate reason to inventory exposed controls and install 2026.2.708 without delay.