Is CVE-2017-0262 (Microsoft Office Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2017-0262 to its Known Exploited Vulnerabilities catalogue on 10 February 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. A remote code execution vulnerability exists in Microsoft Office. Any organisation running the affected product should treat remediation as urgent.

What “exploited in the wild” means for this CVE

For a vulnerability question like this, “exploited in the wild” means there is credible evidence that attackers have already used the flaw against real targets, not just that proof-of-concept code exists. For CVE-2017-0262, the practical takeaway is that exploitation status changes the urgency of response: confirmation in the wild should move the issue into emergency remediation and exposure validation.

Because the question is about active exploitation rather than abstract severity, the right frame is operational triage. A confirmed exploited vulnerability should be treated as a live attack path until the product is removed, patched, or otherwise contained, and that includes checking whether the vulnerable Microsoft Office installation has already been abused before remediation lands. The CISA Known Exploited Vulnerabilities Catalog is the authoritative signal for that status, while the CVE Program provides the vulnerability record itself.

How teams should confirm exposure and prioritise response

The first task is to determine whether any endpoint, VDI image, or user workstation still runs the affected Microsoft Office product and whether it is reachable by the users or workflows that could open untrusted documents. In practice, that means inventorying the deployment, identifying the Office versions in use, and confirming that patching or mitigation has actually been applied rather than merely scheduled. Once a flaw is known to be exploited, incomplete asset visibility becomes a security problem of its own.

Prioritisation should be simple: if the product is present, exposed to document handling, and still unremediated, it belongs at the top of the queue. The NIST National Vulnerability Database is useful for corroborating record details, while the FIRST EPSS can help decide what to tackle first when multiple vulnerabilities compete for attention. Where the vulnerability appears in an environment with high document intake, the urgency is higher because that directly widens the chance of delivery.

What to do if patching cannot happen immediately

If patching must wait, the objective is to reduce the chance that a malicious document can reach the vulnerable Office process and to limit what that process can do if it is triggered. Practical mitigations usually include restricting inbound email attachments, tightening web and mail gateway controls, disabling unnecessary document parsing paths, and isolating users who must handle untrusted content. Temporary compensating controls are only useful if they materially reduce exposure before the next exploit attempt arrives.

When a flaw is already being exploited in the wild, compensating controls should be treated as short-lived risk reduction, not a substitute for remediation. That is why a vulnerability management process should escalate actively exploited vulnerabilities differently from ordinary backlog items, and why remediation SLAs for KEV-listed issues need to be far shorter than routine patch windows. If your environment cannot patch quickly, the remaining question is not whether the issue is serious, but how much blast radius the temporary controls truly remove.

Risk and Threat Considerations

Exploitation in the wild means the vulnerability is not hypothetical. For remote code execution in a widely deployed desktop application, the main risk is that a routine user action, such as opening a crafted file, can become initial access for malware, credential theft, or further lateral movement.

Failure mechanism: An attacker delivers a weaponised document or content path that reaches the vulnerable Microsoft Office code path, triggers code execution, and uses that execution to establish persistence or stage additional payloads.

Impact: The likely consequence is compromise of the user endpoint, followed by secondary exposure such as data theft, malware installation, and expansion into adjacent systems if the workstation has access to sensitive resources.

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 SP 800-53 Rev 5 and NIST CSF 2.0 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 vulnerability discovery and remediation central.
Recommendation — Prioritise KEV-listed flaws and verify remediation on all exposed assets.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The answer centers on urgent remediation of a known exploited software flaw.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation depends on finding vulnerable installations and tracking them.
Recommendation — Patch or mitigate the Office flaw quickly and confirm the fix everywhere. Scan for affected Office installations and track remediation until closed.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and recorded	The question requires identifying vulnerable instances before prioritising response.
	PR.IP-12 — A vulnerability management plan is developed and implemented	The response depends on a process for urgent triage, mitigation, and verification.
Recommendation — Inventory affected endpoints and record every exposed instance for urgent action. Use a formal vulnerability process to accelerate KEV response and validation.

Practitioner Guidance

What to prioritise: Confirm whether the affected Microsoft Office product is installed anywhere in the estate, then rank every exposed instance above non-KEV issues and above vulnerabilities without confirmed exploitation. If the system processes external documents or sits on a privileged user’s workstation, treat it as a faster-path remediation candidate.

What to verify: Do not trust a patch ticket alone. Verify the version, confirm the fix is present on the endpoint, and review whether the system received suspicious documents, macro-like execution, or post-delivery alerts before remediation completed.

Practitioner takeaway: Once a vulnerability is confirmed in the wild, the real decision is not whether it matters, but whether your organisation can remove or contain the attack path before an attacker finds it first.