Is CVE-2025-22224 (VMware ESXi and Workstation TOCTOU Race Condition) being exploited in the wild?

Yes. CISA added CVE-2025-22224 to its Known Exploited Vulnerabilities catalogue on 4 March 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. VMware ESXi and Workstation contain a time-of-check time-of-use (TOCTOU) race condition vulnerability that leads to an out-of-bounds write. Any organisation running the affected product should treat remediation as urgent.

What “being exploited in the wild” means for this CVE

CISA’s KEV listing is the practical signal that this vulnerability has moved beyond theory. For defenders, that means the question is no longer whether exploitation is possible, but whether the affected VMware ESXi or Workstation systems are exposed, reachable, and already showing signs of compromise. Treat the KEV entry as a trigger for immediate triage, not as a routine vulnerability notice.

For a race condition in virtualization software, the security concern is operational as much as technical. An attacker who can reliably hit the timing window may be able to turn a logic flaw into memory corruption and then into broader system impact, so exposure review should focus on internet-facing management paths, exposed admin interfaces, and any host that is difficult to patch quickly. CISA Known Exploited Vulnerabilities Catalog is the authoritative place to confirm that status.

How to confirm exposure and decide what matters first

Start by identifying every ESXi and Workstation deployment, then separate externally reachable hosts from isolated lab or desktop use. The highest-risk systems are the ones that are both vulnerable and operationally important, because a successful exploit against a hypervisor or workstation can create a fast path to system-level impact. If you do not have an accurate inventory, the right response is to build one before you assume the risk is contained.

For version and product specifics, defer to the vendor advisory and the KEV record rather than trying to infer safety from generic patch status. A system may look current at the OS layer and still remain exposed if the virtualization component itself has not been updated or if a compensating control is missing. Authoritative CVE reference data is best checked through the CVE Program and the NIST National Vulnerability Database.

What to do if patching cannot happen immediately

If remediation must wait, reduce exposure instead of hoping the flaw will remain unexploited. The practical levers are isolation, access restriction, and monitoring. Limit administrative reach to the smallest possible set of trusted management sources, remove unnecessary exposure from public networks, and watch for unusual hypervisor instability, unexpected crashes, or changes in host behavior that do not fit the normal maintenance pattern.

When a KEV-listed flaw affects a platform that hosts many workloads, the response priority is usually higher than for a single endpoint vulnerability. Even if the exploit is not tied to ransomware, successful compromise of a virtualization layer can have broad blast radius, which is why virtual infrastructure teams should treat the issue as an urgent remediation item and coordinate with operations before a maintenance window becomes an incident window.

Risk and Threat Considerations

This vulnerability matters because active exploitation against a hypervisor or local workstation platform can turn one successful race-condition trigger into outsized impact. The main risk is not just initial code execution, but the possibility that an attacker gains a high-value foothold in infrastructure that supports many other systems.

Failure mechanism: A TOCTOU race condition means the software checks a condition and then uses the result after state has changed. In security-sensitive code, that gap can let an attacker influence memory operations in a way that produces out-of-bounds write behaviour and potential compromise.

Impact: Once a flaw at this layer is being exploited in the wild, defenders should assume real-world targeting, faster chaining attempts, and a materially shorter response window. The most important consequence is not the CVE label itself, but the possibility of host compromise before the patch cycle catches up.

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	Active exploitation makes rapid identification and remediation central.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Limiting exposure and hardening management paths reduces exploitability.
Recommendation — Prioritise exposed VMware assets for immediate remediation and verified exception tracking. Restrict management exposure and harden VMware hosts until fixes are confirmed.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management Plan	The question is about exploited vulnerability handling and urgent remediation.
Recommendation — Use the vulnerability management process to accelerate triage, patching, and exposure review.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A KEV-listed CVE requires rapid flaw remediation and validation.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and post-remediation validation depend on scanning and monitoring.
Recommendation — Accelerate remediation and confirm affected systems are actually updated. Scan for affected VMware systems and verify remediation status before closing the risk.

Practitioner Guidance

What to prioritise: Triage by exposure first, then by business criticality. Internet-reachable or management-reachable hosts deserve immediate attention because they combine exploitability with higher operational impact.

What to verify: Confirm the exact affected VMware product is present, confirm whether the host is still reachable from untrusted networks, and confirm whether the remediation path has actually been applied rather than merely planned. A patch ticket is not the same as a remediated system.

What to measure: Track time from KEV notice to containment, and time from containment to verified remediation. For this class of issue, those two intervals matter more than a generic vulnerability count.

Practitioner takeaway: When a hypervisor or workstation flaw appears in KEV, treat “exploited in the wild” as an operational assumption for triage purposes and move immediately to exposure reduction, compromise checks, and verified remediation.