Is CVE-2017-11357 (Telerik UI for ASP.NET AJAX Insecure Direct Object Reference) being exploited in the wild?

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

Yes. CISA added CVE-2017-11357 to its Known Exploited Vulnerabilities catalogue on 26 January 2023, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Telerik UI for ASP.NET AJAX contains an insecure direct object reference vulnerability in RadAsyncUpload that can result in file uploads in a limited location and/or remote code execution.

How this vulnerability behaves in practice

CVE-2017-11357 is not just a vulnerability label, it is an exploitation path that can let an attacker abuse how RadAsyncUpload handles object references. When an application exposes the vulnerable component, the practical question is whether an unauthorised party can influence upload handling enough to reach file placement or code execution. That is why confirmed exploitation matters more than the abstract classification.

For readers evaluating exposure, the key issue is whether the application still exposes Telerik UI for ASP.NET AJAX and whether the upload workflow is reachable from untrusted input. If the vulnerable path is present, treat it as an application compromise risk rather than a narrow validation flaw. For broader context on the pattern of exploited bugs and triage pressure, Zero-Day and Exploited Vulnerabilities Guide explains how to prioritise actively abused issues.

Authoritative confirmation should come from the vendor advisory and the CISA KEV catalogue, not from guesswork about version numbers or exposure windows. In practice, that means verifying whether the product instance is present, whether RadAsyncUpload is enabled, and whether any compensating controls actually block the vulnerable request path.

What active exploitation means for response timing

Once a vulnerability appears in KEV, the response problem changes. You are no longer asking whether a future patch is prudent, you are asking how quickly you can remove a known attack path before it is used again. That matters because exploited web application flaws often move from initial access to payload staging very quickly, especially when the flaw can influence file uploads or server-side execution.

If patching must wait, the fallback is to reduce exposure immediately: restrict access to the application, isolate the affected endpoint, and apply any vendor mitigation that meaningfully blocks the upload or reference abuse path. For teams that need a structured triage path, Vulnerability Management Guide covers KEV-based prioritisation, exception handling, and verification after remediation.

Because this is a known-exploited issue, any delay should be treated as a business decision with security consequences, not as a routine patch queue item. The practical test is simple: if the vulnerable application remains reachable, assume it is an active target until you have either remediated it or materially reduced its reachable attack surface.

What to check for after exposure or compromise

When exploitation is suspected, look beyond the CVE itself and ask what the attacker could have done through the upload path. That can include dropped files, web shells, changed application behaviour, unusual new binaries, or signs that code execution happened after the upload step. Review web logs, file integrity signals, and any post-upload process execution paths that should not normally be reachable.

If the application accepted attacker-controlled content before detection, preserve evidence first and then determine whether the server, adjacent services, or downstream data stores were touched. The response should also include searching for lateral movement from the web tier, because a server-side execution flaw can be an entry point rather than the final objective. For deeper read-across on exploitation mechanics, ASP.NET machine key attacks 2025 shows how web exploitation can persist through server-side trust material.

Where evidence shows actual file placement or code execution, rotate any credentials, tokens, or application secrets that the exposed server could have accessed, and check whether the compromise altered application configuration or persistence settings. If compromise is confirmed, recovery should include rebuilding trust in the host rather than only applying the fix.

Risk and Threat Considerations

Exploited web application vulnerabilities are attractive because they can convert a public endpoint into server-side execution or file-write capability. In this case, the risk is not limited to data exposure, because the vulnerable upload path can become a foothold for deeper compromise, persistence, or ransomware staging.

Failure mechanism: An attacker abuses the insecure direct object reference in RadAsyncUpload to influence upload handling, place files in a restricted location, or reach remote code execution if the environment and request path allow it.

Impact: The compromise can lead to web shell deployment, application takeover, lateral movement, data theft, or follow-on ransomware activity, which is why CISA KEV status materially changes the urgency of response.

Standards & Framework Alignment

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

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

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes rapid identification and remediation of exposed software central.
Recommendation — Prioritise and remediate KEV-listed exposure with continuous vulnerability tracking and verification.
OWASP ASVS	V8 — Authorization	The issue is an IDOR in upload handling, so object access checks are central to the failure.
	V5 — File Handling	The vulnerability can affect file upload placement and server-side file handling.
	V16 — Security Logging and Error Handling	Post-exploitation review depends on logs and telemetry showing suspicious upload and execution activity.
Recommendation — Enforce server-side object ownership checks before accepting upload-related actions. Validate, constrain, and isolate upload handling to prevent attacker-controlled file placement. Log upload events and security-relevant failures so exploitation can be investigated quickly.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	KEV status turns ongoing exposure management into an immediate vulnerability monitoring priority.
Recommendation — Track exploited vulnerabilities and confirm remediation of exposed instances without delay.

Practitioner Guidance

What to verify: Confirm whether any internet-reachable or partner-reachable instance of Telerik UI for ASP.NET AJAX is still in service, and verify that the vulnerable upload path is either removed, patched, or effectively blocked. If you cannot prove that the path is closed, treat the system as exposed.

Decision rule: If logs or endpoint telemetry show suspicious upload activity, unexpected file creation, or follow-on command execution, move immediately to compromise assessment before you spend time on clean-up. If there is no patch window, isolate the application and apply the strongest available mitigation first.

Practitioner takeaway: For KEV-listed web flaws, the key judgement is not whether exploitation is possible in theory, but whether the vulnerable request path is still reachable and observable in your environment.

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