The Telerik RCE chain: a two-month-old patch and a brand-new weapon

What broke

Tanto Security published research on 7 September describing a chain of four vulnerabilities in Progress Telerik UI for ASP.NET AJAX that ends in remote code execution. All four were fixed in July.

The chain, in order:

All scores are Progress’s own as CNA. NVD has published no primary metrics.

One correction worth making, because it has been repeated: CVE-2026-13181 is not type confusion. It is unguarded type resolution — a type name taken from attacker-supplied metadata reaches a type-resolution call with no allowlist and no base-type constraint, and the resulting object’s properties are then populated from attacker-supplied data. CWE-470, not CWE-843. The distinction matters if you are writing detections or triaging by class.

The July fix replaced AES-CBC with AES-GCM. That is a neat single move: GCM is authenticated, so tampered ciphertext fails its tag check before anything is decrypted or parsed. That removes the padding oracle, the decrypt-versus-parse split, and the timing shadow of that split, all at once.

Who is affected

• Vulnerable: 2010.1.309 through 2026.2.519 — a fifteen-year range.
• Fixed: 2026.2.708 (2026 Q2 SP1), released 8 July 2026.

The July bulletin actually covers ten CVEs, 13181 through 13190, not just the four in this chain. Same affected range, same fixed version. If you are upgrading anyway you get all ten; if you are assessing exposure, do not scope your assessment to four.

The preconditions are the whole story

The full RCE chain requires configuration that a default install does not have:

• a reachable page containing a RadAsyncUpload control, and
• server-side code whose FileUploaded handler reads UploadResult — Telerik itself never reads it, and that getter is what performs the type resolution, and
• an explicitly set, non-default Telerik.AsyncUpload.ConfigurationEncryptionKey

There is an uncomfortable irony in that third item: setting ConfigurationEncryptionKey is a Telerik-recommended hardening step. The full chain lands on deployments that followed earlier advice.

Two caveats that get lost when this is summarised as “needs non-default config”:

• Those preconditions gate the full chain. The oracles (13182, 13183) need only a reachable RadAsyncUpload, and information disclosure applies more broadly.
• CVE-2026-13184 is the exact inverse. It triggers when configuration is absent — no ConfigurationHashKey, no explicitly configured machineKey. That is a default-ish deployment, not a hardened one.

So “we didn’t configure that, we’re fine” is wrong in both directions. Check which case you are in.

Is it being exploited?

Not that anyone has confirmed. None of CVE-2026-13181 through 13190 appear in CISA KEV as of the 8 September catalog, and there are no confirmed in-the-wild reports.

One vendor threat-intelligence page claims to be tracking “ongoing exploitation attempts” but gives no dates, volumes, or specifics, and nothing corroborates it. Treat that as unverified.

EPSS, once again, is not your friend here:

Half a percent, and the eleventh percentile at the bottom end.

Now the part that those numbers do not know about: Tanto published working exploit code on 7 September, in a public repository. EPSS is a prediction based on observed exploitation, and it has had no time to observe anything.

This is the real point of the post. The patch is two months old. The weapon is two days old. If you scoped this in July, read “no confirmed exploitation” and deferred it, the input that justified deferring has changed even though every number on the dashboard looks the same. Telerik UI for ASP.NET AJAX has four separate entries in KEV from earlier years — this product line has a consistent history of mass exploitation once public code exists.

What to do

Upgrade to 2026.2.708 or later. That is the actual fix and it resolves all ten July CVEs.

If you cannot upgrade immediately:

• Lock the web root so the application pool account cannot write to it. This both blocks the persistent payload and produces a signal when something tries.
• Relocate the RadAsyncUpload temp folder outside App_Data.
• Set an explicit machineKey with HMACSHA256 validation and autogeneration disabled, then recycle the app pool. This closes 13184’s fallback path.
• If RadAsyncUpload is unused, disable the handler outright: Telerik.Web.DisableAsyncUploadHandler = true.
• Disable cookie-based storage in RadPersistenceManager and RadDockLayout, and do not derive storage keys from user input (13185, 13186).

One vendor mitigation to treat carefully

Progress lists customErrors set to On or RemoteOnly as a mitigation for CVE-2026-13182, and it appears as mitigation #1 in the July bulletin.

The researchers say plainly that this suppresses only the error-text oracle. The timing variant, CVE-2026-13183, still works — they demonstrated a stable signal from Melbourne to us-east-1 across roughly 221ms of round-trip time using a timeless timing technique.

customErrors is partial hardening. It is not a fix, and it should not be the reason an upgrade gets deferred.

How to detect it

Progress states there are no visible symptoms and that exploitation leaves no obvious trace in standard ASP.NET error logs. Neither Progress nor Tanto has published network IOCs, Sigma rules, or YARA rules. That gap is real and I would rather say so than paper over it.

What you do have is behavioural:

• w3wp.exe spawning cmd.exe. Tanto’s words: this “almost never happens in normal operation and is worth alerting on outright.” Strongest single signal.
• New or off-schedule .aspx files in the web root. The on-disk payload is encrypted at rest with no recognisable web-shell strings, so content signatures will miss it. Hunt on file creation and timeline, not on content.
• A mixed-mode DLL — a native PE that also carries a .NET assembly manifest — under the RadAsyncUpload temp folder, or w3wp.exe loading a DLL out of App_Data. Well off the normal path.
• Repeated failed attempts are the tell for the memory-only variant, which touches no disk and dies on app-pool recycle. File integrity monitoring will not see it.

The pattern

Two months between the fix and the public exploit is a long, quiet window, and it closes without any dashboard changing colour. Nothing about CVE-2026-13181 looked different on 6 September than it did on 8 September — same CVSS, same EPSS, same absence from KEV — except that working code now exists.

If your prioritisation reads only scores, this is the shape of thing it will miss.

References

• Progress Telerik — Critical RCE Chain Bulletin, July 2026
• Progress Telerik knowledge base articles for CVE-2026-13181 through 13184
• Tanto Security — Telerik research writeup, 7 September 2026
• NVD — CVE-2026-13181, 13182, 13183, 13184
• FIRST EPSS
• CISA Known Exploited Vulnerabilities catalog