Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2017-8570 (Microsoft Office Remote Code Execution) being…
Threats, Abuse & Incident Response

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

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2017-8570 to its Known Exploited Vulnerabilities catalogue on 25 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 software when it fails to properly handle objects in memory. Any organisation running the affected product should treat remediation as urgent.

What makes CVE-2017-8570 a high-priority exploited Office flaw?

This is not just a theoretical Microsoft Office flaw, it is a confirmed exploitation case, which means defenders should treat any exposed installation as a live risk rather than a future patching task. Because the issue sits in a widely used productivity platform, exposure can exist across endpoints, VDI pools, document workflows and shared file-transfer paths where malicious files enter the environment.

The practical question is whether the vulnerable product is still present anywhere that can open untrusted content. That includes legacy desktops, rarely used finance or legal workstations, and systems that receive documents from external partners. If the product remains reachable, the safe assumption is that an attacker may already have tried to weaponise it.

For broader remediation planning, use the logic in the Zero-Day and Exploited Vulnerabilities Guide to triage this as an active-exploitation event, not a routine software maintenance item.

How exploitation changes the response compared with ordinary patching

Once CISA has placed a vulnerability in the KEV catalogue, the response moves from ordinary vulnerability management to urgent exposure reduction. For this class of issue, the key operational concern is not only whether patching is available, but whether the vulnerable application can still be triggered by user behaviour, email delivery, shared storage, or other document intake paths before remediation is complete.

Microsoft office remote code execution vulnerabilities are especially dangerous because the initial payload can arrive in a normal business document. That means the weak point is often the trust placed in everyday file handling rather than an obvious internet-facing service. Security teams should therefore treat document origin, attachment filtering, and user-opened content as part of the attack surface.

For a control-oriented response path, the Vulnerability Management Guide is the most direct internal reference for prioritisation, exception handling and verification after remediation.

What to check before declaring the risk contained

Containment is not complete when the patch is installed. Teams should verify whether the vulnerable Office version was exposed to suspicious documents before the fix, whether endpoint telemetry shows unusual child processes or Office spawning unexpected executables, and whether document-based delivery paths are still open. In practice, you are looking for signs that a user opened a crafted file before the organisation could respond.

If investigation shows possible exploitation, review the affected host for persistence, unusual outbound connections, and lateral movement from the endpoint. A successful Office RCE rarely ends at code execution alone, it can become the entry point for credential theft, mailbox access, or further malware staging depending on the privileges of the logged-on user.

Because Office document abuse often mirrors malicious deserialisation and object-handling flaws, the Insecure Deserialisation Guide helps explain the common pattern of attacker-controlled objects leading to code execution.

Risk and Threat Considerations

Active exploitation changes the threat model: this is no longer only a software defect, but a proven access path that can be delivered through trusted content channels. The main risk is that an attacker can gain code execution on a user endpoint before defenders notice, then use that foothold for credential theft, malware staging or internal movement.

Failure mechanism: A crafted Office object is parsed unsafely in memory, allowing malicious content to trigger execution in the context of the victim process or user session.

Impact: The result can be endpoint compromise, follow-on payload delivery, data access, and a wider incident if the compromised machine has access to sensitive files or services.

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 governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementCVE-2017-8570 is a live exploited vulnerability needing urgent prioritisation.
CIS-8 — Audit Log ManagementPrior compromise checks rely on logs and endpoint telemetry after suspected exploitation.
CIS-10 — Malware DefensesOffice document exploitation often leads to malware delivery and endpoint compromise.
Recommendation — Prioritise and remediate KEV-listed software exposures before routine backlog items. Retain and review logs to confirm whether the Office flaw was used on affected hosts. Use malware defenses to detect and block malicious files and follow-on payloads.
NIST SP 800-53 Rev 5SI-2 — Flaw RemediationThe flaw requires urgent remediation once exploitation is confirmed by CISA KEV.
AU-6 — Audit Review, Analysis, and ReportingEvidence of compromise must be analyzed after possible exploitation.
Recommendation — Remediate the vulnerable Office software immediately after confirming exposure. Review endpoint and security logs for signs of document-based exploitation.

Practitioner Guidance

What to prioritise: Treat every still-exposed installation as urgent until you have confirmed it is remediated or removed from service. Focus first on endpoints with the highest document exposure, the broadest user privileges, or the greatest connectivity to shared drives and mail systems.

What to verify: Confirm not only that the vulnerable product is patched, but also that your detections cover document-open events, suspicious Office child processes, and post-exploitation behaviour such as unusual process creation or outbound traffic. If you find evidence of execution, move immediately to compromise assessment rather than relying on patch status alone.

Practitioner takeaway: For a KEV-listed Office RCE, the right decision is to assume attempted exploitation is plausible until exposure is removed and the affected endpoints have been checked for signs of prior compromise.

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