One console, every server: what ESXiArgs exposed about the hypervisor

The week

In early February 2023, IT teams across Europe and beyond arrived at work to find that not one server but whole rooms of them had stopped. Beginning around February 3, a ransomware campaign later called ESXiArgs compromised VMware ESXi hypervisors exposed to the internet.

A hypervisor is the software that lets one powerful physical computer pretend to be many separate ones. Each of those pretend computers is called a virtual machine, and each can run its own email system, database or billing application. It is a bit like an apartment building: one structure, many separate units. VMware ESXi is one of the most widely used hypervisors in the world.

The attackers encrypted the configuration and disk files of the virtual machines those hypervisors hosted. In apartment terms, they did not break into one unit; they changed the locks on the whole building from the basement.

The attacks were widely linked to CVE-2021-21974, a flaw in the OpenSLP service that VMware had patched in February 2021. A CVE is simply a catalog number for a publicly known security flaw. OpenSLP is a small helper service that lets devices on a network announce themselves to each other. Investigators said some servers may have been reached by other means, but the headline was clear: a fix had been available for two years.

The fix came in VMware advisory VMSA-2021-0002, published on February 23, 2021. The bug was a heap overflow in OpenSLP. An attacker who could reach the service over the network, on port 427, could use it to run code on the host itself. Many of the servers hit in 2023 were also running versions that VMware had stopped supporting. General support for vSphere 6.5 and 6.7 had ended on October 15, 2022, four months before the campaign.

VMware said on February 6 that it had found no evidence that an unknown flaw was being used. It said attackers were going after products past their end of general support or simply out of date. It also noted that ESXi had shipped with OpenSLP switched off by default since version 7.0 Update 2c, and recommended that customers disable it where it was still running.

Warnings spread fast. France’s CERT-FR and Italy’s national cybersecurity agency issued alerts as thousands of servers were reported hit. CERT-FR’s first alert came on February 3. It told victims that patching alone was not enough, since an attacker might already be inside. It advised isolating affected servers, checking for compromise and preferably reinstalling the hypervisor on a supported version. It also urged organizations to restrict administration services to a dedicated network, reachable remotely only through a VPN or an address filter.

Then came an unexpected break. Researchers found the malware often left large virtual disk files only partly encrypted, so much of the data could be rescued. On February 7 CISA, the US Cybersecurity and Infrastructure Security Agency, published a recovery script, a small program that automated that rescue. CISA and the FBI issued a joint advisory on February 8.

That advisory, AA23-039A, said the actors had compromised more than 3,800 servers globally. It said they were likely targeting end-of-life ESXi servers and servers missing available patches. The malware encrypted the configuration files that tell the hypervisor how each virtual machine is built. In many cases it left the large “flat” files holding the virtual disks’ actual data largely unencrypted, which is what made the recovery script possible. CERT-FR had confirmed the same weakness in an update on February 5.

The reprieve was short. Within days a modified version appeared that encrypted more of each file and defeated that recovery method. Organizations that had been counting on the attackers’ mistake found that the attackers had corrected it.

CERT-FR recorded the change in an update on February 10. A new wave had begun on February 8, and it encrypted a larger share of the data in big files, making restoration much harder or impossible. The French agency kept its alert open until March 14 and noted, when closing it, that the threat had not gone away.

Take the operations director of a mid-sized clinic network walking in on a Saturday morning. The scheduling system is down. So is the billing system, the shared drive and the email server. The IT manager explains that these were never really separate machines. They were all virtual machines running on three physical servers in a back room, and those three servers have been locked by ransomware. Everything went at once because everything lived in the same place.

ESXiArgs first looked like a routine patching failure: an old flaw, a two-year-old fix, servers left exposed. That reading is accurate and incomplete. The campaign hit the hypervisor, the layer that runs dozens or hundreds of servers on each physical host, and that choice of target is what made a modest piece of malware so damaging.

Three properties of that layer explain the outcome: its management interfaces are often exposed, it sits in a blind spot for endpoint controls, and recovery frequently depends on the same layer the attacker controls. Each has a clear fix that an executive can sponsor.

One host, a hundred servers

Twenty years ago, most organizations ran one application per physical server. The email server was a box. The finance system was another box. Most of those boxes sat mostly idle, which wasted money, power and space.

Virtualization changed that. A hypervisor is a thin layer of software installed directly on a powerful physical server, called a host. It carves that host into many virtual machines, each of which behaves as if it were its own computer, with its own operating system and applications. A single host might run a dozen or a hundred of them. A small group of hosts, managed together, is called a cluster.

The savings are real, which is why virtualization is nearly everywhere: in banks, hospitals, county offices, law firms and manufacturers. But it changes the shape of risk. A virtual machine is, underneath, a set of files sitting on the host’s storage. Whoever controls the hypervisor controls those files. That means one administrative console can start, stop, copy or delete every server in the building.

That concentration is a feature for the IT team, who can manage hundreds of servers from one screen. It is also a feature for an attacker. Getting into one ordinary server gives you one server. Getting into the hypervisor gives you all of them.

What a virtual machine is made of

The mechanics of ESXiArgs make sense once the files are visible. On ESXi, each virtual machine lives in a folder on a datastore, the storage the host uses. A small configuration file describes the machine: its processors, memory and network cards. A descriptor file points to the virtual disk. A much larger flat file holds the disk’s contents, which can run to hundreds of gigabytes. Other small files hold snapshots, memory state and settings.

ESXiArgs went after those files from the host itself. It encrypted the configuration and descriptor files and only part of the large ones. Without the small files, the hypervisor no longer knew how to start the machine, so every server appeared destroyed. The data inside the flat files was mostly intact. CISA’s script worked by rebuilding the small files around the surviving data. The second version closed that gap by encrypting much more of the large files.

The episode shows how thin the line between an outage and a loss can be. The same attacker, with a slightly different encryption setting, turned a recoverable incident into an unrecoverable one within a week. A recovery plan should assume the attacker gets the settings right.

Managed clusters and standalone hosts

Larger organizations usually manage their hosts through vCenter Server, VMware’s central management system, and keep it on an internal network. Many of the servers hit by ESXiArgs were standalone hosts, managed one at a time through their own web interface. Some were dedicated servers rented from hosting companies, installed with a public internet address and default settings. Reports at the time pointed to many victims among hosting customers in Europe.

The difference matters for ownership. A standalone host rented from a hosting provider can fall outside everyone’s process. The provider supplies the hardware and perhaps the initial install. The customer assumes the provider keeps it safe. Nobody schedules its patches. Contracts for such services should say plainly who patches the hypervisor, who controls which ports face the internet, and who is told when a flaw is published.

How the virtualization layer runs day to day

Inside most organizations, the virtualization layer is looked after by a small infrastructure team, sometimes just one or two people. Their day is spent keeping things running: adding a new virtual machine when a department needs one, moving machines between hosts to balance the load, expanding storage, and applying updates when time allows. They work mostly through a central management console, a single screen that shows every host and every virtual machine.

That team’s priorities are uptime and speed. When a business unit wants a new system by Friday, the infrastructure team makes it happen. When a vendor needs remote access to troubleshoot, the team opens a path. These are reasonable choices made under real pressure, and they explain why security settings drift over time.

The security team, meanwhile, often works elsewhere and focuses on what it can see: laptops, servers, email, the website. The virtualization layer can fall between the two groups. Infrastructure assumes security is watching it; security assumes infrastructure has locked it down. Neither is fully true, and nobody is quite sure whose job the hypervisor is.

Why hypervisor patching slips

Hypervisor updates are harder than they look. On a well-built cluster, the team moves running virtual machines off a host, patches and reboots it, then moves them back. That needs spare capacity on the other hosts and shared storage they can all reach. Smaller sites often have neither, so every hypervisor patch means scheduled downtime for every server on the host.

Hardware adds friction. Each ESXi release supports a defined list of server hardware, and older servers may not be supported by newer versions. A team that wants to move from an unsupported release may need new hardware first, which turns a patch into a capital purchase. That is how hosts end up running out-of-support versions for years. Each delay has a reason. Together they leave an exposed, unpatched host.

The trade-off is real. Patching every month disrupts the business and costs staff time, and some organizations reasonably choose a slower cycle for low-risk internal hosts. The choice becomes indefensible when the host is reachable from the internet or the flaw is known to be exploited. A sensible policy sets a short deadline for those cases and a longer one for the rest, and tracks both.

Smaller organizations face a starker version. A credit union or a rural hospital may rely on a managed service provider, an outside IT firm, to run its hosts. The provider may manage dozens of clients the same way, using the same remote tools. That is efficient, and it means the organization’s most important layer is administered by people it rarely meets, under settings it may never have reviewed.

A managed service contract can close much of that gap. It can set a deadline for applying hypervisor patches, with a shorter one for actively exploited flaws. It can require separate administrative credentials for each client rather than one set reused across all of them. It can require logs of administrative access to be kept and shared on request, and external scan results to be reported to the client each quarter. Few of these terms cost the provider much. They do require the client to ask.

The problem is a gap in ownership rather than competence. Closing it starts with a simple decision from leadership: the virtualization layer is a critical system, it has a named owner, and security monitoring covers it.

How the gap differs by organization

• Health systems often cannot upgrade the hypervisor on their own schedule. Clinical software vendors certify their products on specific platform versions, so an upgrade can wait on the vendor’s support matrix. The security team needs a documented exception, with compensating controls, for every host held back that way.
• Banks and credit unions usually have formal change windows, which makes patching predictable but slow. Emergency change procedures should name exploited hypervisor flaws as a qualifying reason, so a fix does not wait a month for the next window.
• Counties and cities tend to accumulate hosts bought by individual departments, sometimes with grant money, outside central IT. An inventory exercise that asks every department about its servers usually finds hosts nobody in central IT knew about.
• Hosting customers of every type need to read the service terms. A rented dedicated server with a hypervisor installed is usually the customer’s to patch and protect, whatever the customer assumed.

Exposed management interfaces

The servers hit by ESXiArgs were reachable from the internet on services that had no business being there. Hypervisor management interfaces, and helper services such as OpenSLP, are administrative plumbing. In a sound design they are reachable only from a dedicated management network, through a jump host with strong authentication. A jump host is a single, tightly controlled computer that administrators must log into first before they can reach the sensitive systems behind it.

Exposure arises in predictable ways. A small office or clinic installs a standalone host with default settings. A hosting provider opens management ports for customer convenience. A temporary firewall rule for remote vendor support is never removed. A lab host built for a project drifts into production use. These are the ordinary habits of busy teams, with no bad intentions involved.

Findings need a deadline as well as a ticket. A reasonable rule closes any exposed hypervisor or hardware management interface within days, and reports the count of open findings and their age to the CIO every month. The figure should normally be zero. When it is not, the age of the oldest finding shows whether the process works.

The controls are ordinary. Scan your own internet-facing address space from the outside on a schedule, and treat any reachable hypervisor, storage or out-of-band management interface as a priority finding. Out-of-band management refers to the separate control ports built into server hardware that let administrators power machines on and off remotely; they are powerful and should never face the internet. Disable services that are not used; VMware’s own guidance after the campaign was to turn off SLP where it was not needed. Ask hosting providers the same questions in writing. Many organizations scan for vulnerable web applications every week and never look for exposed infrastructure ports.

What an outside scan should look for

The list is short and specific. SLP listens on port 427. ESXi’s management web interface uses the standard web port, 443, and the console service uses port 902. Some hosts expose a hardware monitoring service on port 5989. Server baseboard controllers, sold under names such as iDRAC and iLO, often answer on the web and on IPMI, port 623. SSH on port 22 should never be open to the internet on a hypervisor. Any of these answering on a public address is a finding to fix within days.

A scan only shows what it covers. It should include every public address range the organization owns, the addresses of hosted and colocated equipment, and anything a hosting provider runs on its behalf. Free internet-wide scanning services also show what the rest of the world can see. Checking the organization’s own ranges against them costs nothing.

An inventory of hypervisors is the precondition for all of this. Many organizations can list their virtual machines but not every physical host, with its version and build number, especially hosts in branch offices, clinics or labs. A quarterly reconciliation of the virtualization console, the hardware asset register and external scan results usually turns up a few hosts nobody owns. Those orphaned hosts are disproportionately the unpatched ones.

The written questions for a hosting provider can be brief. The provider should state, for the customer’s servers:

• which management interfaces are reachable from the internet, and from where;
• who applies hypervisor patches, and within what time for exploited flaws;
• how its administrators’ credentials for the customer’s environment are protected and logged;
• whether it keeps backups outside the environment its administrators manage day to day.

The answers belong in the vendor file, with a date, and should be refreshed at renewal. A provider that cannot answer them clearly is telling the customer something about its own controls.

Suppose a county government runs a well-managed central data center. But the county library system bought its own small host years ago, set up by a contractor, and the planning department has another left over from a mapping project. Neither appears in the central IT inventory. An outside scan finds one of them answering on the internet. That host, rather than the main data center, is where an ESXiArgs-style attack would have started.

The endpoint-control blind spot

Most security programs lean on endpoint detection and response agents installed on Windows and Linux servers. These agents, often called EDR, are security software that watches each computer for suspicious behavior. Hypervisors typically cannot run those agents, and many organizations do not send hypervisor logs to their security monitoring at all.

An attacker on the hypervisor encrypts virtual machine files from underneath the guest operating systems. The guests’ security tools see nothing until the machines fail to boot.

Persistence below the operating system

Ransomware crews were not the only ones to notice the gap. In 2022 Mandiant reported that a suspected espionage group had installed malicious software packages on ESXi hosts to keep access that survived reboots. From the hypervisor, the group could run commands on the guest machines without touching their security tools. Such access is invisible to the endpoint agents an organization relies on everywhere else.

ESXi has settings that make this harder. Its acceptance levels can block the installation of unsigned software packages. A setting that allows only installed, signed binaries to run stops an attacker from running a tool copied onto the host. Secure Boot, paired with a hardware security chip, lets the host prove that its software has not been altered. These settings are off or loose on many hosts because they complicate troubleshooting and some third-party drivers. Turning them on is a sound default for any host that runs important workloads.

That makes the hypervisor a high-value, low-visibility target. Closing the gap means treating it as a monitored asset in its own right:

• Forward its logs to the security operations team, the people who watch for attacks.
• Alert on new local accounts, shell or SSH being enabled, service changes and logins from unusual sources. Shell and SSH are ways of typing commands directly into the system; on a hypervisor they are rarely needed day to day, so their sudden appearance is a warning sign.
• Restrict shell access and enable lockdown features where the platform offers them.

Lockdown has a cost. In its strictest form, ESXi lockdown mode allows management only through vCenter. If vCenter itself is down or compromised, administrators can be locked out of their own hosts in the middle of an incident. The usual answer is a short list of exception accounts, stored with a break-glass procedure that is tested and logged. Lockdown without that procedure trades one risk for another.

Logging also needs a destination the attacker cannot erase. Hypervisor logs sent only to local storage on the host disappear with the host. Logs forwarded as they are written to a central collector, under separate administration, survive the attack and show investigators what happened.

Identity is the other half. Many later hypervisor attacks used no vulnerability at all; they used administrator credentials stolen elsewhere in the network. If virtualization administration is tied to ordinary domain accounts, an attacker who takes the directory takes the hypervisors too. The directory, usually Microsoft’s Active Directory, is the central list of users and passwords that controls who can log into what.

Separate administrative identities, phishing-resistant authentication for those accounts, and a short list of named administrators reduce that path. Phishing-resistant authentication means login methods, such as physical security keys, that cannot be tricked out of a user by a fake website. The trade-off is operational friction for infrastructure teams, which is why the change needs an executive sponsor rather than a ticket.

Concrete steps follow from that principle. Hosts that do not need to be joined to the directory can stay out of it, managed through vCenter with its own identity source. Where hosts are joined, the groups that grant hypervisor rights should be defined explicitly, owned by named people and monitored for changes. Each host’s local root password should be unique, stored in a privileged access vault and rotated after use. vCenter itself deserves the same protection as a domain controller, because it controls everything beneath it.

Recovery that depends on the same layer

The third property concerns recovery. Many organizations back up virtual machines through integrations with the hypervisor platform. They store backups on systems managed from the same environment and plan to restore onto the same hosts. An attacker who controls the virtualization layer can often reach the backup server as well, or at least delete the snapshots kept alongside the machines. A snapshot is a saved point-in-time copy of a virtual machine, handy for undoing a bad update but stored right next to the original.

CISA’s recovery script helped many victims because of a flaw in the malware, and the attackers fixed that flaw within days. Recovery that depends on an attacker’s mistake is luck rather than a plan.

A resilient design keeps at least one backup copy offline or immutable, under credentials the virtualization administrators do not hold. Immutable means the copy cannot be changed or deleted for a set period, even by an administrator. The design also includes a tested procedure for rebuilding hypervisors from clean media and restoring workloads onto them, in a defined order: identity services, then core business systems, then the rest. Identity comes first because nothing else can log in without it.

Testing is where most plans fall short. A file-level restore test proves little about rebuilding a whole cluster. A meaningful exercise restores a representative set of virtual machines onto freshly built hosts and measures elapsed time against the recovery objectives the business has been promised. It should also confirm that the restore process works without the domain controllers that were on the encrypted hosts. Domain controllers are the servers that run the directory; if they were among the locked machines, a restore plan that needs them to log in will stall at the first step.

Designing recovery around a clean room

A recovery design that assumes the virtualization layer is hostile looks different from one that assumes a single failed server. Backups go to a repository that does not trust the production directory, with its own administrators and multi-factor authentication. At least one copy uses storage that enforces immutability for a fixed period, so deletion requests fail even from a valid account. The backup software’s own management console runs on an isolated network.

Rebuilding starts with fresh hosts installed from the vendor’s media, not restored from the old configuration, which may carry the attacker’s changes. A small isolated environment comes up first, with name resolution, network addressing and a recovery directory. Core systems are restored into it, checked for signs of compromise and only then connected to the wider network. Restoring straight back into the environment the attacker controlled invites reinfection, which is why CERT-FR urged reinstalling hypervisors rather than only patching them.

The case for moving the problem elsewhere

Some organizations concluded that the answer was to stop running hypervisors at all, moving workloads to software-as-a-service or to a public cloud. For a small clinic or town office, that can be right. It shifts patching of the virtualization layer to a provider with far more staff for the job.

It does not remove the pattern. A cloud account’s administrative console controls every virtual machine, disk and backup in it, just as a hypervisor console does. Stolen cloud administrator credentials can delete servers and snapshots in minutes. The same four disciplines carry over: keep management interfaces off the open internet, monitor the control plane, separate administrative identities and keep backups outside the account they protect.

When forty servers go dark together

The business case is straightforward. When the hypervisor goes, the outage covers close to everything rather than one application. Customers cannot be served, staff cannot work, and regulators and auditors want to know what happened and how data was protected. Recovery times are measured in days or weeks, not hours, and every day carries lost revenue and overtime.

Say a regional insurer runs forty virtual machines on four hosts. If one virtual machine is hit by ransomware, the team restores it from backup and the business barely notices. If the hypervisor is hit, all forty go dark together: policy administration, claims, the customer portal, the phone system and the file shares. The insurer must now decide in what order to rebuild, discover which backups are still intact, and tell customers why claims are delayed. The difference between those two days lies in which layer the attacker reached, and the malware may be identical.

Mapping the blast radius before it happens

Few organizations can say which business services stop if a particular cluster goes down. The mapping is not hard. List the virtual machines on each cluster, tie each to the application and business service it supports, and mark the shared services such as directory, name resolution and file storage. The result shows how much of the organization one cluster failure would take with it.

That map often leads to a structural change. Identity services, backup infrastructure and security tools can run on a separate management cluster with separate administrators. A compromise of the main production cluster then does not also take out the systems needed to recover it. Two domain controllers on different clusters, or one outside the virtual environment, keep sign-in working while the rest is rebuilt. These choices cost some extra hardware and a little more administration. They decide whether recovery starts on the first day or the third.

These three properties fall hardest on smaller organizations: clinics, credit unions, local governments and regional firms running a few hosts with thin security staff. For them the hypervisor is where nearly every server lives, so one compromised host can mean the whole environment.

Who has to report what

When a hypervisor goes down, notification rules apply to the services lost and the data exposed, and they differ by sector. Organizations should confirm the details with counsel.

• Banks must notify their primary federal regulator within 36 hours of a significant computer-security incident under the banking agencies’ notification rule.
• Federally insured credit unions must report reportable cyber incidents to NCUA within 72 hours under the rule that took effect in September 2023.
• Health systems and clinics that are HIPAA covered entities must assess whether encrypted or accessed patient data counts as a breach. HHS guidance presumes that ransomware encryption of protected health information is one unless a documented assessment shows otherwise.
• Counties and cities that host criminal justice information for a sheriff or police department must meet the FBI’s CJIS Security Policy for those systems, including its incident handling requirements. State breach laws may also apply to residents’ personal data.

Each regime asks the same practical questions: what was affected, what data was exposed and when the organization knew. A hypervisor attack makes all three harder to answer, because so many systems fail at once and their logs may be gone. Central logging and an accurate inventory of what runs on each host shorten the time to a defensible answer.

Patching discipline matters too. Many organizations patch guest operating systems monthly and hypervisors rarely, because hypervisor updates require moving or shutting down workloads. Giving hypervisor patching its own owner and its own cycle closes the gap that ESXiArgs used. A two-year-old fix only protects you if someone is responsible for applying it.

A well-run hypervisor estate fits on one page

An organization in good shape can show, on one page, every physical host it owns, its version, its owner and when it was last patched. Counting virtual machines is no substitute: the inventory can look complete while the small host in a branch office is missing. Its outside scans find no management interfaces facing the internet. Hypervisor logs flow to the security team, and someone is alerted when a shell is switched on, because the security agents on the servers do not see the layer beneath them. Virtualization administrators use separate accounts with strong authentication.

At least one backup copy is beyond the reach of those administrators; backups managed by the same accounts, on the same platform, can be wiped by the same attacker. The team has rebuilt a cluster from scratch in a test and timed it, since recovering one file proves the software works and says nothing about whether the business can be back by Monday. And hypervisor updates have a fixed slot in the calendar. Because they are disruptive they tend to slip, and the slip becomes the attacker’s opening. Someone is named as responsible for that patching, with a schedule and a figure for how far behind it is today. Where hosting providers run systems on the organization’s behalf, they have said in writing how they protect the management interfaces.

What the one page costs to keep true

The work is mostly time, not licenses. A quarterly inventory reconciliation takes an infrastructure engineer a day or two. Log forwarding and a handful of alerts take a few weeks to set up and some ongoing tuning. Separate administrative accounts and a vault add friction to every change. An annual cluster rebuild test takes a weekend and a spare set of hardware, or rented capacity. For a large organization these are modest. For a small one with two IT staff, they compete directly with keeping everything else running, which is why the help of a managed provider, under the right contract, is often the realistic route.

The objection that this was only a patching failure

The strongest objection to this article’s argument is that ESXiArgs was a patching failure and nothing more. Every compromised server was missing a fix that had existed for two years. Patch on time, and the campaign has nothing to exploit.

That is true for this campaign, and it is why hypervisor patching needs its own owner. It does not hold for the attacks that followed. Later intrusions used stolen administrator credentials, abused how hosts trusted the directory, or exploited flaws before patches were widely applied. Exposure, blind spots and dependent recovery are architecture problems that remain whatever the patch level. Patching closes one door. The other three properties decide how much damage follows when another door opens.

Hosts, consoles and backups the infrastructure owner should account for

1. How many physical hosts do we run, including in branches, clinics and labs, and who owns each one?
2. When did we last scan our internet-facing addresses from the outside for management interfaces, and what did we find?
3. Are hypervisor logs going to our security monitoring, and are our virtualization administrator accounts separate from ordinary network accounts?
4. Is there at least one backup copy that our virtualization administrators cannot delete?
5. When did we last rebuild a cluster onto clean hosts in a test, how long did it take, and could we do it without our domain controllers?

ESXiArgs was unsophisticated. It used an old flaw against servers that should never have been reachable. What it showed concerns architecture more than cleverness. When one layer controls every server, that layer deserves its own inventory, its own monitoring, its own administrators and a recovery plan that does not depend on it.

With hindsight

Hypervisor targeting became routine. Through 2023 and 2024 several major ransomware operations fielded ESXi-specific encryptors, versions of their malware built specifically to lock virtual machine files. Many intrusions used stolen credentials rather than old flaws. Attackers increasingly did not need to break in through a forgotten service; they logged in with a password taken from somewhere else in the network.

Espionage groups pursued the same layer. In June 2023 Mandiant reported that a suspected Chinese espionage group had exploited a previously unknown flaw in VMware Tools. From compromised ESXi hosts, it could act on the guest virtual machines. The tools that watched those guests could not see the activity, the blind spot described above.

In July 2024 Microsoft reported that ransomware operators were exploiting CVE-2024-37085, an ESXi authentication bypass tied to an Active Directory group. An authentication bypass is a flaw that lets someone skip the normal login check. Because this one was tied to the directory that controls ordinary user accounts, it showed identity and virtualization risk converging: control of the directory could mean control of the hypervisors.

Microsoft’s report gave the mechanism. Domain-joined ESXi hosts granted full administrator rights to any member of a directory group named “ESX Admins”, even though no such group exists by default. An attacker with enough rights in the directory could simply create the group and add an account. Microsoft said its incident response engagements involving ESXi had more than doubled over three years, and that the technique had led to Akira and Black Basta ransomware deployments.

In March 2025 Broadcom disclosed three more ESXi flaws, and CISA added all three to its Known Exploited Vulnerabilities catalog on March 4. Together they could let an attacker with administrator rights inside one virtual machine break out to the hypervisor beneath it. That turned the concentration problem around: one compromised guest could become a route to every other guest on the host.

The market around the technology shifted too. Broadcom completed its acquisition of VMware in November 2023 and changed licensing and packaging, prompting many organizations to review their virtualization platforms. Some migrated; many stayed. That review was a natural moment to ask security questions alongside commercial ones.

The licensing changes included the end of new perpetual licenses in favor of subscriptions, and the withdrawal of the free edition of ESXi in early 2024. Small organizations that had run free or older hypervisors faced a choice between paying more, migrating or staying on software that no longer received updates. The last option recreated the conditions of 2023.

The controls that mattered did not depend on the vendor: management networks isolated from user networks, separate administrative identities, hypervisor logs in security monitoring, and immutable backups held outside the virtual environment. Whichever platform an organization chose, the same layer still held all the servers, and the same four protections still applied.

One expectation from February 2023 did not hold. The partial encryption that made CISA’s recovery script work proved to be a passing flaw, fixed within days, and no victim could count on attackers repeating the mistake. Recovery came to depend on backups the attacker could not reach.

Smaller organizations, the most exposed in 2023, still find these hardest to sustain without outside support. For a board or council overseeing such an organization, the practical question goes beyond whether the IT team understands these controls. It is whether the team has the time, staff and budget to keep them in place year after year, and if not, who will help.

General support for vSphere 7 ended on October 2, 2025. Organizations still running that release were then where ESXi 6.5 and 6.7 users had been in 2023. The layer that held every server ran on software that no longer received regular fixes. The broader point holds well beyond VMware. Any time a single console controls many systems, whether a hypervisor, a cloud account or a remote-management tool, that console deserves the protection of the most valuable system it controls.