Telerik UI for ASP.NET AJAX File Read to RCE Chain (CVE-2026-18672)

TL;DR

• An unauthenticated file read in Progress Telerik UI for ASP.NET AJAX, CVE-2026-18672, lets any attacker who can reach a page with RadImageEditor or RadEditor read files under the application root, including web.config. Tanto Security published the full chain, with working requests, on October 27, 2026.
• The read chains into CVE-2026-19219, a dialog-parameter tampering flaw, for unauthenticated remote code execution as the application pool identity when web.config carries a static machineKey or a custom DialogParametersEncryptionKey. Progress rates the read High at 7.5 and the tampering flaw High at 8.1, and its chain bulletin is titled "Critical Security Bulletin".
• Every release from 2011.2.712 through 2026.2.708 is affected. No exploitation is known, neither CVE is in CISA's Known Exploited Vulnerabilities catalog as of November 3, 2026, and the CISA ADP recorded Exploitation "none" on September 2, 2026.
• Upgrade to 2026.3.812 or later. No configuration fully mitigates the file read before the upgrade, so treat any unpatched site that exposes the controls as exposed. "How do I fix it?" carries the vendor's interim measures.

Am I affected?

You are exposed to the file read when all of these hold:

• Your application runs Progress Telerik UI for ASP.NET AJAX from 2011.2.712 through 2026.2.708, any release in a fifteen-year span.
• A page reachable by unauthenticated visitors renders RadImageEditor, either as a standalone control or through RadEditor's built-in Image Editor tool, which hosts a RadImageEditor internally. The handlers behind the chain are registered once for the whole application, so any page that renders RadEditor pulls the dialog machinery in.
• The attacker only needs that page. The writeup reproduces the read with two unauthenticated requests and a replayed, unmodified __VIEWSTATE, which is signed on its own and does not cover the other hidden fields.

You are additionally exposed to the RCE half when both of these hold:

• RadEditor is used with its built-in file browser dialogs enabled, and the application sets a custom Telerik.Web.UI.DialogParametersEncryptionKey in web.config or a static machineKey rather than the AutoGenerate default. Progress recommends configuring these keys, but neither is present in a default install, and Progress states that AutoGenerate deployments are not remotely forgeable through this vector.
• The attacker has recovered the key by reading web.config through the file read or by other means.

Check the deployed assembly and the web.config keys:

# File version of the assembly the application deploys
Get-Item .\Bin\Telerik.Web.UI.dll |
  Select-Object -ExpandProperty VersionInfo |
  Format-List FileVersion, ProductVersion

# The two keys that turn the file read into RCE, if present
Select-String -Path .\web.config -Pattern "machineKey",
  "DialogParametersEncryptionKey"

A machineKey element absent from web.config means the AutoGenerate default is in effect, per the vendor's advisory. A static machineKey or a custom DialogParametersEncryptionKey is what the RCE path needs, and a present key is a lead to confirm, not by itself a compromise.

How do I fix it?

Upgrade to the 2026 Q3 release, then confirm the keys were not exposed while you waited:

1. Upgrade every application using the suite to 2026.3.812 or later through the vendor's upgrade documentation. Progress released the fixed version on August 12, 2026 and urged customers to upgrade through this critical security bulletin.
2. Rotate the exposed material on any site that ran a vulnerable version with a static machineKey or a custom DialogParametersEncryptionKey and cannot rule out the file read. Treat the keys as recoverable by an unauthenticated visitor.
3. Apply the vendor's interim measures where the upgrade cannot land immediately. They reduce risk but do not fully close the issue. Confirm the application pool identity has no write access to the web application root. Disable script execution on any folder it can write to.
4. If the RadEditor file browser is not required, remove the affected RadEditor controls or disable their file browser dialogs, or remove the DialogHandler mapping from web.config. The vendor's advisory carries the exact <httpHandlers> and <handlers> lines to remove.

Blocking the literal request Telerik.Web.UI.WebResource.axd?type=iec is not a confirmed complete mitigation, per the vendor. Alternate handler mappings, URL forms, encodings and a custom HttpHandlerUrl can bypass a filter written against one route. There is no configuration that mitigates the file read prior to upgrading.

What is the root cause?

RadImageEditor's image path travels to the server in a hidden form field that is neither encrypted nor signed. The control stores it in a download cache that a second, globally registered handler later reads from disk. The RadEditor dialog parameters are encrypted and signed. Nothing outside the blob, however, constrains which folders they name.

RadImageEditor keeps its state in a hidden postback field named <ClientID>_ClientState. Tanto Security's decompilation, published with the writeup, shows how the base class loads it:

// Telerik.Web.UI/RadWebControl.cs, decompiled by Tanto Security
// no message authentication code and no decrypt,
// so the whole dictionary is client-controlled
if ( !string . IsNullOrEmpty (text) &&
     new JavaScriptSerializer (). DeserializeObject (text)
         is Dictionary < string , object > clientState) {
    LoadClientState (clientState);
}

The override in RadImageEditor copies the imageUrl key of that dictionary into the control's ImageUrl property. The control then stores that path in a download cache to serve the file on a later request. A page-level field the server never authenticates becomes a server-side file path.

The read-back runs through Telerik.Web.UI.WebResource.axd?type=iec, the ImageEditorCacheHandler registered once for the application. The handler decrypts the _downloadKey token it receives, looks the entry up in the cache, maps the stored string to a path and returns the file's bytes. It derives the response content type from the file's extension and does not restrict which extensions it serves, so web.config returns as image/config.

The relative-path resolution disagrees between the two stages: the fetch that caches the path resolves it from the page's folder, while the handler resolves it from the application root. No relative path satisfies both. An application-relative path does: ~/web.config names the same file in both stages, so it survives the fetch's existence check and the handler's application-root containment check.

For the RCE half, RadEditor's dialogs carry an encrypted and authenticated parameter blob, SerializedParameters, that includes the file browser's ViewPaths, UploadPaths and DeletePaths. The blob's integrity protection proves the holder of the key produced it, not that a developer configured those folders, as the writeup concludes. Whoever holds the encryption key mints a valid blob that points uploads at the web root.

How is it exploited?

The public proof of concept is the request sequence published in the Tanto Security writeup on October 27, 2026. The steps below follow it.

1. The attacker sends an unauthenticated GET to a page that renders RadImageEditor and keeps the __VIEWSTATE and the client state field name from the response.
2. The attacker posts back to the same page, replaying __VIEWSTATE unchanged so its MAC passes, with the client state field carrying the poisoned path:

{"currentCommand": null, "imageUrl": "~/web.config", "imageKey": null,
 "height": null, "width": null, "enableResize": null,
 "toolBarPosition": null, "isf": null}

1. The response carries a fresh _downloadKey, the encrypted GUID of the poisoned cache entry. On a RadEditor page the attacker reaches the same control through the ImageEditor dialog. They harvest the dialog's server-minted parameter blob from the page and supply the path in the OriginalImageLocation form field.
2. The attacker posts the key to Telerik.Web.UI.WebResource.axd?type=iec&dkey=3, and the handler returns the bytes of ~/web.config, the writeup's PoC target, as image/config.
3. If the recovered web.config holds a static machineKey, the attacker forges a signed __VIEWSTATE carrying a deserialization gadget chain. This is the standard ASP.NET ViewState technique built by ysoserial.net, and the writeup reproduced it to write a webshell into the web root.
4. If it holds a DialogParametersEncryptionKey, the attacker instead forges the dialog parameter blob with UploadPaths at the web root. The webshell then uploads through RadEditor's file browser, the path Progress assigned to CVE-2026-19219.
5. The webshell's code runs as the IIS application pool identity, and the attacker controls it from that point on.

How does the attack flow?

One unauthenticated request sequence reads web.config, and the keys inside it, when configured, turn the read into code execution in the web root.

What can an attacker do?

The vendor's chain bulletin states the combined impact plainly. An unauthenticated remote attacker who exploits the chain can execute arbitrary code on the web server with the privileges of the application pool identity. The bulletin assesses this may result in full server compromise, data exfiltration or further lateral movement within the hosting environment.

• The file read alone, CVE-2026-18672, exposes every file under the application root, and web.config is where connection strings and the two keys live. It works on default installs; no key configuration is needed to read.
• The RCE chain, through CVE-2026-19219, needs the key material: a static machineKey or a custom DialogParametersEncryptionKey present in web.config. A site left on the AutoGenerate default with no custom dialog key is not remotely forgeable through this vector, per the vendor's advisory.
• Exploitation is silent. The vendor's bulletin notes there are no visible symptoms and no obvious trace in standard ASP.NET error logs. The writeup's two RCE paths each end with a functional webshell rather than a crash.

The conditions are network reachability of a page that renders the controls and, for code execution, the presence of the key settings. No user interaction and no authentication are required at any step.

Why does the fix work?

Progress distributes a closed-source assembly, so no patch diff is public to quote. The fix's behavior, as the writeup verified it against 2026.3.812, closes both halves:

• The cache handler now checks the decrypted path against the control's configured image directories and enforces an image extension allow-list of jpg, jpeg, png, gif and bmp. Either check stops the web.config read, and the dialog's OriginalImageLocation input now runs through the same checks.
• RadImageEditor now stores its image location in the client state as an encrypted value under a server key, so a client can no longer substitute its own path without that key.
• The dialog upload path enforces a hardcoded denylist of dangerous extensions when a file is written, rejecting .aspx, .ashx, .config, .exe and a long list of other types, and adds an opt-in Telerik.Web.UI.FileBrowserAllowedPaths setting that restricts which folders the file browser may list and upload to.

The fix narrows the issue rather than removing the pattern. The writeup notes that FileBrowserAllowedPaths is opt-in. When it is not set, the file browser keeps trusting whatever paths a validly encrypted dialog blob carries. An adversary holding the DialogParametersEncryptionKey can still upload to any folder on the site. The vendor's own mitigation section is aligned: the measures reduce risk, and only the upgrade fully addresses it. Rotate any exposed key when you upgrade, because the key, not the version, is what the second half needs.

How do I check if I was compromised?

No indicators are published, and the vendor states exploitation leaves no obvious trace in standard ASP.NET error logs. These checks hunt the request shapes of the public writeup in your own logs; a hit is a lead to investigate, not proof.

• In IIS logs, look for the two-step signature: a POST to a page with RadImageEditor or RadEditor followed by a request to Telerik.Web.UI.WebResource.axd carrying type=iec and a dkey parameter. Legitimate image editing also uses this handler, so weight the pair, not the single request.
• Look for POST requests to Telerik.Web.UI.DialogHandler.aspx from unauthenticated sessions, the dialog endpoint the RCE path forges parameters for.
• Compare web.config and the web root against a known-good copy: unexpected .aspx files, new handlers or machineKey changes are the writeup's post-exploitation artifacts.
• Treat the keys as exposed on any site that ran a vulnerable version with a static machineKey or a custom DialogParametersEncryptionKey and cannot rule out the read. There is no fingerprint that distinguishes a read of an image from a read of web.config in the handler's responses.

Timeline

• 2026-07-28: Tanto Security reports the findings to Progress through its security disclosure channel; Progress acknowledges receipt the same day.
• 2026-07-31: Progress provides a patched build for validation and review.
• 2026-08-01: Tanto Security confirms the file read is fixed and reports that the upload remains reachable with the dialog key.
• 2026-08-12: Progress releases the fixed version, 2026.3.812 (2026 Q3), urging customers to upgrade through the critical security bulletin.
• 2026-09-02: Progress publishes the CVEs and the knowledge-base advisories for both flaws.
• 2026-10-27: Tanto Security publishes the full chain writeup with the request sequence.

FAQ

The fix shipped in August 2026. Why does this matter now?

The public chain documentation landed on October 27, 2026. Any site still on 2026.2.708 or earlier now faces a published, unauthenticated request sequence that reads web.config. The writeup demonstrates the code-execution half against sites with the recommended key settings. Versions of the suite are also hard for scanners to flag without the assembly's file version, so inventory matters.

Is a default installation exposed to remote code execution?

No. The file read works unauthenticated on a default install, but the RCE half needs a static machineKey or a custom DialogParametersEncryptionKey in web.config, neither of which a default install carries. Progress recommends configuring them, which is exactly what makes a site that followed the hardening guidance exposed to the chain.

Did anyone exploit these flaws?

No exploitation is known. The CISA ADP assessment recorded Exploitation "none" for both CVEs on September 2, 2026, and neither appears in CISA's Known Exploited Vulnerabilities catalog as of November 3, 2026. The product line has exploitation history, though: its RadAsyncUpload flaw CVE-2019-18935 has been in that catalog since 2021.

Is there public exploit code?

The writeup publishes the complete request sequence for the read, including the client state payload and the cache-handler request, and describes both code-execution paths in full. Tanto Security ported the ViewState gadget generation into its exploit, but a standalone exploit script has not been released.

Do the other Telerik CVEs from this series matter?

The two writeups in the series reported twelve vulnerabilities in the suite, and Progress patched all of them across 2026.2.708 and 2026.3.812. This post covers the two CVEs Progress chains into unauthenticated RCE, and the vendor's knowledge base carries an advisory for each of the others.

Can I block the handlers instead of upgrading?

You can reduce exposure that way, but the vendor states that filtering the literal request is not a confirmed complete mitigation. Alternate handler mappings, URL encodings and a custom HttpHandlerUrl can bypass a route-based filter. Use the interim measures in "How do I fix it?" and confirm any filtering control with Telerik Support.

Map exposed application surfaces with Ostorlab

Ostorlab's Web Agentic Deep Scan crawls your web applications and maps the surfaces their pages expose, including the handler endpoints and dialogs this chain reaches. Run a scan with Ostorlab to find which applications need the 2026.3.812 upgrade first.

References

• Tanto Security, Marcio Almeida, "From Arbitrary File Read to Shell: Yet Another RCE in Telerik", published October 27, 2026, with the full chain, decompiled code and request sequence: https://tantosec.com/blog/2026/10/telerik-file-read-to-rce/ (checked November 3, 2026)
• Progress Telerik knowledge-base advisory, "RadImageEditor Path Traversal Vulnerability (CVE-2026-18672)", with the affected matrix, the no-mitigation statement and the filtering caveat: https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/kb-security-rie-path-traversal-cve-2026-18672 (checked November 3, 2026)
• Progress Telerik knowledge-base advisory, "DialogHandler UploadPaths Tampering Vulnerability (CVE-2026-19219)", with the vulnerable conditions, CWE-345 and CWE-434, and the interim mitigations: https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/kb-security-dialoghandler-uploadpaths-tampering-cve-2026-19219 (checked November 3, 2026)
• Progress Telerik, "Critical Security Bulletin - RadImageEditor and RadEditor CVE-2026-18672 and CVE-2026-19219 (2026 Q3)", the chain-level impact statement and the per-component fixed matrix: https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/kb-security-radimageeditor-radeditor-rce-chain-bulletin-2026-q3 (checked November 3, 2026)
• CVE-2026-18672 record, Progress CNA, with CVSS v3.1 7.5 and the CISA ADP SSVC block: https://www.cve.org/CVERecord?id=CVE-2026-18672 (checked November 3, 2026)
• CVE-2026-19219 record, Progress CNA, with CVSS v3.1 8.1 and the CISA ADP SSVC block: https://www.cve.org/CVERecord?id=CVE-2026-19219 (checked November 3, 2026)
• Progress Telerik web.config settings overview, the guidance that recommends configuring the encryption keys: https://www.telerik.com/products/aspnet-ajax/documentation/general-information/web-config-settings-overview (checked November 3, 2026)
• ysoserial.net, the .NET deserialization toolkit the writeup used for the ViewState gadget: https://github.com/pwntester/ysoserial.net (checked November 3, 2026)
• CISA Known Exploited Vulnerabilities catalog JSON feed, searched for both CVEs with no match, and for the product line's CVE-2019-18935 history, as of November 3, 2026: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (checked November 3, 2026)