Security firm TantoSec has published a working exploit that reaches unauthenticated code execution through the RadAsyncUpload control in Progress Telerik UI for ASP.NET AJAX. The September 7 disclosure puts a complete attack chain and ready-to-run tooling in public hands, although the researchers report no confirmed exploitation in the wild.
The demonstrated chain affects Telerik UI releases 2010.1.309 through 2026.2.519 under specific application conditions. Progress fixed it in 2026.2.708, released July 8. Teams running older builds should scope the RadAsyncUpload surface now, then look beyond patch state for evidence that the IIS worker process already loaded attacker-controlled code.
Public code completes the chain
The attack starts with encrypted RadAsyncUpload client state. Vulnerable releases protect that state with AES-CBC but can reveal whether modified ciphertext failed during decryption or survived decryption and failed later as JSON. Progress describes CVE-2026-13182 as a remotely exploitable decrypt-versus-parse oracle that does not require authentication or knowledge of the encryption key.
That distinction gives an attacker a chosen-ciphertext test. By changing bytes in the ciphertext block before a target block and observing which failure follows, the attacker can recover plaintext one byte at a time. The same oracle can then forge encrypted upload metadata. If an application hides the two error messages with customErrors, TantoSec found a slower timing difference that still reveals whether padding was valid.
The final step is Telerik’s CVE-2026-13181. Forged metadata controls AsyncUploadTypeName; vulnerable code resolves that attacker-selected type and can load a mixed-mode DLL. The result is code execution inside w3wp.exe, the IIS worker process hosting the application.
TantoSec’s Marcio Almeida calls the chain’s conditions “preconditions that are not met by a default installation.” That limit is central to exposure decisions. It also explains why the CVSS 3.1 vector for CVE-2026-13181 carries high attack complexity despite the release of automated exploit code.
Three conditions define exposure
First, the application must run Telerik UI for ASP.NET AJAX 2026.2.519 or earlier and render a reachable RadAsyncUpload control. Second, server-side application code must consume the uploaded result. Third, the site must use an explicit Telerik.AsyncUpload.ConfigurationEncryptionKey, a non-default setting that Progress historically recommended as hardening.
A strong value for that custom key does not stop the oracle. The attack measures how the server handles altered ciphertext instead of guessing or stealing the key. Setting customErrors to On or RemoteOnly removes the simple error-text signal, but the researcher’s timing variant preserves the path at greater cost.
Version alone therefore identifies the population that needs investigation, not every exploitable server. Neither TantoSec nor Progress quantified the number of exposed deployments. The primary records also do not report victims or in-the-wild exploitation. A public exploit raises immediacy without establishing prevalence.
Figure details
A linear sequence begins with an unauthenticated request carrying altered RadAsyncUpload client state. The vulnerable server reveals valid padding through different parse behavior or response timing. That oracle lets the attacker forge encrypted metadata containing an attacker-selected AsyncUploadTypeName. Vulnerable type resolution then loads a mixed-mode DLL and executes its code inside w3wp.exe. The diagram describes demonstrated capability under the documented non-default prerequisites and does not claim observed exploitation.
Hunt the worker process
TantoSec says successful exploitation leaves no obvious trace in standard ASP.NET error logs. Recognition has to focus on what happens after the oracle succeeds. On Windows web servers with an affected Telerik build and exposed RadAsyncUpload control, review process-creation telemetry for w3wp.exe spawning cmd.exe or another unexpected child process.
Search the application web root for new or unexplained .aspx files. Inspect RadAsyncUpload temporary storage and App_Data for mixed-mode DLLs that the application did not deploy. Separate files merely written to those locations from modules the IIS worker actually loaded; process or module-load telemetry provides the stronger execution evidence.
The released demonstration includes one payload that writes a web shell to disk and another that executes from memory. That split makes any single filesystem check incomplete. Correlate IIS requests to Telerik.Web.UI.WebResource.axd with worker-process children, loaded modules, application-pool identity activity, and subsequent account or file changes.
These behaviors are investigative pivots. A legitimate deployment or administrative task can create some of them, while memory-only execution can avoid the web-shell artifact entirely. Preserve volatile process and module evidence before recycling an application pool during containment.
Upgrade changes the cryptography
Progress fixed the chain in 2026.2.708, which replaces the vulnerable custom-key handling with AES-GCM authenticated encryption. GCM rejects modified ciphertext before decrypting or parsing it, removing both the padding signal and the later decrypt-versus-parse distinction. Progress lists CVE-2026-13181, CVE-2026-13182, CVE-2026-13183, and CVE-2026-13184 among the release’s security fixes.
Progress strongly recommends upgrading to 2026.2.708 or later. If an immediate upgrade is impossible, disable the upload handler by setting Telerik.Web.DisableAsyncUploadHandler to true when RadAsyncUpload is not needed. Progress also documents removing the custom Telerik key on older releases and falling back to an explicitly generated ASP.NET machine key protected with AES and HMAC. The IIS machine-key validation method should be HMACSHA256, with automatic runtime generation disabled.
Those changes reduce exposure while an upgrade is pending. Hiding errors only forces the timing route, and a stronger custom key on a vulnerable build does not close the oracle. After changing machine keys or handler settings, recycle the relevant application pool and test the application’s expected upload behavior.
Prove the handler is safe
Inventory the deployed Telerik.Web.UI.dll version and the application pages that render RadAsyncUpload. Confirm whether server-side upload code reads the result and whether web.config defines Telerik.AsyncUpload.ConfigurationEncryptionKey. The expected result is 2026.2.708 or later on every exposed application, or a disabled async-upload handler while the upgrade is completed.
Then verify the response at the point of use: exercise an approved upload workflow after deployment and confirm normal application behavior while altered client state receives one uniform rejection. A clean version check proves the published flaw is removed. Historical process, module, IIS, and filesystem review is what addresses the separate question of whether the old path was used.
This disclosure matters because a setting intended to strengthen encryption became one of the conditions for a practical exploit. The durable fix is authenticated encryption that refuses tampered state before application logic can distinguish anything about it. Defenders should treat the public tool as a deadline to remove the oracle and preserve the evidence that a version number cannot reconstruct later.