## Overview

Progress Telerik UI for ASP.NET AJAX is a widely deployed enterprise UI component library, used by at least 14,740 verified companies across finance, IT services, government, and automotive sectors. The RadAsyncUpload control, which provides drag-and-drop file upload functionality, contains a chain of cryptographic and deserialization weaknesses that allow an unauthenticated remote attacker to achieve arbitrary code execution with IIS application pool privileges.

## The Vulnerability Chain

### CVE-2026-13182 — AES-CBC Padding Oracle (CVSS 7.5)

The RadAsyncUpload control encrypts client-side state using AES-CBC with no integrity check (HMAC). When the server decrypts a tampered ciphertext, two distinct error conditions occur: a CryptographicException on bad padding versus an InvalidOperationException on valid padding but invalid JSON. This differential — a "decrypt-versus-parse" oracle — allows an attacker to probe ciphertext bytes and recover the plaintext without knowing the encryption key. The oracle is exposed through two entry points: the async upload handler path (AsyncUploadHandler.GetConfiguration, which decrypts the _serializedConfiguration hidden field and passes it to JavaScriptSerializer.Deserialize) and the postback path (PlayClientState → AsyncUploadClientStateConverter, which decrypts per-file metaData blobs). The 2026.1.421 partial patch only wrapped the handler path in a unified try/catch, leaving the postback path unpatched and the oracle fully operational.

### CVE-2026-13183 — Timing-Based Oracle Variant (CVSS 7.5)

Discovered by Justin Steven of TantoSec, this variant exploits measurable timing differences between the two code paths: bad padding fails early, while good-padding-but-bad-JSON takes measurably longer. Even when customErrors is set to On or RemoteOnly to suppress distinguishable error responses, the timing differential persists. The attack uses the "Timeless Timing Attacks" technique (Van Goethem et al., USENIX Security 2020), racing two requests against each other in the same TCP packet so that the order of responses carries the timing signal independent of network latency. Demonstrated consistently across approximately 221ms RTT from Melbourne to us-east-1.

### CVE-2026-13184 — Predictable Default HMAC Key (CVSS 7.5)

When Telerik.Upload.ConfigurationHashKey is not explicitly set in web.config and machineKey is left at its default AutoGenerate setting, the upload metadata integrity protection falls back to a predictable default key. This enables attackers to forge protected upload metadata, including the TempTargetFolder path used in later exploit stages.

### CVE-2026-13181 — Unguarded Type Resolution / Deserialization RCE (CVSS 8.1)

The FileUploaded event handler's UploadResult property calls Type.GetType(obj.FileType) using the attacker-controlled AsyncUploadTypeName value without any allowlist or base-type constraint. The resolved type is then deserialized via JavaScriptSerializer with property values from the attacker-controlled SerializedData. The chosen gadget is System.Configuration.Install.AssemblyInstaller, whose Path setter calls Assembly.LoadFrom(path), loading an attacker-supplied mixed-mode DLL.

## The Sacrificial Block Technique

Because the AES-CBC IV is statically derived from Rfc2898DeriveBytes(password, SALT) and never sent with the ciphertext, the first plaintext block cannot be directly controlled. The exploit uses a "sacrificial block" technique: it decrypts the _serializedConfiguration from right to left via the oracle until a block boundary falls inside the AllowedFileExtensions key name. Everything left of the cut is reused verbatim (carrying TargetFolder, TempTargetFolder, MaxFileSize, TimeToLive, CsrfToken, and the start of AllowedFileExtensions). The first block after the cut is a sacrificial block whose garbage plaintext falls inside the JSON string key value (e.g., AllowedFileq9%Kf2#z). The remaining blocks are forged with backwards-CBC: closing the junk key with a throwaway value, then appending ",AllowedFileExtensions":["dll"]}. JavaScriptSerializer honors the last occurrence of duplicate keys, so only the forged .dll extension survives. If the sacrificial block produces breaking bytes (quote, backslash, control character), another sacrificial block is added to reshuffle the garbage.

## The Mixed-Mode DLL Payloads

The DLL is a C++/CLI "It Just Works" (IJW) mixed-mode assembly — simultaneously a valid managed .NET assembly and a native Windows PE. When Assembly.LoadFrom is called, the Windows loader fires DllMain(DLL_PROCESS_ATTACH) before any managed code executes. The CLR caches assemblies by manifest name, so DllMain only fires once per name per process; the exploit patches the .NET manifest name in the DLL bytes before each upload to bypass this cache.

Two payloads are provided: (1) a write-webshell that reads the IIS config path from GetCommandLineW(), parses the physicalPath (web root), and writes a self-decrypting .aspx file (key derived from filename, encrypted on disk) that survives app pool recycles, and (2) an in-memory webshell that hooks into the request pipeline and responds to any URL when a secret HTTP header is present, running the header value through cmd.exe. The in-memory variant leaves no disk artifact but dies on app pool recycle.

## Exploit Tooling

The telerik-rau-exploit tool (Go, published on GitHub) runs as a pipeline of numbered phases totaling approximately 127,000 oracle queries. At roughly 30 requests per second, the full chain completes in just over one hour against a lab target. The phases are: (1) decrypt _serializedConfiguration to find the AllowedFileExtensions cut point (~5,200 requests), (2) decrypt again to locate the TempTargetFolder blob (~49,500 requests), (4) forge the AllowedFileExtensions suffix with backwards-CBC (~62,800 requests), (5) assemble the forged token, (6) refresh session and swap prefix for live CsrfToken/PageGUID, (7) recover the CryptoService IV via the MetaData oracle and decrypt TempTargetFolder (~74,400 requests), (8) forge the MetaData blob with the AssemblyInstaller gadget (~127,000 requests), and (9) POST the forged rau_ClientState to trigger Assembly.LoadFrom and DllMain.

## Affected Versions

All versions of RadAsyncUpload from 2010.1.309 through 2026.2.519 (2026 Q2) are affected. The fix was shipped in version 2026.2.708 (2026 Q2 SP1), released July 8, 2026. Additional related components (RadPersistenceManager, RadDockLayout) have overlapping affected ranges starting at 2013.1.220. The 2026.2.708 patch replaces AES-CBC with AES-GCM authenticated encryption, which provides an integrity tag on every ciphertext, has no padding to probe, and eliminates the decrypt-versus-parse timing split.

## Exploitation Preconditions

TantoSec states the chain has preconditions not met by a default installation: (1) a page must render RadAsyncUpload whose server-side FileUploaded handler reads the UploadResult, and (2) the application must have an explicit, non-default Telerik.AsyncUpload.ConfigurationEncryptionKey configured — a setting that Telerik has historically recommended as a hardening measure. Without both conditions, affected sites are not exploitable through this specific chain.

## Historical Context

This is not the first critical vulnerability in the RadAsyncUpload component. CVE-2019-18935, a .NET deserialization flaw in the same handler, was exploited in the wild by Netwalker ransomware operators (2020–2021), Blue Mockingbird cryptomining operations (2020 onward), the XE Group cybercrime syndicate (August 2021 onward), and unnamed APT groups (August 2022 onward). CISA added CVE-2019-18935 to its Known Exploited Vulnerabilities catalog in November 2021, and the NSA listed it as one of the most commonly exploited vulnerabilities by Chinese state-sponsored hackers. A joint CISA/FBI/MS-ISAC alert (January 2023) confirmed a US federal agency breach where both an APT and XE Group had exploited the same vulnerable IIS server. Shadowserver honeypot data shows continued exploitation attempts on CVE-2019-18935 through August 2026 — nearly seven years after disclosure. The historical pattern strongly suggests that adversaries will weaponize this new chain once the public PoC is integrated into their toolkits.

## Detection and Defense

Exploitation leaves no obvious trace in standard ASP.NET error logs. Behavioral indicators include: w3wp.exe spawning cmd.exe, new or unexpected .aspx files in the web root, and mixed-mode DLLs (native PE plus .NET manifest) in the RadAsyncUpload temporary folder or App_Data. The in-memory webshell variant leaves no disk artifact but dies on app pool recycle; repeated exploitation attempts become the detection signal. Recommended mitigations if upgrading is not immediately possible: set customErrors to On or RemoteOnly, remove explicit encryption keys from web.config to fall back on MachineKey.Unprotect with AES+HMAC, generate strong non-autogenerated machine keys in IIS with HMACSHA256 validation, and disable the async upload handler entirely via Telerik.Web.DisableAsyncUploadHandler=true if RadAsyncUpload is not needed.