How do you patch or mitigate CVE-2017-8570 (Microsoft Office Remote Code Execution)?

What patching CVE-2017-8570 should look like in a real estate

The operational goal is simple: verify where Microsoft Office is installed, then apply the vendor update or documented mitigation everywhere that version exists. For this kind of exploited Office flaw, the question is not whether a patch exists somewhere, but whether every reachable copy has been found, scheduled, and confirmed.

That means treating discovery as part of the fix. Office can be present on user workstations, shared machines, VDI pools, and long-lived endpoint images, so a partial rollout leaves a residual attack path even when the headline vulnerability is “patched.”

When you need a broader playbook for actively exploited vulnerabilities, the Zero-Day and Exploited Vulnerabilities Guide covers the triage logic that helps decide when to shift from routine patching to emergency response. The same prioritisation discipline is useful here because CISA placed this issue in the KEV catalogue.

When mitigation has to replace immediate patching

If you cannot apply the update right away, reduce exposure rather than leaving the vulnerable software exposed to the internet or to untrusted content channels. For Office RCE issues, that usually means removing direct internet exposure, tightening email and document handling paths, and taking the product out of service where business impact permits.

Mitigation is only defensible as a temporary state. The longer the gap between discovery and patching, the more you are relying on perimeter controls, user behaviour, and the assumption that hostile documents will not reach a susceptible host.

The same principle appears in Microsoft hardening guidance: use platform controls to narrow attack surface first, then layer identity, mail, and logging protections around the affected workload. The Microsoft 365 Security Guide is a useful companion when Office exposure is tied to tenant, mail, or endpoint pathways rather than a single isolated desktop.

How to confirm you are really done

After patching, validate that the vulnerable Office installation is gone or updated, and then check for signs of prior exploitation. Because this flaw was used in the wild, the post-fix step is not optional: it is how you determine whether the machine was only exposed or also compromised.

Review mail, endpoint, and host telemetry for suspicious document openings, child process creation from Office, unusual script execution, dropped files, and subsequent outbound connections. If the host handled untrusted documents before remediation, treat the patch as one control in a larger compromise assessment rather than as proof of cleanliness.

When you need a broader operational lens on whether the vulnerable software was exploited before the fix landed, the Vulnerability Management Guide is the better reference for verification, exception handling, and remediation tracking. For prioritisation, the CISA Known Exploited Vulnerabilities Catalog is the authoritative source for why this issue should be treated as urgent rather than routine.

Risk and Threat Considerations

Office RCE flaws are attractive because they turn a common document-handling workflow into code execution, often without needing unusual user behaviour. That creates two risks at once: broad exposure across standard productivity software, and a realistic path from document delivery to endpoint compromise.

Failure mechanism: An attacker delivers or lures a target into opening a malicious file that triggers code execution in the vulnerable Office component, then uses the resulting access to run payloads, persist, or stage follow-on activity.

Impact: A single unpatched instance can become an entry point for malware installation, credential theft, lateral movement, or further exploitation inside the environment, especially if the host has access to shared data or trusted internal systems.

The NIST public vulnerability records, together with the CVE program, are useful here because they anchor the issue to a specific software flaw and remediation pathway rather than leaving it as an abstract “Office problem.” The NIST National Vulnerability Database and the CVE Program are the right places to verify the canonical record before you act on local guidance.

Practitioner Guidance

What to prioritise: Patch every reachable Office installation first, then focus on the endpoints most likely to have processed external documents or email attachments before remediation. Those systems deserve the earliest compromise check because they are the most plausible initial access points.

What to verify: Confirm that the vendor update or mitigation was applied to all Office instances, not just to managed endpoints. If a device was unreachable during rollout, treat it as still exposed until you have a positive installation check.

Decision rule: If patching is delayed, remove the exposed system from direct internet-facing use or isolate the affected application path until the fix is in place. If the host cannot be confidently isolated, assume the risk remains active and escalate the exception.

Practitioner takeaway: For an exploited Office RCE, the real finish line is not “patch deployed,” but “patched, exposure reduced, and prior compromise ruled out.”

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2017-11826 (Microsoft Office Remote Code Execution)?
• How do you patch or mitigate CVE-2009-0238 (Microsoft Office Remote Code Execution)?
• How do you patch or mitigate CVE-2007-0671 (Microsoft Office Excel Remote Code Execution)?
• How do you patch or mitigate CVE-2017-8543 (Microsoft Windows Search Remote Code Execution)?