Telerik UI Flaw Enables Unauthenticated RCE via Padding Oracle

Introduction

A newly released proof-of-concept from security research firm TantoSec has drawn renewed attention to a high-impact vulnerability in Telerik UI for ASP.NET AJAX. The exploit chains a classic padding-oracle weakness in the component's AES-CBC handling with a deserialization flaw, ultimately producing unauthenticated remote code execution on vulnerable servers. While the issue is not trivial to exploit, and Progress Software shipped fixes back in July, the public availability of a working exploit raises the urgency for organizations that have not yet audited their deployments.

What makes this particular advisory noteworthy is the precision required to weaponize it. The attack only works against applications operating in a specific non-default configuration, which limits the blast radius. However, for organizations that fit that profile, the consequences are severe: an attacker with no credentials could execute arbitrary code on the underlying server.

Understanding the Vulnerability Chain

At the heart of the exploit lies a well-known cryptographic mistake. Telerik UI for ASP.NET AJAX exposes functionality that encrypts and decrypts data using AES in CBC mode. When the implementation reveals whether a given ciphertext produced a valid padding error or a different kind of decryption error, it creates a textbook padding oracle. Attackers can exploit this oracle to recover plaintext byte by byte without ever needing the encryption key.

TantoSec's researchers did not stop there. They paired the padding oracle with a second flaw that allowed them to manipulate serialized objects passed through the same component. By decrypting and re-encrypting payloads through the oracle, the team was able to inject a malicious serialized object that the application would later deserialize. The end result is remote code execution, triggered simply by sending crafted HTTP requests to an exposed endpoint.

Who Is Actually at Risk?

The critical detail in this advisory is that the exploit does not work out of the box against default Telerik UI installations. The vulnerable code path only becomes reachable when developers configure the component to use custom encryption keys rather than the automatically generated machine-specific defaults. This configuration choice is common in load-balanced environments, multi-server deployments, and applications that need to share encrypted state across instances.

Security teams should ask the following questions to determine exposure:

• Was a custom encryption key manually configured in the Telerik UI settings?
• Is the application accessible from the internet, or only from internal segments?
• Has the application been patched to a Telerik UI build containing the July 2024 fixes from Progress?
• Are there any indicators of probing activity against RadAsyncUpload, RadUpload, or related endpoints?

The Patch Timeline and Current Threat Status

Progress Software addressed both the cryptographic flaw and the deserialization weakness in updates released in July. Organizations running a fully patched version of Telerik UI for ASP.NET AJAX are not vulnerable to this specific chain, regardless of how they configured their encryption keys. The release of a public proof-of-concept does, however, shift the calculus for organizations that have been slow to update.

As of the time of writing, no confirmed reports of in-the-wild exploitation have surfaced. That window of relative quiet is unlikely to last, given how reliably padding-oracle attacks can be automated once a working exploit is published. Threat actors with a history of opportunistic scanning are likely to begin probing exposed Telerik UI endpoints in the coming weeks.

Recommended Defensive Actions

For security teams responsible for ASP.NET applications using Telerik UI, several immediate steps are advisable. First, confirm the exact version of Telerik UI in use and compare it against Progress's July 2024 advisory to determine whether the patch has been applied. Second, audit configuration files and source code to identify any instances where custom encryption keys have been set, since these are the deployments that actually face exposure.

Beyond patching, organizations should consider placing web application firewalls in front of vulnerable endpoints to detect and block exploitation attempts. Monitoring for anomalous outbound connections from web servers is also wise, as successful exploitation typically leads to follow-on activity such as webshell deployment or credential harvesting. Finally, rotating any encryption keys that may have been exposed during the vulnerable period is a prudent precaution.

Conclusion

The TantoSec proof-of-concept serves as a useful wake-up call for any organization running Telerik UI for ASP.NET AJAX in a customized configuration. While the vulnerability requires specific conditions to exploit and was patched months ago, the public release of a working exploit removes the friction that previously kept opportunistic attackers at bay. Verifying patch status, auditing encryption key configuration, and monitoring for unusual activity should be top priorities for affected teams.

At Grivyonx Cloud, we understand that vulnerabilities like this one rarely exist in isolation. They are symptoms of broader gaps in configuration management, patch cadence, and continuous monitoring. Our AI-driven cybersecurity and automation services help organizations identify misconfigurations across their technology stack, prioritize patches based on real exploitability, and detect anomalous behavior before it escalates into a breach. Proactive defense is no longer optional in a threat landscape where public exploits can shift a theoretical vulnerability into an active one overnight.