Is CVE-2019-18935 (Progress Telerik UI for ASP.NET AJAX Deserialization of Untrusted Data) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2019-18935 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Progress Telerik UI for ASP.NET AJAX contains a deserialization of untrusted data vulnerability through RadAsyncUpload which leads to code execution on the server in the context of the w3wp.exe process.

How to tell when a CVE is actually being exploited

The practical test is whether an authoritative source has confirmed active exploitation, not whether the vulnerability sounds dangerous. For CVE-2019-18935, the key signal is CISA’s KEV listing, because KEV entries represent vulnerabilities with reliable evidence of real-world abuse. That makes the question about operational exposure, not just theoretical severity.

When a vulnerability is in KEV, teams should treat internet exposure, public-facing applications, and any system reachable by untrusted users as immediate scope for review. The relevant question is whether the vulnerable component is deployed anywhere in the estate, whether it can be reached remotely, and whether exploit conditions exist in production or staging.

For this class of issue, the right starting point is Zero-Day and Exploited Vulnerabilities Guide, which ties KEV status to emergency prioritisation, compromise assessment, and post-patch validation. The same operational logic applies here: if the flaw is in a reachable web stack, assume it belongs at the front of the remediation queue.

Why deserialization flaws are high-risk in web application stacks

Progress Telerik UI for ASP.NET AJAX uses a deserialization path that can be abused through RadAsyncUpload, and that kind of flaw is dangerous because deserialization happens before normal business logic can safely constrain the input. Once an attacker can influence object construction, the outcome can shift from application error to server-side code execution.

That risk is especially severe when the vulnerable component sits inside a web application process such as w3wp.exe, because compromise can inherit the privileges, network reach, and data access of the hosting application. The issue is not merely malformed input, it is trusted processing of attacker-controlled data in a place where code execution is possible.

Insecure Deserialisation Guide is the most relevant internal reference for understanding why object injection, gadget chains, and unsafe deserialization are so often exploited for remote code execution. For defenders, the important point is that a deserialization bug should be treated as a code-execution candidate until proven otherwise.

What to do when the exploit is already in the wild

When active exploitation is confirmed, patching alone is only half the response. Teams should first confirm exposure, then apply the vendor fix or mitigation from the advisory, and then look for signs that the system was already accessed before the update was applied. That sequence matters because KEV-listed flaws are often exploited quickly after disclosure.

If patching cannot happen immediately, reduce exposure by removing the affected component from internet-facing paths, restricting access to the application, and increasing monitoring around the host and the web process. A vulnerable application that must stay online should be treated as a temporary exception with explicit ownership and a short expiry.

Where the vulnerable path can execute code, post-exploitation review should include process creation, web shell indicators, unusual child processes from the application pool, and unexpected outbound connections from the host. If the application handled credentials, sessions, or secrets, those should be rotated as part of the cleanup decision rather than left unchanged.

Vulnerability Management Guide is useful here because it ties KEV-driven triage to exception handling, verification, and remediation metrics. For a live exploit, the point is not just to close the ticket, but to prove the asset is no longer exploitable and was not previously compromised.

Risk and Threat Considerations

Once a deserialization flaw is being used in the wild, the main risk is not abstract vulnerability presence but rapid transition from web request to code execution. That creates a direct path to application takeover, data access, lateral movement, and in some cases ransomware staging if the host can reach other internal systems.

Failure mechanism: Attacker-supplied data is deserialized by the application before adequate validation, allowing crafted objects or gadget chains to trigger server-side execution in the web worker context.

Impact: The vulnerable server may be used for persistence, credential theft, payload deployment, or broader compromise of the application and its adjacent systems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	Exploit status depends on knowing whether the vulnerable app is deployed and reachable.
	PR.DS-01 — Data-at-Rest Protection	Code execution can expose application data and stored secrets on the host.
	DE.CM-01 — Networks and Network Services Monitored	Active exploitation calls for monitoring for suspicious web and host activity.
Recommendation — Inventory the exposed Telerik deployment and assess whether the vulnerable path is reachable. Protect sensitive application data and secrets on affected servers. Monitor affected web servers for unusual process and network activity.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	KEV-listed exploitation requires rapid remediation of the vulnerable component.
	SI-4 — System Monitoring	Post-exploitation review depends on detecting suspicious host and web activity.
Recommendation — Patch or mitigate the Telerik vulnerability without delay. Increase monitoring for suspicious activity on the affected host.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-driven prioritisation is a vulnerability management problem with active exploitation.
	CIS-13 — Network Monitoring and Defense	Exploitation in the wild warrants heightened monitoring and containment.
Recommendation — Prioritise and remediate the KEV-listed vulnerability immediately. Detect suspicious traffic and web exploitation attempts on exposed systems.

Practitioner Guidance

What to verify: Confirm whether the Telerik component is present, whether the RadAsyncUpload path is reachable, and whether the host has any indicators of prior execution or suspicious child processes. Do not rely on inventory alone if the application has not been actively tested for exposure.

Decision rule: If the system is internet-facing or handles untrusted uploads, treat KEV status as a remediation emergency and prioritise it ahead of routine backlog work. If patching must wait, formalise the exception, reduce access, and increase detection coverage until the fix is deployed.

Practitioner takeaway: For KEV-listed exploitation, the right question is not whether the CVE is serious, but whether the vulnerable code is still reachable and whether the host has already been touched.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org