Is CVE-2017-0022 (Microsoft XML Core Services Information Disclosure) being exploited in the wild?

Yes. CISA added CVE-2017-0022 to its Known Exploited Vulnerabilities catalogue on 24 May 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft XML Core Services (MSXML) improperly handles objects in memory, allowing attackers to test for files on disk via a crafted web site.

What “exploited in the wild” means for a KEV-listed CVE

For a CVE like CVE-2017-0022, the practical question is not whether a proof of concept exists, but whether defenders should treat it as an active exposure. Once a vulnerability appears in CISA’s Known Exploited Vulnerabilities catalogue, the working assumption should be that real-world exploitation is already happening and that exposure management has become urgent, not theoretical.

That is why CISA KEV is useful for triage. The catalogue is a prioritisation signal built around observed exploitation, so it helps separate “known but dormant” issues from vulnerabilities that warrant immediate attention in patch queues, compensating controls and compromise checks. Use the vendor advisory for product-specific remediation details, then use KEV status to drive urgency and internal escalation.

What this means operationally for exposure and remediation

The immediate task is to confirm whether the affected product is present anywhere in your environment, including legacy systems, development or test assets, externally reachable hosts and forgotten instances that may not appear in normal ownership records. For internet-facing systems, the threshold for action is lower because exploitation of a known target can happen quickly once public scanning and weaponisation converge.

If patching is delayed, the next-best move is to reduce the reachable attack surface around the vulnerable component, limit exposure to only the business workflows that genuinely need it, and increase monitoring for suspicious requests or unusual file and network access around the affected service. That is especially important for flaws that can be tested remotely without obvious authentication noise.

Why this kind of vulnerability can matter even when the impact looks narrow

Information disclosure vulnerabilities are often underestimated because they do not always look like full compromise. In practice, a small leak can still help an attacker confirm file presence, map local state, or refine a follow-on exploit path. That makes the issue more than a privacy concern, because reconnaissance value can be enough to support chained attacks.

Zero-Day and Exploited Vulnerabilities Guide is useful here because it covers the same operational pattern: treat KEV-listed issues as exploit-now problems, not score-only problems. The same triage logic also appears in Vulnerability Management Guide, which focuses on prioritisation, exceptions, verification and remediation discipline for actively exploited vulnerabilities.

For this page, the practical lesson is that “can an attacker learn something useful?” is enough to justify urgent handling when the flaw is already being exploited in the wild. Disclosure bugs should be assessed for their role in discovery, chaining and pre-compromise intelligence, not only for whether they directly produce code execution.

Risk and Threat Considerations

When a vulnerability is already in KEV, the main risk is not just direct exploitation, but the speed with which attackers can incorporate it into mass scanning and chained intrusion paths. Even limited disclosure can support targeting, validation, or later-stage exploitation, especially on systems that are exposed to the internet or poorly inventoried.

Failure mechanism: Attackers use the flaw to observe file or system state through crafted requests, then combine that information with other weaknesses, weak configuration, or exposed services to move from reconnaissance into compromise.

Impact: The likely outcome is increased exposure to follow-on intrusion, faster exploitation of weak assets, and delayed containment if defenders treat the issue as informational rather than security-critical.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0 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	KEV-listed CVEs require continuous prioritisation and remediation of known exploited weaknesses.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities first.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	Determining exposure to an exploited CVE depends on identifying vulnerable assets and their reachability.
	PR.IP-12 — Vulnerability Management	Active exploitation makes remediation timing and compensating controls central to the response.
	DE.CM-01 — Network Monitoring	Exploited-in-the-wild vulnerabilities justify monitoring for probing and exploitation attempts.
Recommendation — Inventory affected assets and validate exposure to the vulnerable component. Accelerate remediation and document any temporary compensating controls. Monitor traffic and logs for exploitation attempts against the vulnerable service.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	KEV status calls for scanning, validation, and tracking of a known exploited vulnerability.
Recommendation — Scan for the CVE and track remediation until exposure is eliminated.

Practitioner Guidance

What to prioritise: First confirm whether any instance of the affected Microsoft component is present, reachable, and still supported. If you have multiple vulnerable systems, prioritise the ones that are externally accessible, business-critical, or difficult to monitor closely.

What to verify: Do not stop at patch state. Verify that the vulnerable service is not still exposed through alternate hosts, legacy images, or forgotten test systems, and confirm whether logs show unusual probing around the disclosure vector before remediation.

Decision rule: If patching must wait, treat compensating controls as temporary risk reduction only. The moment the system can be patched or retired, the exception should close, because KEV status means the exposure is already in active attacker use.

Practitioner takeaway: A KEV-listed disclosure flaw should be handled as an active exploitation problem, with inventory, reachability and post-exposure validation taking priority over abstract severity debates.