CVE-2017-11317 is an ASP.NET unrestricted file upload vulnerability in Telerik User Interface (UI) for ASP.NET AJAX. CISA added it to the Known Exploited Vulnerabilities catalogue on 11 April 2022, which means attackers have used it in real attacks.
What this vulnerability means in practice
An unrestricted file upload flaw in a web application framework can let an attacker submit content the application should never accept, then place it where the server processes or serves it. In products built around web forms, that often turns a simple upload feature into a path for persistence, code execution, or deeper compromise.
That is why this class of vulnerability is dangerous even before you know the exact payload. Once an attacker can store a file on the server, the next step may be to trigger it, reuse it, or combine it with another weakness in the application or hosting stack.
Why it is dangerous in Telerik UI for ASP.NET AJAX
This CVE affects Telerik UI for ASP.NET AJAX, so the risk is not just “a bad upload form”, but a trusted web component embedded in an ASP.NET application. If upload handling is reachable, the flaw can become a reliable foothold inside otherwise normal business applications, especially when the uploaded content lands in a web-accessible location.
The practical concern is that attackers often look for framework-level weaknesses because they scale across many deployments. A single exposed component can affect many applications, and a successful upload may bypass the application logic that developers assumed was enforcing file type or content restrictions.
For authoritative version and patch details, use the vendor advisory and the NIST National Vulnerability Database, rather than relying on secondary summaries.
How organisations check exposure and reduce blast radius
Exposure checks start with an accurate asset inventory: which applications use Telerik UI for ASP.NET AJAX, where the upload feature is enabled, and whether any instance is internet-facing. That inventory should be paired with vendor advisories and vulnerability scanning so teams can separate real exposure from theoretical exposure.
If patching is delayed, compensating controls matter. Organisations should restrict access to upload endpoints, place uploaded content outside executable paths where possible, enforce strict server-side validation, and monitor for unexpected file creation or execution in web directories. Vulnerability Management Guide is useful here because the key question is not just whether the CVE exists, but whether the vulnerable component is deployed, reachable, and prioritised correctly.
When the upload feature is business-critical, reduction of blast radius is as important as the patch itself. That means treating the vulnerable application as a potential entry point, not just a standalone bug.
Detection, compromise review, and identity impact
Detection should look for signs that uploaded files were used as a delivery mechanism, not merely that a request succeeded. Review web logs, file-system events, and application logs for unusual upload names, double extensions, unexpected content types, and follow-on requests to newly created files. Post-patch review should also check whether the server was already touched before remediation.
If exploitation is confirmed or strongly suspected, rotate any credentials, session material, keys, or service account secrets that could have been accessed from the compromised application host. That includes secrets stored in configuration files, deployment pipelines, or adjacent services the application could reach. The initial weakness is a file upload flaw, but the business impact often comes from what the attacker can do after they land.
Risk and Threat Considerations
Unrestricted file upload flaws are attractive because they can convert a routine application feature into arbitrary server-side control. In a widely deployed web component, that creates a straightforward attack path from public input to internal execution or persistent access.
Failure mechanism: An attacker supplies a file the application accepts but should reject, then uses the uploaded content, its location, or a follow-on processing step to gain code execution, webshell-style persistence, or another foothold.
Impact: Successful exploitation can expose application data, enable lateral movement, and force incident response work that goes well beyond the original web application.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | File upload abuse is prevented by validating inbound content before processing. |
| SI-3 — Malicious Code Protection | Uploaded payloads may carry executable content or web shells that require code protection controls. | |
| CM-7 — Least Functionality | Restricting exposed application functions limits the attack surface for vulnerable upload features. | |
| Recommendation — Validate uploaded content server-side before accepting or storing it. Scan and block suspicious uploaded files before they can be executed or served. Disable unnecessary upload paths and reduce exposed application functionality. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This CVE requires asset discovery, prioritisation, and remediation tracking across deployed instances. |
| Recommendation — Inventory affected applications and prioritise remediation using vulnerability management processes. | ||
| OWASP ASVS | V5 — File Handling | The flaw is an insecure file upload condition in a web application component. |
| Recommendation — Apply file-handling requirements to restrict types, storage, and execution of uploaded files. | ||
Practitioner Guidance
Why practitioners should care: Treat this CVE as a deployment-risk issue, not only a patching issue. The practical question is whether the vulnerable Telerik component is present on an exposed system and whether upload handling can reach executable or sensitive paths.
What to watch for: Look for anomalous upload behaviour, unexpected file creation under web roots, and any post-upload requests to newly added files. If the application was internet-facing, assume compromise review may be needed even after patching.
Practitioner takeaway: Remediate the vulnerable instance, validate that upload paths and execution boundaries are separated, and confirm that no credentials or sessions were exposed during the exploitation window.
Related resources from NHI Mgmt Group
- CVE-2017-9248 (Progress Telerik UI for ASP.NET AJAX and Sitefinity Cryptographic Weakness)
- CVE-2017-11357 (Telerik UI for ASP.NET AJAX Insecure Direct Object Reference)
- CVE-2021-20022 (SonicWall Email Security Unrestricted Upload of File)
- CVE-2021-26828 (OpenPLC ScadaBR Unrestricted Upload of File with Dangerous Type)