Is CVE-2022-21971 (Microsoft Windows Runtime Remote Code Execution) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2022-21971 to its Known Exploited Vulnerabilities catalogue on 18 August 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Windows Runtime contains an unspecified vulnerability that allows for remote code execution. Any organisation running the affected product should treat remediation as urgent.

What “exploited in the wild” means for this CVE

The key practical question is not whether the flaw exists, but whether it has crossed from theoretical exposure into active abuse. For this advisory, CISA’s KEV listing is the operational signal that matters because it reflects evidence of real exploitation, not just vendor disclosure or lab proof. That changes the response from normal patch planning to urgent exposure reduction and verification.

When a Windows runtime remote code execution issue is already being exploited, the first task is to identify every system that can still reach the vulnerable component. If the environment spans multiple Windows estates, treat the problem as an asset-scoping exercise, not a single patch ticket.

For a broader response pattern around actively exploited flaws, the Zero-Day and Exploited Vulnerabilities Guide is the right internal starting point because it frames KEV-driven triage, emergency mitigation, and post-patch hunting as one workflow.

How to confirm exposure and close the gap

Confirmation should start with inventory, then move to remediation status, then to compensating controls. In practice, that means checking which Windows hosts are in scope, whether the affected component is present on those hosts, and whether patch deployment has actually reached them. Do not rely on a change record alone; verify on the endpoint or through your patch telemetry.

If patching is delayed, reduce the attack window immediately. That usually means isolating high-risk endpoints, tightening remote access paths, and increasing monitoring for suspicious child processes, unexpected launches, or other signs that remote code execution may already have occurred. The objective is to make exploitation harder while the fix is pending, not to wait for full maintenance windows.

Use authoritative references for version and mitigation details rather than reproducing them from memory. The vendor advisory tells you what must be fixed, while the CISA Known Exploited Vulnerabilities Catalog tells you why the issue should be prioritised ahead of routine backlog work.

For a disciplined remediation workflow, the Vulnerability Management Guide provides the triage logic practitioners need when KEV status, remediation SLAs, and exception handling all have to be aligned.

What to look for after patching or mitigation

Because the issue is remote code execution, patching is only one part of the response. You also need to ask whether the host was exposed long enough for an attacker to use it before the fix landed. That is especially important if the endpoint handled sensitive admin activity, was internet reachable, or sat on a trust path into more valuable systems.

Look for evidence of post-exploitation rather than only the initial exploit signal. Review recent process creation, unusual script execution, new services, scheduled tasks, unexpected outbound connections, and any credential or token access that occurred around the time the weakness was publicly active. If the host was used interactively or had privileged sessions, assess whether adjacent accounts or sessions should be reset.

Where Windows administration tooling is part of the normal operating model, the PowerShell Security Guide is a useful companion because it helps distinguish legitimate administration from suspicious post-exploitation activity and reinforces the logging that makes that distinction possible.

Risk and Threat Considerations

Actively exploited remote code execution flaws are dangerous because they collapse the normal boundary between user context and system control. Once exploitation succeeds, an attacker can often pivot from a single reachable host into persistence, lateral movement, or credential access, especially where the endpoint has administrative exposure or weak monitoring.

Failure mechanism: The vulnerability can be triggered remotely, which means an exposed Windows host may be compromised before defenders complete normal patch cycles. If the host is already trusted inside the network, the attacker can turn that first foothold into broader access.

Impact: The likely consequence is unauthorized code execution on affected systems, followed by possible data theft, service disruption, or use of the host as a staging point for deeper compromise. If the system supports privileged workflows, the blast radius can expand quickly.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	CVE exploitation requires timely remediation and verified rollout across Windows hosts.
Recommendation — Prioritise and verify remediation of the vulnerable Windows Runtime flaw across all in-scope systems.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The issue is KEV-listed, so prioritised vulnerability handling and exception control are central.
Recommendation — Use KEV status to drive urgent prioritisation, tracking, and exception management for exposed hosts.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	Active exploitation makes vulnerability prioritisation and remediation part of the core response.
	DE.CM-01 — Networks and network services are monitored to find potentially adverse events	Exploited RCEs require monitoring for compromise indicators during the exposure window.
Recommendation — Apply vulnerability management processes that accelerate mitigation of known exploited flaws. Monitor for signs of exploitation and suspicious activity on exposed Windows systems.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Remote exploitation of an exposed service or component follows a known adversary pattern.
Recommendation — Map exposure to likely initial-access techniques and hunt for follow-on activity.

Practitioner Guidance

What to prioritise: Prioritise externally reachable or business-critical Windows systems first, then any host with administrative reach or sensitive local data. Those are the systems where exploitation creates the largest downstream security problem.

What to verify: Verify remediation at the endpoint, not just in ticketing. You want evidence that the vulnerable condition is gone and that the host did not show signs of suspicious activity during the exposure window.

Decision rule: If patching cannot happen immediately, treat the system as potentially compromised until proven otherwise, and narrow access until validation is complete.

Practitioner takeaway: For a KEV-listed RCE, the right question is not “is there a patch plan?”, but “has exposure been removed, and do we have enough evidence to trust the host again?”

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.

NHIMG Editorial Note
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