On 7 September 2026, TantoSec's Marcio Almeida published a working exploit for a four-flaw chain in RadAsyncUpload, the file upload control in Telerik UI for ASP.NET AJAX. The chain ends in unauthenticated code execution on the web server.
The affected range is 2010.1.309 through 2026.2.519, fixed in 2026.2.708. That first version number is from 2010.
The four flaws
- CVE-2026-13181 — a type-resolution flaw, CVSS 8.1
- CVE-2026-13182 — the padding oracle
- CVE-2026-13183 — a timing-based variant of the same oracle
- CVE-2026-13184 — a predictable default encryption key
Only the first has a published CVSS.
How the chain works
The control encrypts client-side upload configuration using AES-CBC with no integrity checking. That is the root cause, and everything else follows from it.
Because there is no MAC, an attacker can tamper with the ciphertext and watch how the server reacts. The responses differ depending on whether the tampered data produced valid padding or failed JSON parsing afterwards — two distinguishable outcomes, which is all a padding oracle needs. Given enough queries, the attacker decrypts the configuration and forges a new one without ever learning the key.
The forged configuration can name arbitrary .NET types, which the control then deserializes without an allowlist. That reaches gadgets capable of loading an attacker-supplied DLL, and the uploaded mixed-mode assembly runs native code the moment it loads.
Encrypt-then-MAC has been the known-correct construction for two decades. This is what its absence costs.
The precondition is the hardening step
Here is the part that will be misread, so it is worth being exact.
The exploit does not work against a default installation. It needs two things:
- The RadAsyncUpload control rendered on a page, with a server-side handler that reads upload results
- An explicit, non-default encryption key configured
The second is a hardening measure Telerik recommends. Administrators who followed the vendor's own guidance are the ones in scope.
That is not an argument against hardening, and anyone drawing that conclusion has the causality backwards. Setting a key was the right thing to do — the predictable default key is itself CVE-2026-13184. The problem is that the key was put to work in a cipher mode with no integrity check, which means configuring it correctly moves you from one broken state into a different broken state. The lever the vendor gave administrators was never attached to the thing that needed fixing.
If you set that key because you were told to, you did your job. The construction underneath it did not do its.
127,000 requests
The end-to-end attack in TantoSec's write-up took roughly 127,000 oracle requests — about an hour against a lab target.
That number is the good news, and it is the most actionable thing in this story.
A padding oracle is not stealthy. It is a hundred and twenty-seven thousand requests to one endpoint, from an attacker who needs every single response. Any rate limiting, any per-endpoint anomaly threshold, any WAF that counts requests rather than inspecting them, changes this from an hour into something impractical — and generates an alert while doing it.
TantoSec explicitly does not know how far rate limiting extends the attack, so treat this as a strong lead rather than a measured mitigation. It is still the cheapest control available to anyone who cannot patch today.
The disclosure timeline was handled well
- 22 May 2026 — TantoSec reports to Progress
- 8 July — Progress patches
- 22 July — CVEs published
- 7 September — public exploit released
Two months between the patch and the working exploit. That is a defensible interval and worth saying, because the same site will criticise vendors who get this wrong.
There are no confirmed reports of these 2026 flaws being exploited in the wild, and none of them is in CISA's KEV catalogue as of 7 September. That will not survive contact with a public CLI tool for long. Last week's Chrome zero-day is a reminder of how little time there usually is between a working exploit existing and it mattering.
What to do
- Upgrade to 2026.2.708 or later. This is the fix and everything below is a stopgap.
- Find your RadAsyncUpload instances. The version range starts in 2010; the control is embedded in a great many internal ASP.NET applications nobody has looked at in years.
- Rate-limit the upload handler. 127,000 requests is the attack. Something has to count them.
- Do not remove your encryption key as a mitigation. The default is CVE-2026-13184. Removing the key does not close the chain, it opens a different one.
- Alert on repeated malformed upload configurations. That is what an oracle looks like in a log.
What is not established
- CVSS for three of the four CVEs. Only CVE-2026-13181 has a published score.
- Real-world exposure. No count of vulnerable instances has been published.
- How much rate limiting actually helps. Explicitly unmeasured.
- Whether it is being exploited. No confirmed reports as of 7 September, and a public tool now exists.
