How do you patch or mitigate CVE-2021-38646 (Microsoft Office Access Connectivity Engine Remote Code Execution)?

CISA’s required action for CVE-2021-38646 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.

How to patch Microsoft Office Access Connectivity Engine safely

Start by locating every installed copy of Microsoft Office Access Connectivity Engine and any Office deployment that includes it, then apply the vendor security update exactly as Microsoft documents it. For estates that cannot patch immediately, reduce exposure by removing internet-facing paths and limiting where the product can be reached until the fix is in place. Zero-Day and Exploited Vulnerabilities Guide

Because CVE-2021-38646 is an active exploitation case, the operational question is not only whether the update exists, but whether every reachable instance has actually been covered. Missing one installation on a long-lived workstation, terminal server, or published application host can leave the same exploit path open even after the main fleet is patched.

When patching is blocked by application compatibility or change windows, treat the product as a temporary exposure problem. Disable unnecessary access routes, remove public reachability, and be explicit about the business owner’s acceptance of residual risk until the update or retirement action is complete.

What to check before and after remediation

Before you declare this issue closed, confirm inventory, exposure, and logging coverage. You want to know where Microsoft Office Access Connectivity Engine exists, whether any affected host is externally reachable, and whether your logs retain enough history to investigate earlier exploitation if the system was exposed before remediation.

After patching, review endpoint, application, and authentication logs for signs of abnormal execution, suspicious child processes, or user sessions that do not fit normal Office usage. If the vulnerable software was internet-exposed, treat the patch as the start of validation, not the end of the incident response question.

A useful habit is to tie remediation to asset scope rather than the existence of a single update bulletin. That helps catch cloned images, golden desktops, published servers, and “temporary” installs that often escape one-off patch campaigns. Vulnerability Management Guide

When mitigation is the only immediate option

If you cannot patch right away, your priority is to shrink attack surface quickly enough that exploitation becomes materially harder. For this kind of exploited Microsoft Office flaw, that usually means isolating the affected software from untrusted networks, removing unnecessary publishing, and accelerating retirement or replacement where the product is no longer essential.

Mitigation should be treated as a time-bounded exception, not a substitute for remediation. The longer the exception lasts, the more important it becomes to document who approved it, what compensating control is in place, and when the environment will be rechecked for patch completion or decommissioning.

For teams that need a reference point for emergency response discipline, the broader pattern is to triage exploited vulnerabilities by exposure and exploitability first, then verify closure with post-patch hunting. CISA Known Exploited Vulnerabilities Catalog and FIRST EPSS

Risk and Threat Considerations

This flaw matters because actively exploited Office RCEs are high-value initial access paths. If the vulnerable component is internet-reachable or reachable through a user workflow that accepts untrusted content, an attacker may be able to run code on the host before defenders notice normal-looking Office activity.

Failure mechanism: An attacker triggers the vulnerable Office component through a crafted file, document, or workflow, causing code execution on a system that still trusts the application path or user action.

Impact: Successful exploitation can lead to endpoint compromise, credential theft, lateral movement, and follow-on deployment of additional payloads before the vulnerability is remediated.

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

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Directly supports finding and fixing exposed software quickly.
Recommendation — Prioritise vulnerable Office hosts and verify remediation across the full asset inventory.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Covers applying vendor fixes and managing known exploited flaws.
	AU-6 — Audit Review, Analysis, and Reporting	Supports post-patch log review for signs of earlier exploitation.
Recommendation — Apply vendor remediation promptly and track exception handling until closure. Review logs after remediation to confirm whether the flaw was abused before patching.
OWASP ASVS	V13 — Configuration	Relevant to reducing exposure when patching must wait.
Recommendation — Remove or restrict exposed deployment paths until the fix is installed.

Practitioner Guidance

What to prioritise: Patch every exposed or business-critical Office installation first, then move to lower-risk internal endpoints. If a host cannot be patched immediately, treat it as a temporary exception and narrow its exposure until it can be remediated or removed.

What to verify: Confirm that remediation covered all delivery methods, including standard installs, packaged images, and any system where Office components were added later. Afterward, validate that logs are available to support a compromise check if the host was exposed before patching.

Practitioner takeaway: For exploited Office vulnerabilities, closure is not just “the update was deployed”, it is “every reachable instance was covered and earlier compromise was checked.”