Public exploit turns Telerik padding-oracle flaw into full server takeover

Key points

• TantoSec has released a working exploit chain against Telerik UI for ASP.NET AJAX, a widely used web component library.
• The attack abuses a padding oracle, a cryptographic weakness that lets attackers decrypt and forge encrypted data one byte at a time.
• Only apps running a specific non-default configuration are vulnerable, and Progress Software shipped a fix in July.
• No exploitation in the wild has been confirmed at time of writing.
• Admins running Telerik UI should confirm they are on the July 2025 build or later and audit their web.config settings.

A security company called TantoSec has published a fully working attack that turns a cryptography bug in Telerik UI for ASP.NET AJAX into unauthenticated remote code execution. In plain English, an attacker on the internet, with no login, can end up running their own commands on the affected web server.

Telerik UI for ASP.NET AJAX is a big bag of ready-made web building blocks (buttons, grids, file uploaders) that thousands of business apps quietly rely on. Progress Software makes it. If you have ever used an insurance portal or a government form that felt oddly familiar across sites, there is a decent chance Telerik was under the hood.

Progress patched the underlying chain in July. The Hacker News flagged the release of the public proof-of-concept this week.

How does the attack actually work?

The entry point is a padding oracle, a classic flaw in how some systems handle encrypted data. When the server decrypts a value and the padding at the end is wrong, it reacts differently than when the padding is right. An attacker can send thousands of tweaked messages and, byte by byte, work out what the encrypted data says, or forge new encrypted data of their choosing.

In practice, that means TantoSec can hand-craft encrypted parameters that Telerik will happily accept as legitimate. From there, the chain pivots to file upload and code execution features inside the component, and the server runs whatever the attacker wants.

The failure mode here is familiar: a cryptographic side channel that looks academic on paper, weaponised into unauthenticated RCE once someone puts in a weekend.

Who is actually at risk?

Only sites running Telerik UI for ASP.NET AJAX in a specific non-default configuration are exposed. That is the good news. The less good news is that plenty of long-lived enterprise apps were configured years ago by people who have since left, and nobody has looked at the settings since.

What should teams do this week?

Confirm the version. Progress shipped the fix in a July release of Telerik UI for ASP.NET AJAX, so anything older than that is a candidate for exploitation now that working code is public. Then check the configuration: the vulnerable path only opens up in a specific non-default setup, and your web.config is the place to look.

If you cannot patch immediately, put the app behind a web application firewall rule that blocks the malformed encrypted payloads the padding-oracle attack has to send in bulk. That is a stopgap, not a fix.

One thing the post-mortem will say, if anyone gets popped by this: the patch was available for months before the exploit dropped.

Should ordinary customers worry?

Not directly, and not yet. There are no confirmed cases of anyone using this against real companies. But if a business you deal with runs a customer portal built on older Telerik components and gets breached in the coming weeks, this is a plausible route in. Watch for breach notification emails and treat any password reset prompt with the usual care: go to the site yourself, do not click the link in the email.

Operational takeaway: public PoC plus a four-month-old patch equals a scanning wave by the weekend. Get on the July build.