CVE-2017-11357 is an ASP.NET insecure direct object reference vulnerability in Telerik User Interface (UI) for ASP.NET AJAX. CISA added it to the Known Exploited Vulnerabilities catalogue on 26 January 2023, which means attackers have used it in real attacks.
What this vulnerability means in practice
An insecure direct object reference in a web application means the application exposes internal object identifiers, then trusts the caller to only request data or actions it should already be allowed to reach. In ASP.NET AJAX applications, that can turn a routine page or component request into an access-control failure if the server does not revalidate ownership or scope.
The danger is not the identifier itself, but the assumption behind it. If an attacker can guess, enumerate, or reuse a reference, they may reach records, configuration data, or privileged functionality without needing to defeat the login step first.
Why this class of flaw is dangerous
IDOR issues are especially harmful in interactive web applications because the exposed object often sits behind normal application traffic, not a clearly suspicious exploit path. That makes them attractive when attackers want quiet access rather than noisy code execution.
For a vulnerability that has already appeared in real-world exploitation, the operational concern is that exposure can persist across many deployed instances and may be invisible to owners who only check whether the application is up to date. A page like this should be read alongside the vendor advisory and the NIST National Vulnerability Database record for version and product detail, and the CVE Program entry for the canonical identifier.
How organisations check exposure
Exposure review starts with asset inventory: identify every internet-facing and internally reachable application that uses Telerik UI for ASP.NET AJAX, then determine whether that application exposes object identifiers in request parameters, component calls, or hidden state. If the product appears anywhere in the estate, treat the application as potentially affected until the vendor guidance and deployment state are confirmed.
Teams should also look for indirect exposure, such as reverse proxies, shared hosting, staging environments, and forgotten admin portals. A vulnerable component does not need to be public to matter, but public exposure increases the chance of discovery and abuse.
When triaging, pair the product advisory with vulnerability management workflows so the issue is tracked as an exposure problem, not just a line item in a scanner report. NHIMG’s Vulnerability Management Guide is useful here because it frames prioritisation around asset scope, KEV status, verification, and remediation ownership.
Remediation, detection, and post-compromise review
Definitive remediation depends on the vendor’s fixed versions and guidance, but organisations should not wait passively if patching is delayed. Compensating controls usually mean reducing exposure, tightening access paths, and monitoring for unusual object access patterns or abuse of the affected endpoint.
Detection should focus on requests that enumerate IDs, repeat similar calls at scale, or access objects outside the expected user context. After patching, review logs for prior misuse, because exploitation may have been used to read data, modify application state, or harvest content for later abuse.
If exploitation is suspected, assess whether the issue exposed application secrets, session material, or privileged workflow data that could enable follow-on compromise. For broader context on how object-reference weaknesses sit inside web application attack chains, see the Web Application Attacks Guide.
Risk and Threat Considerations
Object-reference flaws are dangerous because they often bypass the application’s intended authorisation model rather than attacking the login system directly. An attacker who can predict or alter a reference may reach data or functions that should have been limited by ownership, role, or tenant boundaries.
Failure mechanism: The server accepts a caller-supplied object reference without rechecking whether that caller is entitled to the specific resource, so access control becomes dependent on the obscurity of the identifier.
Impact: Attackers can read or manipulate records they should not see, and in some applications that creates a path to fraud, data leakage, or further privilege escalation through exposed internal state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | IDOR is an object-level authorisation failure in web applications. |
| V16 — Security Logging and Error Handling | Reviewing exploitation depends on log coverage for unusual object access and failed checks. | |
| Recommendation — Enforce object-level checks on every request that resolves a user-supplied identifier. Log access denials and anomalous object lookups so abuse can be reviewed after patching. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The vulnerability can expose access beyond the minimum required privilege. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-compromise review relies on analysing audit records for suspicious object access. | |
| Recommendation — Restrict each role and workflow to the minimum objects it must access. Review audit records for unusual or cross-account object access after remediation. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Direct object access must be governed as an access-control issue across the application estate. |
| Recommendation — Govern application access paths so users can only reach objects they are authorised to use. | ||
Practitioner Guidance
Why practitioners should care: Treat IDOR risk as an authorisation defect, not a UI quirk. The fix is to enforce object-level checks on every request path that resolves a user-controlled identifier, including APIs, callbacks, and AJAX endpoints.
What to watch for: Any endpoint that behaves correctly when tested with one account but reveals another user’s data when the object ID changes needs immediate review. Verification should include both normal and edge-case workflows, because these flaws often hide in “helper” endpoints that were never designed as direct user entry points.
Practitioner takeaway: If the application can locate an object from a request parameter, it must also prove the caller is allowed to reach that exact object every time.
Related resources from NHI Mgmt Group
- CVE-2017-9248 (Progress Telerik UI for ASP.NET AJAX and Sitefinity Cryptographic Weakness)
- How should security teams prevent insecure direct object reference vulnerabilities in web applications?
- Insecure Direct Object Reference
- Why do insecure ASP.NET applications create such a broad risk surface for data breaches and unauthorized actions?