From Research Paper to Command-Line Tool
Security researchers Marcio Almeida and Justin Steven at TantoSec published a working, publicly available exploit tool for a chain of four vulnerabilities in Telerik UI for ASP.NET AJAX on September 7, 2026. The CVEs range from CVE-2026-13181 through CVE-2026-13184 and cover a type-resolution flaw, a padding oracle in AES-CBC encryption, a timing-based variant of that oracle, and a predictable default encryption key. Individually, several of these look like the kind of low-severity finding that gets triaged and deprioritized. Chained together, they add up to unauthenticated remote code execution.
The distinction between a described vulnerability and a released exploit tool matters enormously for how fast risk moves through the wild. A CVE with a technical writeup requires an attacker to do real engineering work to turn it into a working attack. A published command-line tool, complete with the DLL payloads needed to execute it, collapses that barrier to entry down to running a script. TantoSec's release does exactly that, and it does so for a vulnerability class that has existed in Telerik's codebase since 2010.
How the Chain Actually Works
The technical path runs through Telerik's RadAsyncUpload control, a component that handles file uploads in ASP.NET applications built with this UI library. The core weakness is that the server encrypts upload configuration data using AES-CBC without any integrity verification, and because the server responds differently depending on whether padding in the ciphertext is valid, an attacker can use that behavioral difference to decrypt and then forge the encrypted configuration without ever knowing the underlying key. That forged configuration then gets deserialized on the server side into an arbitrary .NET type, and the attacker steers that deserialization into a gadget that loads a malicious DLL under the attacker's control.
The end state is remote code execution running with IIS application pool privileges, which in most deployments means the attacker lands with meaningful access to the web server process itself, not a low-privilege sandboxed context. Every step in this chain relies on a design choice, unauthenticated encryption without integrity checks, that security engineers have flagged as an anti-pattern for well over a decade. This is not a novel cryptographic break. It is a known category of mistake that sat unaddressed in a widely deployed enterprise UI component.
You Cannot Assume Your Logs Would Catch It
Progress Software's own advisory language carries a specific warning that deserves to be read carefully by anyone running an incident response process: the exploitation technique leaves no obvious trace in standard ASP.NET error logs. For a security team that leans on log review as a compensating control while patches roll out, that statement removes the safety net entirely. You cannot reasonably tell your board or your auditors that you would have caught exploitation through normal monitoring, because the vendor itself says the standard telemetry will not show it.
That gap pushes the burden back onto patch status and network-level detection rather than application logs. Organizations running affected Telerik versions need to treat the absence of alarming log entries as uninformative, not reassuring, and instead verify patch application directly against the asset inventory. If you cannot say with confidence which of your internet-facing ASP.NET applications embed a vulnerable Telerik UI version, that inventory gap is now the most urgent item on the list, ahead of the patch itself.
The Patch Has Existed for Two Months
Progress Software fixed the underlying issue in version 2026.2.708, released July 8, 2026, by replacing the flawed AES-CBC scheme with authenticated encryption that closes the padding-oracle path entirely. That means every organization running an affected version has had roughly two months between patch availability and this public exploit release to close the gap. TantoSec's disclosure did not hand attackers a brand-new zero-day, it handed them a fully weaponized tool against a bug that patient, well-resourced defenders should already have closed.
That timeline is exactly why this incident belongs in a different category from the true zero-days in this week's news cycle. There is no excuse gap here, no vendor racing to catch up with active exploitation. There is only the ordinary, unglamorous failure mode of enterprise patch management: a fix existed, it was not applied everywhere, and now a tool exists that makes exploitation trivial for anyone who finds an unpatched instance through routine internet scanning. That is a harder failure to explain internally than a genuine zero-day, because it means the organization had every opportunity to close the gap before anyone had to.
What This Means for Legacy Enterprise Software
Telerik UI for ASP.NET AJAX sits inside a huge number of enterprise .NET applications built over the past fifteen years, many of them internal line-of-business tools that never got the security attention a customer-facing product would. That is precisely the profile of software this exploit is most dangerous against: old, embedded deep in a stack nobody actively maintains, running with elevated server privileges, and now facing a public tool that turns a decade-old design flaw into full compromise.
The action item for enterprise tech leaders is a targeted inventory sweep, not a general patch reminder. Identify every internet-facing ASP.NET application in your environment, confirm whether any embed Telerik UI for ASP.NET AJAX, and check the version against 2026.2.708 specifically. Given that log review will not reliably surface prior exploitation, any instance found running an older version should be treated as a candidate for compromise assessment, not just a patch to schedule for the next maintenance window. This is also a good moment to ask application owners a broader question: which other third-party UI components in the portfolio carry similarly old, unaudited cryptographic code that nobody has revisited since it was first integrated a decade ago.
