Is CVE-2025-22226 (VMware ESXi, Workstation, and Fusion Information Disclosure) being exploited in the wild?

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

For this CVE, the practical question is not whether the bug exists, but whether real attackers are already using it. CISA’s KEV listing answers that operationally: once a vulnerability appears there, defenders should treat it as an active exploitation problem, not a theoretical patch item. For VMware estates, that changes priority from routine maintenance to urgent exposure reduction.

Because the issue is an information disclosure flaw in ESXi, Workstation, and Fusion, the immediate concern is whether confidential data can be exposed from affected hosts or guest workflows. That means the relevant response is to confirm where the product is deployed, determine whether the vulnerable code path is reachable in your environment, and treat any exposed instance as needing rapid remediation.

For a KEV-listed vulnerability, current guidance is to act on the vendor fix or mitigation as soon as possible and to use the CISA KEV entry as the trigger for escalation. The most useful supporting references are the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database, which together help teams confirm record details and track remediation status.

Why this matters operationally

An information disclosure flaw can still be serious even when it does not directly execute code. If the out-of-bounds read leaks sensitive memory content, the impact can include credentials, session material, configuration data, or other data that helps an attacker expand access. That is why active exploitation matters: a disclosure issue can become the first step in a broader compromise chain.

In practice, exploitation pressure is highest when the vulnerable product is widely deployed, internet-facing, or embedded in an environment where administrators assume isolation protects them. For VMware products, the exposure can be especially consequential because virtualization layers often sit close to sensitive infrastructure and privileged operations. The right response is to assume the flaw may already have been probed and to verify that compensating controls are actually limiting blast radius.

If you need a broader response model for active exploitation, the Zero-Day and Exploited Vulnerabilities Guide and the Vulnerability Management Guide both map well to the decisions teams must make when a vulnerability moves from “patch eventually” to “treat as live risk.”

What teams should do next

Start by confirming whether any ESXi, Workstation, or Fusion systems remain in scope, then verify whether those installations are exposed to the vulnerable HGFS path in your environment. If the vendor fix is available to you, prioritise patching on the highest-risk systems first, especially hosts with privileged access, broad trust relationships, or sensitive attached workloads.

If immediate patching is not possible, reduce exposure by isolating affected systems, tightening administrative access, and monitoring for signs that the vulnerability has been exercised. In a KEV case, waiting for a fuller maintenance window is usually the wrong default unless there is a documented and bounded exception with compensating controls.

After remediation, check for earlier compromise rather than assuming patching closes the case. Look for unusual host behaviour, unexpected access, suspicious process activity, and any evidence that sensitive information may have been exposed before the fix. If the affected system handled credentials, tokens, or other secret material, rotate what the vulnerable system could have exposed.

Risk and Threat Considerations

Active exploitation changes the risk profile from isolated product weakness to a live adversary opportunity. For information disclosure flaws, the main threat is not just leakage in the abstract, but the attacker learning enough from memory or process state to support follow-on access, privilege escalation, or lateral movement.

Failure mechanism: An out-of-bounds read can return memory adjacent to the intended buffer, which may reveal sensitive in-process data if the attacker can trigger the vulnerable path reliably.

Impact: Exposure can include secrets, configuration details, or other information that reduces attacker effort on the next stage of compromise, especially in infrastructure that administrators expect to be tightly trusted.

Practitioner Guidance

What to prioritise: Treat KEV inclusion as the trigger for emergency triage, not as a reporting footnote. Confirm whether the vulnerable VMware products are present, whether they are reachable, and whether the systems host data or administrative access paths that raise the consequence of disclosure.

What to verify: Before trusting remediation, verify that the vendor fix or mitigation has actually been applied on every relevant instance, including less visible workstations, lab systems, and offline management assets. Then confirm that any exposed credentials, tokens, or sessions have been assessed for rotation.

Practitioner takeaway: Once a vulnerability is in KEV, the decision is no longer “should we patch soon?”, it is “how fast can we remove exposure and prove we were not already affected?”

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2025-22226 (VMware ESXi, Workstation, and Fusion Information Disclosure)?
• CVE-2025-22226 (VMware ESXi, Workstation, and Fusion Information Disclosure)
• Is CVE-2025-24984 (Microsoft Windows NTFS Information Disclosure) being exploited in the wild?
• Is CVE-2025-22225 (VMware ESXi Arbitrary Write) being exploited in the wild?