VMware ESXi: patching and protecting hypervisors from ransomware

Updated November 2026

An ESXi host runs every virtual machine on it, so ransomware groups target it to encrypt dozens of servers in one go. Keep it on a supported release, apply each VMSA patch with esxcli software profile update (or vSphere Lifecycle Manager), never expose its management interface to the internet, and keep backups the hypervisor and your domain admins cannot reach.

Supported versions

Broadcom, which now owns VMware, publishes end dates in its Product Lifecycle portal and knowledge base. After the End of General Support date there is no technical support and there are no new patches, apart from customers with a separate extended support contract.

ESXi support status as of November 2026
Version	Released	End of General Support	Status now
ESX 9.0 / 9.1	–	See Broadcom Product Lifecycle	Supported (current, part of VCF/VVF 9)
ESXi 8.x	October 11, 2022	October 11, 2027	Supported, under a year left
ESXi 7.x	April 2, 2020	October 2, 2025	End of general support; patches only with extended support
ESXi 6.x and older	–	Ended years ago	Unsupported

Check what a host runs (in the ESXi Shell or over SSH, as root):

esxcli system version get
esxcli software profile get

The first shows version, update and build number, for example 8.0.3 build 25595708. Compare the build with the fixed build listed in the latest advisory.

Still on ESXi 7? Broadcom’s July 2026 advisory VMSA-2026-0006 fixed a critical (CVSS 9.3) ESXi flaw for 9.x and 8.0, but for 7.0 it says only “contact Broadcom Support if you have an extended support contract”. Without such a contract, a 7.0 host stays vulnerable. Plan the move to 8.0 or 9.x now; ESXi 8 itself reaches end of general support on October 11, 2027. See end-of-life planning.

Where VMSA advisories appear

Broadcom publishes VMware Security Advisories (VMSA-YYYY-NNNN) in the Broadcom Support Portal under Security Advisories, VMware Cloud Foundation. Sign in and use Manage Notifications to get email alerts. Each advisory gives a response matrix with the CVSS score, the fixed build for each version, and any workaround. Read “Workarounds: None” as “patch now”.

Two recent examples:

VMSA-2025-0004 (March 4, 2025): three ESXi flaws, including CVE-2025-22224 (heap overflow, CVSS 9.3), exploited in the wild as zero-days before the patch. They allowed code in a virtual machine to escape to the host. Fixed in ESXi80U3d-24585383, ESXi80U2d-24585300 and ESXi70U3s-24585291.
VMSA-2026-0006 (July 29, 2026, updated August 19, 2026): CVE-2026-47876, an out-of-bounds write in the VMXNET3 virtual network adapter (CVSS 9.3), and two lesser ESXi flaws. Fixed in ESXi-9.1.0.0200-25557999, ESXi-9.0.2.0100-25595025, ESXi80U3k-25595708 and ESXi80U2f-25626445. No workaround.

Also watch the CISA Known Exploited Vulnerabilities catalog, which flags ESXi bugs that attackers are using. See following security advisories.

Get the patch

Patches come from the Broadcom Support Portal and need an active support entitlement. You have two options:

Offline bundle: download the ESXi patch ZIP (the “depot” file) from the Broadcom Support Portal and upload it to a datastore the host can see, for example /vmfs/volumes/datastore1/.
Online depot: a site administrator generates a download token in the portal (My Dashboard > Quick Links > Generate Download Token, Product Administrator role needed). The depot address is then https://dl.broadcom.com/<Download Token>/PROD/COMP/ESX_HOST/main/vmw-depot-index.xml. Old vmware.com depot URLs no longer work.

If the host is managed by vCenter, put the new depot into vSphere Lifecycle Manager and remediate the cluster from there instead; it migrates VMs and handles maintenance mode for you.

Patch a host with esxcli

Since ESXi 8.0 Update 2, Broadcom no longer supports changing the ESXi version with esxcli software vib update or vib install. Use an image profile. These commands run as root on the host.

One host at a time; in a cluster, the next host starts only after the last one is back.

# 1. Move or shut down the VMs on this host, then:
esxcli system maintenanceMode set --enable true

# 2. List the image profiles in the depot (offline ZIP shown; an online
#    depot URL works the same way)
esxcli software sources profile list -d /vmfs/volumes/datastore1/<patch-depot>.zip

# 3. Test, then apply. Use the profile name from step 2.
esxcli software profile update --dry-run -d /vmfs/volumes/datastore1/<patch-depot>.zip -p <profile-name>
esxcli software profile update -d /vmfs/volumes/datastore1/<patch-depot>.zip -p <profile-name>

# 4. REBOOTS THE HOST (it must be in maintenance mode)
esxcli system shutdown reboot --reason "Security patch VMSA-2026-0006"

# 5. After it is back: check the build, then leave maintenance mode
esxcli system version get
esxcli system maintenanceMode set --enable false

Pick the profile that matches the one esxcli software profile get reports today, at the new build. If the update stops on a hardware compatibility warning, check the warning against Broadcom’s compatibility guide before you rerun with --no-hardware-warning. To use the online depot from a standalone host, allow outbound HTTP for the duration:

esxcli network firewall ruleset set -r httpClient -e true
esxcli software sources profile list -d https://dl.broadcom.com/<Download Token>/PROD/COMP/ESX_HOST/main/vmw-depot-index.xml
# ... profile update as above, with the same -d URL ...
esxcli network firewall ruleset set -r httpClient -e false

Disable SLP

The ESXiArgs campaign in February 2023 most likely used known, already-patched flaws in the SLP service on outdated or end-of-life hosts; VMware found no evidence of a zero-day. ESXi 7.0 U2c and later and ESXi 8.0 and later ship with SLP disabled, but upgraded hosts may still have it on. Broadcom’s KB 318790 gives this procedure (no reboot needed):

esxcli system slp stats get                 # check whether SLP is in use
/etc/init.d/slpd stop                        # stops the SLP service
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd off                           # keep it off after reboots
chkconfig --list | grep slpd                 # should print: slpd off

The only side effect: CIM clients that find the CIM server through SLP will no longer find it. Treat this as hardening, not a substitute for patching.

Lock down the management network

Never on the internet. ESXiArgs compromised over 3,800 servers worldwide, and CISA’s first advice was to make sure no ESXi host is exposed to the public internet. Put the host management (vmk0) and vCenter on a separate VLAN reachable only from admin workstations or a jump host, and use a VPN for remote work.

Restrict host firewall rules to your admin subnet. List rulesets with esxcli network firewall ruleset list, then for example:

esxcli network firewall ruleset set -r sshServer -a false
esxcli network firewall ruleset allowedip add -r sshServer -i 10.10.50.0/24

Turn off SSH and the ESXi Shell when you are not using them, and use lockdown mode on vCenter-managed hosts so changes go through vCenter.
Active Directory. Microsoft reported in July 2024 that ransomware operators (deploying Akira and Black Basta) exploited CVE-2024-37085: on domain-joined hosts, members of any AD group named “ESX Admins” got full admin rights, so attackers simply created that group. Patch, and if hosts are domain-joined, change the admin group or set Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd to false. Better still, do not join hosts to the same domain your users log in to.
Consider the --require-exec-installed-only option of esxcli system settings encryption set (on hosts that support it), which lets only binaries from installed VIBs run, so a dropped encryptor cannot start. Test it on one host first.
Forward ESXi logs to a remote syslog or SIEM so an attacker cannot erase the trail.

Backups that survive the hypervisor

When a host is encrypted, every VM on it goes with it, and an attacker with domain admin rights can usually reach the backup server too. CISA’s ESXiArgs advisory recommends offline backups that are tested regularly, encrypted and immutable.

Run the backup server outside the production domain, with its own credentials and MFA on its console.
Keep at least one copy offline or on immutable storage (object lock, tape, or a hardened repository) that a stolen vCenter or domain admin account cannot delete.
Back up the host configuration too, so you can rebuild a host quickly.
Test a full VM restore on a spare host at least every quarter.

If a host is already encrypted, isolate it and follow the ransomware response steps. ESXiArgs encrypted VM configuration files but not the large flat disk files, which is why CISA could publish a recovery script; other ESXi ransomware is not so forgiving.