Is CVE-2025-22225 (VMware ESXi Arbitrary Write) being exploited in the wild?

What it means when a VMware ESXi CVE is in CISA KEV

A KEV listing is the practical signal that this is no longer just a theoretical vulnerability. For defenders, the important question is not whether the CVE exists, but whether the exposed ESXi estate can be reached, identified, and remediated fast enough to stay ahead of exploitation. KEV status should trigger emergency validation, not routine backlog handling.

For a platform like ESXi, that means confirming whether the vulnerable hypervisors are internet-facing, reachable from less-trusted administrative networks, or embedded in shared virtualisation stacks where compromise has high blast radius. In this situation, the product layer and the management plane both matter, because attackers rarely need broad foothold to cause major operational impact.

Because CISA also associates this CVE with ransomware campaigns, the operational priority is to treat the issue as an active intrusion risk, not just a patching item. That changes the response sequence: exposure confirmation, emergency change control, remediation, and compromise review should move together rather than one after the other.

Why arbitrary write flaws on hypervisors are treated as urgent

An arbitrary write in a hypervisor is dangerous because it can undermine one of the strongest trust boundaries in the environment. If an attacker can write where they should not, they may be able to corrupt memory, alter execution flow, destabilise the host, or prepare deeper control of the virtualisation layer.

That matters because ESXi sits at the point where one compromise can affect many guest systems at once. When the vulnerable host supports multiple workloads, the real exposure is not just a crashed server, but a possible path to broad service disruption, data loss, and follow-on access to adjacent systems and administrative tooling.

In practice, the urgency is driven by blast radius and attacker efficiency. A single exploited host can produce outsized impact compared with compromising an ordinary endpoint, which is why Zero-Day and Exploited Vulnerabilities Guide is a useful reference for triage, emergency mitigation, and post-patch hunting when exploitation is already happening in the wild.

What defenders should verify before and after remediation

First confirm exposure by inventorying the exact ESXi systems in scope, then map where management access is exposed and which hosts are business-critical. If patching or mitigation has to wait, isolate the most exposed systems, restrict administrative reach, and raise monitoring around the virtualisation management layer.

Next assume compromise is possible if the vulnerable hosts were reachable during the exploitation window. That means checking for unexpected changes to host configuration, unusual processes or binaries, suspicious log patterns, and any signs that management credentials or adjacent administrative sessions may have been abused.

This is also the point to compare the vulnerable estate against your broader vulnerability workflow, because prioritisation depends on speed as much as severity. The Vulnerability Management Guide is relevant here because it ties KEV, exposure, exceptions, and verification into a response process that actually closes risk instead of just recording it.

Risk and Threat Considerations

This kind of flaw is attractive to attackers because hypervisors concentrate valuable workloads, credentials, and operational control in one place. If an arbitrary write is successfully exploited, the attacker may gain a foothold that is harder to detect and more damaging than a single host compromise.

Failure mechanism: The vulnerability can let an attacker overwrite memory or execution state on ESXi, which may be used to gain control, disable protections, or set up persistence on the host.

Impact: The likely consequences are host compromise, wider virtual machine exposure, service disruption, and ransomware-ready conditions where one exploited platform unlocks multiple downstream systems.

Practitioner Guidance

What to prioritise: Treat KEV-listed ESXi exposure as an emergency, and prioritise the hosts that are internet-reachable, centrally managed, or support the most critical workloads. If those systems cannot be patched immediately, containment and compensating controls should come first.

What to verify: Validate whether the management plane was exposed during the likely exploitation window, and preserve logs before they roll over. On a hypervisor, you need enough evidence to answer two questions: was the host reachable, and did anything on the host change in ways that suggest attacker activity?

Practitioner takeaway: For exploited hypervisor flaws, the key decision is not whether patching is desirable, but whether you can still trust the host enough to keep it online while you fix it.

Related resources from NHI Mgmt Group

• CVE-2025-22225 (VMware ESXi Arbitrary Write)
• Is CVE-2025-21043 (Samsung Mobile Devices Out-of-Bounds Write) being exploited in the wild?
• Is CVE-2025-21042 (Samsung Mobile Devices Out-of-Bounds Write) being exploited in the wild?
• Is CVE-2024-37079 (Broadcom VMware vCenter Server Out-of-bounds Write) being exploited in the wild?