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

What should you do first when CVE-2017-11826 is in scope?

Start with exposure discovery, because the right fix depends on where Microsoft Office is installed and how it is used. The practical goal is to find every affected instance, confirm which systems can reach untrusted content, and then apply the vendor update or documented mitigation everywhere you can. For this kind of exploited Office flaw, CISA’s Known Exploited Vulnerabilities Catalog is the authoritative operational reference for why this issue needs urgent handling.

Inventory matters here because partial patching leaves a mixed estate: a secured desktop next to an unpatched shared workstation, RDS host, or VDI image can still provide an entry point. If the product is deployed in a way that cannot be patched quickly, your decision is not to wait for perfect remediation, but to reduce attack surface immediately and plan a controlled removal from service if needed.

How do you mitigate it if patching is delayed?

If the security update cannot be applied right away, the safest mitigation is to make exploitation harder by removing internet exposure and limiting how the vulnerable Office installation can receive or open hostile content. In practice, that means tightening ingress paths, restricting user workflows that accept untrusted documents, and isolating the affected host so a drive-by delivery route is no longer available. The NIST National Vulnerability Database and the vendor advisory should be used together to confirm the exact remediation guidance for your environment.

When no acceptable mitigation exists, taking the product out of service is a valid security decision. That is especially true for older Office deployments or systems that cannot be updated without breaking business functions. The mitigation goal is not just to reduce likelihood, but to remove the reachable attack path entirely until the supported fix can be deployed.

What should you check after remediation?

After patching or isolating the system, review logs and telemetry for signs that the flaw was already abused before the fix landed. Because this vulnerability was used in the wild, post-remediation validation should include document-open activity, unusual child processes, suspicious network connections, and any evidence that Office launched commands or loaded content that should not have executed. The broader vulnerability handling workflow described in the Zero-Day and Exploited Vulnerabilities Guide is directly relevant to that hunting phase.

Do not stop at “patched” as a completion criterion. If you find evidence of exploitation, treat the event as a compromise investigation, not a patching task, and expand your review to adjacent hosts, user accounts, and any documents or email chains that may have carried the initial payload.

Risk and Threat Considerations

This vulnerability matters because Microsoft Office is a high-frequency user entry point, so exploitation can scale quickly across an enterprise once a malicious document or delivery path reaches a user. The main risk is not only code execution, but the speed with which a successful exploit can become a foothold for follow-on access, persistence, or internal spread.

Failure mechanism: An attacker delivers a crafted Office file or lures a user into opening malicious content on an unpatched system, then uses the resulting code execution to run payloads in the user context and expand access.

Impact: The compromise can lead to malware installation, credential theft, lateral movement, or further exploitation of internal systems, especially when Office runs on a connected workstation with broad user access.

Practitioner Guidance

What to prioritise: Patch all reachable Office installations first, then focus on systems that routinely handle external documents, shared mailboxes, shared workstations, and remote-access endpoints. Those are the places where exploitation pressure is highest and where a delayed fix creates the most exposure.

What to verify: Confirm that the vendor update or documented mitigation is actually present on each host, not just approved for deployment. If a system cannot be patched, verify that the compensating control really removes exposure, rather than merely reducing it.

Practitioner takeaway: For exploited Office CVEs, the right sequence is exposure discovery, urgent remediation, and compromise checking, because successful defense depends on both closing the vulnerability and proving it was not already used.

Related resources from NHI Mgmt Group

• 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)?
• How do you patch or mitigate CVE-2017-0148 (Microsoft SMBv1 Server Remote Code Execution)?