How do you patch or mitigate CVE-2018-0802 (Microsoft Office Memory Corruption)?

CISA’s required action for CVE-2018-0802 is to apply updates per vendor instructions. In practice, find every instance of Microsoft Office in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What actually changes when you patch CVE-2018-0802?

The practical objective is to remove the vulnerable Office code path from every reachable system, not just to “install a patch.” That means validating where Microsoft Office is deployed, applying the vendor update or documented mitigation, and confirming that users cannot still reach the vulnerable build through stale images, unmanaged laptops, or long-lived virtual desktops.

When a fix cannot be applied immediately, the exposure question becomes whether the affected Office installation can still be reached from the internet or from untrusted content sources. If so, the risk stays live even if the product is not your most visible business application. Microsoft Office is often present on endpoints that also hold mail, browser, and collaboration access, so one unpatched instance can still become a viable initial access point.

For prioritisation and emergency response, use the same discipline you would use for any actively exploited vulnerability: inventory the product, confirm exposure, apply the update, and then verify closure rather than assuming the patch succeeded. The Zero-Day and Exploited Vulnerabilities Guide is useful here because it treats KEV-listed issues as operational response problems, not just patch tickets, and the CISA Known Exploited Vulnerabilities Catalog is the authoritative place to confirm whether the issue is being handled as an exploited vulnerability.

How should you verify exposure and close the gap safely?

The first check is simple: identify every Microsoft Office installation that could receive hostile content, whether through email, document sharing, browser download, or lateral access from another user context. If you only patch the “standard” corporate build and miss older images, offline systems, or contractor endpoints, the vulnerability remains present in practice.

Where patching is delayed, the most useful mitigation is to reduce the attack surface around the affected software. That may mean isolating the host, removing unnecessary internet reachability, restricting document sources, or temporarily taking the product out of service if business operations allow it. The decision should be based on whether the vulnerable application can still be triggered by ordinary user activity, not just on whether it is formally installed.

Authoritative version and product details should come from the vendor advisory and the KEV catalogue, while exploitability triage can be sharpened with NIST National Vulnerability Database, CVE Program, and CISA Known Exploited Vulnerabilities Catalog. Together they help you confirm the record, the vulnerability identity, and the operational urgency without guessing.

What should you do after patching or mitigation?

After remediation, check for signs that the vulnerability was used before you closed it. Review endpoint and email telemetry, Office crash or application logs where available, and any suspicious child processes, script launches, or document-open activity around the exposure window. If the environment handled suspicious documents, treat the question as possible prior compromise, not merely as a successful patch event.

Where the fix was delayed, the investigation should be broader. Document the timeframe during which the vulnerable version was reachable, identify users or systems that could have opened attacker-controlled content, and look for post-exploitation activity that would outlast the original exploit. A single vulnerable Office host is often enough to justify incident-style review because the compromise path can begin with normal document handling and then pivot into credential theft or follow-on execution.

The Vulnerability Management Guide is helpful for turning that review into a repeatable process, especially the parts on asset scope, verification, exceptions, and remediation measurement. In a case like CVE-2018-0802, those controls matter more than a one-time patch because they show whether the vulnerable software was actually removed from service everywhere it mattered.

Risk and Threat Considerations

This flaw matters because exploited Office vulnerabilities are often used for initial access, and the real risk is not limited to a single workstation. If a user can open hostile content on an unpatched host, attackers may gain a foothold that leads to code execution, follow-on payload delivery, or later credential and session abuse.

Failure mechanism: The vulnerable Office code path is still reachable through an unpatched installation or an inadequate mitigation, allowing crafted content to trigger memory corruption before defenders have removed the exposure.

Impact: The result can be remote compromise of the endpoint, suspicious document-driven execution, and a credible path to broader environment access if the host holds valuable user context or connected credentials.

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	CVE patching and KEV-driven remediation are continuous vulnerability management tasks.
Recommendation — Prioritise and verify remediation for exploited Office vulnerabilities across the estate.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management Plan	The question is about operational patching, mitigation, and verification of a known exploited flaw.
	DE.CM-09 — Continuous Monitoring for Unauthorized Software and Activity	Post-patch review for exploitation depends on monitoring endpoint and application activity.
Recommendation — Track remediation, exceptions, and verification under a formal vulnerability management plan. Monitor for suspicious Office activity and validate whether exploitation occurred before remediation.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The response requires finding exposed Office instances and confirming remediation status.
	SI-2 — Flaw Remediation	Applying vendor updates and documented mitigations is direct flaw remediation.
Recommendation — Scan for vulnerable Office installations and confirm remediation against authoritative sources. Apply the vendor update or mitigation and document exception handling until closure.

Practitioner Guidance

What to prioritise: Patch or isolate the instances that are actually reachable by users first, especially internet-connected endpoints and systems that process external documents. A dormant installation is lower priority than a live endpoint that regularly opens mail attachments or shared files.

What to verify: Do not trust the patch ticket alone. Verify the Office version, confirm the mitigation is in place, and check that the vulnerable build is gone from gold images, unmanaged devices, and any remote-access or VDI estate.

Practitioner takeaway: Treat CVE-2018-0802 as an exposure-management problem as much as a patching problem: the fix is only complete when the vulnerable Office path is removed, the reachability is reduced, and the environment is checked for prior abuse.