CVE-2024-37085 – Immediate Action Guide for VMware ESXi AD Authentication Bypass

What breaks and who should care

If your VMware ESXi host is configured to use Active Directory (AD) for user management, you may be looking at an authentication bypass that lets a malicious actor with enough AD rights take full control of the host. The vulnerability is identified as CVE-2024-37085. Anyone running ESXi with AD integration should stop what they’re doing and read on.

Related remediation guides

Other vulnerabilities in the same family or affecting the same products:

• CVE-2025-22225 – VMware ESXi arbitrary write vulnerability – what you need to know at 2 am
• CVE-2025-29927 – Critical Next.js Authorization Bypass – Immediate Action Required
• CVE-2026-35273 – Critical PeopleSoft PeopleTools Authentication Bypass

For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.

Technical overview

VMware’s ESXi includes a feature that maps AD groups to ESXi permission roles. By default the group called ESXi Admins is granted full administrative rights on the host. The flaw lies in how ESXi treats the existence of that group. If the group is deleted in AD, ESXi continues to remember its name but not its members. An attacker who can recreate the group in AD – which only requires a modest level of AD permission – can then add themselves as a member. ESXi will accept the new group as the trusted admin group and grant the attacker full host access without any further authentication.

The vulnerability is classed as an authentication bypass. The underlying code does not re‑validate the group’s SID after it has been recreated, so the host trusts a stale reference. The exact implementation details have not been released publicly; VMware’s advisory simply notes the logic error.

Because the issue is confirmed to have been used in ransomware campaigns, the impact is not theoretical. An adversary who gains AD rights – for example through a compromised service account – can silently elevate to ESXi administrator and then move laterally or encrypt virtual machines.

How bad is it?

The Common Vulnerability Scoring System gives this flaw a score of 6.8, which places it in the medium severity range. The score reflects the need for AD permissions, but the real‑world impact is higher because those permissions are often easier to obtain than full ESXi credentials. Once an attacker has host‑level rights they can install tools, modify VMs, or destroy data. The fact that the vulnerability has been observed in the wild and is listed in the CISA Known Exploited Vulnerabilities catalog means you should treat it as an urgent priority.

Am I affected?

Two conditions must be true for your environment to be vulnerable:

• Your ESXi host is running a version that predates the vendor’s security update for this issue (see the table below for the exact range).
• You have AD authentication enabled and the default admin group – or a custom group serving the same purpose – is configured.

If either condition does not apply, the vulnerability does not affect you. For example, a host that only uses local users, or one that has already been patched, is safe.

To verify the first condition, run the following command on the ESXi shell or via SSH:

esxcli system version get

This returns the build information for the host. Compare the output with the entries in the table below – any build listed as affected means you need to act.

To check the second condition, look at the authentication configuration file:

/etc/vmware/hostd/config.xml

Search for a line containing auth.AD.enabled set to true. If you see that, AD integration is active. You can also query the AD group that ESXi trusts with the following PowerShell command on a domain‑joined management workstation:

Get-ADGroup -Identity "ESXi Admins"

If the group exists, note its members – any unexpected accounts may be a sign of compromise.

Mitigation steps

There are three practical paths to protect yourself:

• Apply the vendor security update. VMware has released a patch that corrects the group‑validation logic. Upgrade to the patched release for your branch – the table below marks the fixed state. The upgrade process is the same as any other ESXi update: place the host in maintenance mode, upload the offline bundle, and run esxcli software vib install -v /path/to/patch.zip. After the host reboots, verify the version again with esxcli system version get.
• Temporarily disable AD authentication. If you cannot patch immediately, edit /etc/vmware/hostd/config.xml and set auth.AD.enabled to false. Restart the host management service with services.sh restart. This removes the attack surface but requires you to manage local ESXi accounts until AD is re‑enabled.
• Restrict AD permissions. The flaw only works if an attacker can create or restore the admin group in AD. Review the delegated permissions on the OU that holds the ESXi groups. Ensure that only highly trusted accounts have the ability to create groups. Use the AD console or Get-ADPermission to audit who can write to that OU.

If you cannot apply a patch and disabling AD is not acceptable, consider isolating the ESXi host from the domain network until a fix is available. Network segmentation reduces the chance that an AD‑compromised account can reach the host.

Step‑by‑step remediation checklist

1. Identify hosts. Run esxcli system version get on every ESXi host. Note any that appear in the affected column of the table below.
2. Confirm AD usage. Check /etc/vmware/hostd/config.xml for AD enabled flag. If false, you can skip the remaining steps for that host.
3. Audit the AD group. From a domain controller, execute Get-ADGroup -Identity "ESXi Admins" | Get-ADGroupMember. Remove any accounts that should not have admin rights.
4. Apply the patch. Download the latest ESXi security bundle from the VMware patch portal. Follow the standard offline‑bundle upgrade procedure. After reboot, re‑run esxcli system version get to confirm the host now reports a fixed build.
5. Validate. Attempt to list the ESXi admin group via the vSphere client. Ensure that only the intended accounts appear and that no unexpected users can log in.
6. Document. Record the host’s new build number, the date of remediation, and any AD permission changes made.

What if a patch is unavailable?

In the unlikely event that you cannot obtain the vendor update – perhaps because you are on an offline air‑gapped environment – you should take the defensive measures that do not rely on code changes:

• Disable AD authentication on the host until you can apply the fix.
• Lock down the AD OU that contains the ESXi groups. Remove create‑group rights from all but a single, tightly controlled account.
• Enable multi‑factor authentication for any AD accounts that have the ability to manage groups.
• Monitor the host’s log files (/var/log/hostd.log and /var/log/vpxa.log) for any login events that originate from newly added AD users.

These steps do not eliminate the vulnerability, but they raise the bar high enough that an attacker would need both AD privilege escalation and a way to bypass the host’s logging to succeed.

When you’re done

After you have patched or applied mitigations, treat the host as you would any other system that has been exposed to a credential‑based attack. Rotate any passwords that were used for AD group management, and consider a full audit of virtual machine snapshots and backups for signs of ransomware activity.

Finally, keep an eye on the vendor’s security advisory page for any follow‑up guidance. New information sometimes emerges after the initial release, and staying current is the best defence.

Version table

The table below lists the affected and fixed releases as published by the National Vulnerability Database. Use it as a quick reference when you compare the output of esxcli system version get against your hosts.

Affected versions

Straight from the NVD record for CVE-2024-37085. If your build is inside one of these ranges, treat it as vulnerable.

Product	Affected range	Fixed in
cloud_foundation	4.0 up to 5.2	5.2