The Telerik RadAsyncUpload vulnerability is a good example of why security bugs rarely exist in isolation.
The original issue was not an obvious remote shell. It was a cryptographic mistake. Combined with a second flaw in how .NET types were resolved, it became something much more serious: remote code execution.
The underlying component, RadAsyncUpload, handles file uploads inside ASP.NET applications. The affected versions used encrypted client-side state protected with AES-CBC, but without sufficient integrity protection. That distinction is where the attack starts.
The oracle is the first primitive
The vulnerable application reacted differently when manipulated ciphertext failed at different processing stages.
That response difference gives an attacker an oracle.
The attacker does not need the AES key. Instead, repeated requests can reveal information about the encrypted plaintext through the application’s responses. In the Telerik case, the attacker can progressively recover or manipulate protected metadata.
This is the important cryptographic lesson: encryption alone does not guarantee that encrypted state is trustworthy.
CBC encryption without proper authentication can become malleable. If the server tells an attacker enough about how modified ciphertext was processed, the ciphertext itself becomes a query interface.
The application effectively answers:
“Your guess changed this part of the encrypted state in this way.”
Repeat that enough times and protected data stops being protected.
Then the attack crosses into .NET
The second vulnerability, CVE-2026-13181, involves the AsyncUploadTypeName value.
Once the attacker can forge the relevant upload metadata, that value can influence .NET type resolution.
This is where the attack changes character.
The attacker is no longer merely manipulating encrypted application state. The forged state reaches a component capable of resolving attacker-controlled types, creating a path toward loading attacker-controlled code.
The final result is code execution in the IIS application pool context.
The chain looks roughly like this:
attacker-controlled request → padding oracle → forged encrypted metadata → type resolution → malicious DLL → server-side code execution
Each individual mistake looks manageable.
Together, they form an RCE.
Why the number of requests matters
The public exploit was not magic.
Researchers reported that the demonstrated oracle attack required roughly 127,000 requests and could take around an hour under their laboratory conditions.
That makes exploitation more complicated, but it does not remove the underlying security problem.
Internet-facing applications are particularly interesting targets because attackers can automate large numbers of HTTP requests. Rate limiting can slow an attack. It does not repair a broken trust model.
The related timing-oracle issue makes the situation even more interesting. Hiding detailed error messages does not necessarily remove the information leak if processing times still differ between internal states.
The real security boundary was never the cipher
The biggest lesson here is architectural.
Developers often think about encrypted client state as:
encrypted = trusted
It isn’t.
Encryption provides confidentiality. Authentication and integrity mechanisms are what stop attackers from modifying protected state without detection.
Once the server accepts manipulated encrypted data and feeds fields from that data into sensitive functionality such as type resolution, the cryptographic layer becomes part of the application attack surface.
The vulnerable upload control therefore became more than an upload feature.
It became a parser, cryptographic oracle and type-resolution gateway.
Bugstoday Take
This is why chaining vulnerabilities deserves more attention than looking at CVSS scores individually.
A padding oracle can sound like a cryptography problem. A type-resolution issue can sound like a framework problem.
An attacker doesn’t care.
They combine primitives until the application crosses a security boundary.
Telerik patched the chain in July. The public exploit appeared in September. That gap is exactly why patching old enterprise components cannot be treated as routine maintenance.
Once the exploit exists, every forgotten ASP.NET application running an old Telerik component becomes an interesting target.
And the uncomfortable part is that the application does not have to look vulnerable from the outside.
It only has to answer the wrong questions.
Technical Sources
- Progress Telerik security advisory
- CVE-2026-13181
- CVE-2026-13182
- CVE-2026-13183
- Telerik UI for ASP.NET AJAX 2026.2.708
- TantoSec technical research and public exploit
- Bugstoday: Telerik’s Padding Oracle Just Became an RCE
Today’s Bugs. Tomorrow’s Breaches.
