Is CVE-2017-9248 (Progress Telerik UI for ASP.NET AJAX and Sitefinity Cryptographic Weakness) being exploited in the wild?

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

Yes. CISA added CVE-2017-9248 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Any organisation running the affected product should treat remediation as urgent. Check exposure first, then patch or mitigate, then review logs for signs of earlier compromise.

What “exploited in the wild” means for CVE-2017-9248

For a vulnerability like CVE-2017-9248, “in the wild” is the operational threshold that matters most: it means the issue has moved from theoretical exposure to observed attacker use. CISA’s KEV listing is the clearest public signal that exploitation has been seen and that remediation should be treated as urgent, not scheduled into a normal backlog.

That does not tell you whether every deployment is affected, but it does tell you the risk posture has changed. The practical question becomes whether your specific environment contains the vulnerable product and whether any internet-facing or broadly reachable instance has already been exposed long enough for abuse to occur.

How to confirm whether you are actually exposed

Start with product inventory, not patch tickets. Confirm whether Progress Telerik UI for ASP.NET AJAX or Sitefinity is present anywhere in production, test, partner-facing, or legacy web estates, including forgotten applications that may still be reachable through old URLs, load balancers, or archived servers.

If the product is present, determine whether the vulnerable component is reachable from the network path an attacker could use. For web-exposed flaws, check whether the application is directly reachable, proxied, embedded in another service, or exposed through an undocumented administrative path. Keep in mind that exposure can persist even when the application is no longer actively maintained by the original team.

Useful confirmation evidence includes asset inventory records, deployment manifests, package references, web server mappings, and any change history that shows when the component last changed. If you cannot confidently prove absence, treat the system as exposed until you can.

What to do when patching or mitigation cannot wait

The right order is exposure confirmation, then fix or mitigation, then validation. If the vendor fix is available to you, apply it as soon as change control permits. If you cannot patch immediately, reduce reachable attack surface by restricting access, removing public exposure, and disabling or isolating the affected application path until remediation is complete.

For vulnerabilities that are already in KEV, compensating controls should be treated as temporary risk reduction only. They are useful when they buy time, but they do not change the fact that exploitation is known to exist. Track the exception as a short-duration item with an owner, a deadline, and a verification step so it does not become a permanent workaround.

Because this issue involves cryptographic weakness, also review whether the application may have exposed or enabled abuse of sensitive material such as tokens, sessions, or protected configuration values. If compromise is plausible, plan for credential or secret rotation where those values could have been touched by the vulnerable service.

Risk and Threat Considerations

The main risk is that exploitation may have occurred before defenders realised the application was exposed. For KEV-listed issues, attackers often act faster than patch cycles, so the presence of the vulnerable component should trigger both remediation and compromise checks, not just a software update.

Failure mechanism: The vulnerable web component can be reached and abused before the organisation has patched or isolated it, allowing attacker activity to begin without obvious user-visible failure.

Impact: A successful compromise can expose data, enable further web-based intrusion, or leave attacker-controlled changes behind even after the vulnerability is fixed.

Standards & Framework Alignment

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

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require inventory, prioritization, and rapid remediation.
Recommendation — Prioritize the KEV-listed flaw for immediate remediation and verification.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This question is about confirming exposure and responding to a known exploited vulnerability.
	SI-2 — Flaw Remediation	KEV-listed exploitation makes timely flaw remediation central to the response.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-exploitation review depends on logs and audit evidence to spot earlier compromise.
Recommendation — Scan for the vulnerable component and track remediation until exposure is removed. Apply the vendor fix or mitigation as soon as change control allows. Review logs and alerts for indicators of pre-patch compromise.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	The page is about handling a known exploited vulnerability and urgent remediation.
Recommendation — Treat the KEV-listed issue as an urgent technical vulnerability and close it quickly.

Practitioner Guidance

What to verify: Verify three things in sequence: that the vulnerable product exists, that it is reachable, and that the environment has no sign of pre-patch compromise. If you only verify patch status, you may miss an already-breached system.

Decision rule: If the system is internet-facing or supports sensitive business functions, treat KEV status as a remediation priority over routine maintenance work. If patching must be delayed, document the compensating control and an explicit end date for the exception.

Common mistake: Teams often stop at “the vendor fixed it” and skip log review. For an actively exploited flaw, that misses the possibility that the real problem is no longer exposure but persistence.

Practitioner takeaway: KEV inclusion should change the workflow, not just the severity label, first prove exposure, then remove the vulnerability, then assume compromise until logs and host evidence show otherwise.

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 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org