The vulnerabilities described in this post were discovered, analysed, and exploited with some AI assistance, and a lot of old-fashioned human persistence. What you need to know Tanto Security found an unauthenticated AES-CBC padding oracle in Telerik UI for ASP.NET AJAX and chained it with two other vulnerabilities to achieve remote code execution. Progress Software says that the vulnerability affects versions 2010.1.309 through 2026.2.519 inclusive, and that version 2026.2.708 (2026 Q2 SP1) prevents exploitation of the chain. The vulnerability chain has preconditions that are not met by a default installation of Telerik UI for ASP.NET AJAX: There must be a reachable page containing a RadAsyncUpload control where the page’s server-side FileUploaded handler reads UploadResult The site must be configured with an explicit, non-default Telerik.AsyncUpload.ConfigurationEncryptionKey , which is a recommended hardening setting If the site has customErrors set to On , then the padding oracle vulnerability must be exploited using timing analysis. This increases the complexity and effort of a successful attack, but it does not prevent exploitation. Users of Telerik UI for ASP.NET AJAX should upgrade to 2026.2.708 (2026 Q2 SP1) or later. Telerik UI for ASP.NET AJAX is a pretty popular framework that shows up regularly in enterprise ASP.NET applications. It ships as a suite of server-side handlers and UI controls, and if you spend enough time doing penetration tests on web apps you will run into it sooner or later. Some time ago I ran into a Telerik UI for ASP.NET app doing something odd. Its AES-CBC scheme derived its encryption key straight from the ASP.NET_SessionId cookie. A cookie is not a server-side secret. It is a value the client can observe and manipulate in the request, so anyone could freely decrypt and forge the application’s protected parameters. This behaviour made me wonder where it was coming from. A user-controlled key is bad on its own, but the bigger question was whether the developers of that app had introduced this behaviour themselves or whether it was baked into Telerik. If it was the framework, this would not be one app’s problem. It would ship with Telerik itself, in every version that carried that behaviour. A quick Google search confirmed that Telerik does use AES-CBC in its handlers and encrypted parameters. Then I pulled up the Telerik documentation on how it handles encryption keys for its handlers . Based on what I read, I began to doubt that Telerik was deriving an encryption key from the ASP.NET_SessionId cookie. In its documentation, Telerik explicitly tells developers to configure their own encryption key values. When it’s not configured, Telerik falls back to using the ASP.NET machine key as the encryption key. That key is a server-wide value ASP.NET keeps for protecting things like view state and forms-auth cookies. This made me think that the ASP.NET_SessionId encryption key derivation was coming from the application, not the framework. However, that search left me with a different question. If Telerik is using AES-CBC , could it be vulnerable to padding oracle attacks? How padding oracle attacks work New to padding oracles? This section teaches the attack from the ground up, for readers who have not met a padding oracle before or who want a refresher, and it takes each part slowly. If that is you, read on. If you already know how padding oracles work, feel free to skip ahead to A quick tour of Telerik and its building blocks . Block ciphers like AES work on fixed-size chunks called blocks. An AES block consists of 16 bytes. Real messages are rarely a neat multiple of that, so the final chunk has to be “topped up” to a full block before it can be encrypted. That “topping up” is called padding. The common scheme is PKCS#7. It works by encoding the number of padding bytes in the padding bytes themselves. Every padding byte holds the number of padding bytes that were added. If the final block is missing one byte, that byte is filled with 0x01 . Two bytes short are filled with 0x02 0x02 . Three bytes short are filled with 0x03 0x03 0x03 , and so on. When the receiver decrypts the message, it reads the last byte to know how many bytes to remove. Before removing them, it validates the padding, and if the trailing bytes do not follow the rule above, the decryption fails with an invalid padding error. PKCS#7 has one more rule worth knowing. What if the message is already an exact multiple of the block size, with nothing to top up? It still gets padded, with a whole extra block. For a 16-byte block that means sixteen bytes each holding 0x10 . The scheme always adds between one byte and a full block, never nothing, so the receiver can always trust the last byte to tell it how much to strip. Block ciphers like AES only encrypt one block at a time. Encrypting a longer message means running the cipher over each block in turn, and encrypting them independently leaks structure. To avoid that, a ...