Is CVE-2024-37085 (VMware ESXi Authentication Bypass) being exploited in the wild?

Yes. CISA added CVE-2024-37085 to its Known Exploited Vulnerabilities catalogue on 30 July 2024, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. VMware ESXi contains an authentication bypass vulnerability. Any organisation running the affected product should treat remediation as urgent.

Why CISA’s KEV Listing Matters for This VMware ESXi Flaw

For a vulnerability like CVE-2024-37085, the practical question is not whether the flaw exists, but whether there is evidence it is being used against real systems. CISA’s KEV catalogue is the strongest public signal that exploitation is active, and its ransomware flag raises the urgency further because the issue is no longer theoretical or limited to lab reproduction.

That is why the right response is exposure confirmation, then immediate containment planning. The relevant control path is to compare your ESXi estate against the vendor advisory and the KEV entry, then treat any confirmed exposure as a live remediation item, not a routine vulnerability backlog entry. See the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database for authoritative record details.

When a system is in KEV, the main operational risk is delay. Attackers do not need to discover the bug first, because exploitation pressure is already established, and ESXi sits at a high-value infrastructure layer that can affect many workloads at once. That makes rapid remediation materially different from ordinary patch planning, especially where virtualisation hosts are shared, difficult to reboot, or protected by change windows that slow response.

What You Should Verify Before You Assume You Are Safe

Start by verifying whether any ESXi hosts are actually deployed, whether they are internet-facing, and whether they are reachable from trust zones that an attacker could use after foothold elsewhere. The important distinction is not just “installed or not,” but “exposed, reachable, and still susceptible under current configuration.”

Then verify whether the environment has compensating controls that would meaningfully reduce exposure if patching is delayed, such as strict management-plane isolation, blocked administrative access, and monitored access paths. If you cannot confirm those conditions, you should assume the host is at elevated risk until proven otherwise.

For a KEV-listed authentication bypass, it is also worth checking for indicators that the management plane was accessed unexpectedly before remediation began. If an attacker obtained unauthorised access, the immediate question becomes whether they used that access to stage persistence, modify management settings, or move toward other systems on the same infrastructure.

How to Respond When Remediation Cannot Happen Immediately

The first decision is whether to patch or remove exposure by isolation. If you cannot remediate at once, reduce the attack surface around the host, tighten administrative reachability, and treat the system as a potential compromise candidate rather than a known-good asset. The goal is to limit both further exploitation and post-bypass lateral movement.

For vulnerable infrastructure that supports many virtual machines, response should also include a plan for operational continuity. A host that must stay online may need temporary segmentation, closer monitoring, and accelerated maintenance scheduling so the organisation can reduce risk without creating a larger outage through rushed change.

After the fix is applied, validate that the host is no longer exposed in practice, not just in theory. That means confirming the effective configuration, checking for suspicious management activity during the exposure window, and reviewing adjacent systems that may have been reachable from the same control plane.

Risk and Threat Considerations

Authentication bypass on a hypervisor is dangerous because it can turn a single weakness into broad infrastructure exposure. If attackers can reach the management plane, they may be able to control multiple workloads, harvest credentials or session material, and use the host as a stepping stone to wider enterprise compromise.

Failure mechanism: The flaw weakens the trust boundary around ESXi administration, allowing unauthorised access where the organisation expects authentication to block entry. Once that boundary is broken, the attacker can focus on persistence, privilege escalation, or downstream access to other managed systems.

Impact: The practical consequence can include ransomware staging, service disruption, and cross-system compromise, especially when the same administrators, networks, or management tooling are shared across many hosts.

Standards & Framework Alignment

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

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and recorded	KEV-listed ESXi exposure requires identifying vulnerable hosts and recording them.
Recommendation — Inventory exposed ESXi hosts and track the vulnerable instances until remediation is complete.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes prioritisation, remediation and verification central to the response.
Recommendation — Prioritise and remediate the ESXi vulnerability using an urgency-based vulnerability management process.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue requires prompt remediation and validation of corrective action.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and ongoing scanning are needed to find affected ESXi systems.
Recommendation — Apply flaw remediation promptly and verify the ESXi fix is effective after deployment. Scan the environment for affected ESXi hosts and monitor for residual exposure.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	A KEV-listed flaw is a technical vulnerability requiring prioritised treatment and tracking.
Recommendation — Treat the ESXi flaw under a formal technical vulnerability management process and document remediation.

Practitioner Guidance

What to prioritise: Treat KEV-listed infrastructure bugs as exposure-management problems first and patch-management problems second. If the host is reachable, business-critical, or shared across many systems, its remediation priority should rise above ordinary backlog ordering.

What to verify: Confirm the exact ESXi estate, the exposed management paths, and whether any administrative activity occurred during the likely exploitation window. If patching is delayed, document the compensating controls that actually reduce exploitability, not just the planned ones.

Escalation / exception: If you cannot remediate promptly, escalate the host as a potential incident candidate and not merely a vulnerable asset. A KEV listing with ransomware relevance is a strong signal to accelerate review of logs, management access, and adjacent systems.

Practitioner takeaway: For an actively exploited ESXi authentication bypass, the right question is not “can we schedule a patch,” but “what else must we assume may already be exposed if this host was reachable?”