Yes. CISA added CVE-2021-38646 to its Known Exploited Vulnerabilities catalogue on 28 March 2022, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Microsoft Office Access Connectivity Engine contains an unspecified vulnerability which can allow for remote code execution. Any organisation running the affected product should treat remediation as urgent.
What this CVE answer is really telling you
This question is not just asking whether a flaw exists, it is asking whether you should treat the issue as an active exploitation problem. The practical conclusion is that the product should be assumed exposed until proven otherwise, and that triage should focus on where the software is deployed, whether it is internet reachable, and whether patching or mitigation has already happened.
For defenders, the key distinction is between a vulnerability that is merely published and one that has entered the exploitation lifecycle. Once a CVE appears in the CISA KEV catalogue, the response posture changes from normal patch planning to urgent exposure validation, remediation, and compromise review. A good starting point is CISA's own guidance in the CISA Known Exploited Vulnerabilities Catalog and the underlying CVE record in the CVE Program.
Because the answer identifies remote code execution, this is not a reporting-only issue. Remote code execution means the flaw can become an initial foothold, not just a reliability concern, so the operational question becomes whether the vulnerable product is present anywhere in the environment and whether that exposure can be reached from user-controlled input or external traffic.
How to interpret exploitation in the wild for this product
“Exploited in the wild” means more than proof-of-concept code or theoretical risk. It means defenders should assume real attackers have a reason to scan for it, weaponise it, and chain it into follow-on activity. That changes priority because exploitation can begin before an internal patch window closes, especially on widely deployed desktop or application components.
For Microsoft Office Access Connectivity Engine specifically, the immediate concern is reachability through normal business workflows. If the component is installed on endpoints, servers, or application hosts that process untrusted files or content, exposure may exist even where the product is not visibly front-facing. That is why inventory, not just patch state, is the first control to verify.
The most useful next step is to validate whether the vulnerable component is actually present, then map where it can be invoked, and then decide whether the affected systems can be isolated or accelerated for remediation. The Zero-Day and Exploited Vulnerabilities Guide is useful here because it frames KEV status, emergency response, and post-patch hunting as one workflow rather than separate tasks.
What urgent remediation looks like when the CVE is active
Once active exploitation is confirmed, the remediation path is straightforward in principle: remove the vulnerable condition, reduce exposure until the fix is in place, and verify whether compromise occurred before the patch. If the affected software is business critical, temporary containment may be needed, but it should be treated as a short bridge to full remediation rather than a long-term workaround.
When patching must wait, the priority is compensating control, not reassurance. That can include restricting which systems can open or process the triggering content, segmenting access to the affected hosts, tightening monitoring around unusual Office-related process execution, and preserving evidence before making disruptive changes. If the product is used in a sensitive environment, review whether a broader credential or session reset is warranted after remediation if there are signs the host was reached.
The practical lesson from Vulnerability Management Guide is that KEV-listed issues should be triaged by exploitability and business exposure, not by abstract severity alone. For this kind of issue, verification of remediation and exception handling matter as much as the patch itself.
Risk and Threat Considerations
Actively exploited remote code execution flaws are attractive because they compress the attacker’s work. A successful exploit can turn ordinary document or application handling into arbitrary execution, which can then lead to payload delivery, persistence, credential access, or lateral movement depending on the endpoint and the surrounding controls.
Failure mechanism: The vulnerable component processes attacker-influenced input in a way that permits execution of code on the host, so normal business use becomes the trigger path for compromise.
Impact: An exposed system may be used for initial access, malware deployment, data theft, or as a stepping stone into more privileged parts of the environment, especially if the host has broad user trust or network reach.
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.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed exploitation requires urgent identification and remediation of exposed assets. |
| Recommendation — Prioritise and remediate the exposed vulnerable software immediately. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The answer depends on finding affected installations and confirming exposure before attack use. |
| SI-2 — Flaw Remediation | Active exploitation makes prompt flaw remediation the core control response. | |
| IR-4 — Incident Handling | Possible in-the-wild exploitation requires compromise review and evidence preservation. | |
| Recommendation — Scan for the affected component and verify exposure across the estate. Apply the vendor fix or approved mitigation without delay. Investigate for pre-remediation compromise and preserve relevant artefacts. | ||
Practitioner Guidance
What to verify: Confirm where Microsoft Office Access Connectivity Engine is installed, which systems can invoke it, and whether those systems were patched or otherwise remediated after the KEV listing. Do not rely on software inventory alone, verify actual exposure paths.
Decision rule: If the component exists on a reachable host, treat the system as urgent for patching or containment; if the host also handled sensitive documents, external content, or privileged workflows, elevate the compromise review priority.
What to prioritise: First exposure inventory, then remediation, then compromise assessment. If there is any sign the host was accessed during the active exploitation window, preserve logs and artefacts before you make broad changes that could destroy evidence.
Practitioner takeaway: KEV status is the signal to move from ordinary vulnerability management to exploit-driven response, and for an RCE flaw that means verifying exposure, remediating fast, and checking for prior compromise in the same motion.
Related resources from NHI Mgmt Group
- CVE-2021-38646 (Microsoft Office Access Connectivity Engine Remote Code Execution)
- Is CVE-2021-1647 (Microsoft Defender Remote Code Execution) being exploited in the wild?
- Is CVE-2021-31166 (Microsoft HTTP Protocol Stack Remote Code Execution) being exploited in the wild?
- Is CVE-2020-1350 (Microsoft Windows DNS Server Remote Code Execution) being exploited in the wild?
Deepen Your Knowledge
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.
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