VMware ESX and ESXi Release History: Versions, Patching and Support Dates

VMware's bare metal hypervisor has shipped as ESX Server (2001 to 4.1), as ESXi (3i in 2007, then the only edition from 5.0 in 2011) and, from the 9.0 release in June 2025, under the ESX name again. As of 25 October 2026, Broadcom's knowledge base gives ESXi 8.0 an end of general support date of 11 October 2027, and ESXi 7.0 general support ended on 2 October 2025. The newest builds listed are ESX 9.1.1.0100 (12 October 2026) and ESXi 8.0 Update 3k (29 July 2026).

This post walks through every major release with its build number and date, the support dates Broadcom publishes in its own knowledge base, how security features arrived release by release, how update and patch releases are named and installed, what changed after Broadcom bought VMware in November 2023, and how the hardware compatibility guide quietly decides which release a server can run. It ends with a step by step routine to inventory the build on every host and map it to the support table and to VMware security advisories. Specific vulnerabilities are left to our incident posts; this one is about versions, lifecycle and patch hygiene.

Key takeaways

• ESXi 8.0 and the ESX 9.x line are the supported lines. Broadcom KB 459135 gives ESXi 8.x a general availability date of 11 October 2022 and an end of general support (EoGS) of 11 October 2027. ESX 9.0 went GA on 17 June 2025 and 9.1 on 12 May 2026, according to the build number KB 316595.
• ESXi 7.0 is out of general support. KB 415405 says general support for vSphere 7.0 "was October 2nd, 2025". Broadcom's own reminder blog says the date had already been pushed back six months from 2 April 2025.
• The VCF 9 line runs on a new support model. Broadcom moved from "5+2" to "6+1" with VCF 9.0: a major release supported for six years, minor releases about every nine months, 27 months of support for early minors and 45 months for the last one. Broadcom estimates an end of service of 17 June 2031 for the 9.x code line.
• The build number is the version that matters. "ESXi 8.0 Update 3e" and "ESXi 8.0.3 P05" are the same release, build 24674464. Map builds, not marketing names, to advisories.
• Patching moved from baselines to images. vSphere 8.0 deprecated vSphere Lifecycle Manager baselines (the old Update Manager workflow); Broadcom KB 322186 says they are removed in the next major release, and image based lifecycle management is the path forward.
• Licensing changed on 11 December 2023. VMware by Broadcom ended the sale of perpetual licenses and of support renewals for perpetual offerings. A free ESXi edition came back with ESXi 8.0 Update 3e in April 2025, without vCenter management or Broadcom support.
• Hardware support ends releases before software does. ESXi 8.0 dropped TPM 1.2 and CPUs their vendors had marked end of life; ESX 9.x discontinues more CPU series and warns on deprecated ones at install time.
• Hardening defaults are not on. Broadcom's vSphere 8 hardening guide lists Secure Boot, lockdown mode and execInstalledOnly as top priority controls whose installation default is off.

ESX and ESXi: where the hypervisor came from

ESX Server 1.0 to 4.1: a VMkernel with a Linux service console

VMware's first server hypervisor, ESX Server 1.0, shipped in 2001. In a 2023 post on his blog, VMware's William Lam described imaging a sealed ESX Server 1.0.1 box from that year and noted that copies of anything before 2.0 were hard to find. ESX ran VMware's own VMkernel directly on the hardware, with a Linux based "service console" running alongside it as a privileged management environment. Administrators logged into that console, ran agents in it and installed RPM style packages into it, which meant every ESX host also carried a general purpose Linux userland that had to be patched and hardened like any other Linux server.

ESX Server 3i (2007): the thin hypervisor

On 10 September 2007 VMware introduced ESX Server 3i. The press release described "the industry's next generation thin hypervisor", a "compact, 32 MB package" designed to be built into server hardware from the large server makers, and said it would be the only hypervisor on the market "that does not incorporate a general-purpose operating system". Hardware vendors were expected to ship it embedded in their products from the end of 2007 and through 2008, with a download version to follow.

The security idea was simple: removing the service console removes a large Linux attack surface and a large patch surface. Management moved to remote APIs and clients. Today's local ESXi Shell and SSH services both ship stopped and set to start manually, according to Broadcom's hardening guide.

ESXi only from 5.0 (2011)

For the 4.0 and 4.1 releases, VMware shipped both editions. Broadcom's build number KB lists ESX and ESXi builds side by side through 4.1, with the last classic ESX patch, ESX 4.1 Patch 11a, dated 1 October 2014. From vSphere 5.0, released on 24 August 2011, there is only an ESXi installer. The vSphere 5.0 release notes describe upgrading or migrating "from ESXi/ESX 4.x hosts to ESXi 5.0", which is the end of the service console architecture.

ESX again from 9.0 (2025)

Broadcom's build table labels every 9.x release "ESX", for example "ESX 9.0 GA" and "ESX 9.1.1.0", while every 8.x and 7.x row still says "ESXi". Broadcom documents now refer to "Securing the ESX Configuration" for 9.0 where the 8.0 page said ESXi. The product is still the thin VMkernel based hypervisor; only the name changed. For searches, inventories and CMDB fields, treat ESX 9.x and ESXi 8.x as the same product line.

Every ESX and ESXi release with build numbers and support dates

Broadcom's product lifecycle matrix (support.broadcom.com/web/ecx/productlifecycle) returned HTTP 403 to every request we made, so the support dates below come only from Broadcom knowledge base articles and Broadcom's VMware blog, and the release dates and builds come from KB 316595, "Build numbers and versions of VMware ESXi/ESX". Where no Broadcom page we could load gives a date, the table says so rather than guessing. The last column shows the newest build Broadcom lists for that line, which is a useful proxy for when patches stopped.

A few things stand out once the dates are side by side.

• Patches stop at EoGS, not after it. ESXi 6.5 and 6.7 each got a final patch on 6 October 2022, nine days before their 15 October 2022 EoGS. ESXi 6.0's last listed patch is 20 February 2020, three weeks before its 12 March 2020 EoGS. Anything still running those lines has had no fixes for years.
• General support is roughly five years for the 6.x to 8.x lines. 6.5 got "a full six years from date of release", in KB 318892's words, because VMware extended it to match 6.7. 7.0 ended five and a half years after GA because of the six month extension. 8.0 is scheduled for exactly five years.
• Technical guidance is not patching. KB 318892 says 6.0 had technical guidance until 12 March 2022, but "VMware does not offer new hardware support, server/client/guest OS updates, new security patches or bug fixes" in that phase. Broadcom's blog lists an end of technical guidance date of 2 April 2027 for 7.x, with an asterisk saying it "does not apply to Broadcom contracts".

What end of general support means in Broadcom's words

The vSphere 7 reminder blog says that after 2 October 2025, customers still on 7.x "will not be able to receive product support, security patches and updates". It adds that, under the Broadcom software maintenance policy, previously published fixes "will continue to be available as part of self-service support" for the rest of a customer's maintenance term. KB 456708, which lists the 11 October 2027 end of service for ESXi 8.x, vCenter 8.x, vSAN 8.x, NSX 4.x and VCF 5.2.x, is blunter: after the listed date "there will be no Technical Support and no new patches".

The VCF 9 support model and why 9.x dates are per minor release

Broadcom's July 2025 post on the VCF 9 support model describes the change in detail. Earlier VCF releases followed a "5+2" model: five years of general support, with up to two more years of extended support in some cases, on a two year major release cadence with updates every six months. From VCF 9.0 the model is "6+1": six years of support from the major release, optionally one more year of paid extended support, a major release every three years and minor releases (9.0, 9.1, 9.2, 9.3) about every nine months.

The post says the initial minor releases are expected to get 27 months of support each and the last minor release 45 months, and it estimates an end of service of 17 June 2031 for the 9.x code line. Counting forward from a GA date is tempting, but the exact per minor dates live in the lifecycle matrix, which we could not load. Treat any 9.0 or 9.1 end date you see quoted without a Broadcom link as unconfirmed.

Which security features arrived in which release

ESXi's security model built up over a decade. The table lists features Broadcom documents, with the release where Broadcom or VMware sources place them and the control ID in Broadcom's vSphere 8 Security Configuration Guide where one exists.

Secure Boot and the VIB verifier

With UEFI Secure Boot enabled, Broadcom's hardening guide says a host "refuses to load any UEFI driver or app" unless the bootloader is validly signed, and that ESXi Secure Boot requires "all ESXi kernel modules, drivers, and VIBs be signed by VMware or a partner subordinate". VMware's vSphere Security documentation dates ESXi support for Secure Boot to vSphere 6.5: the bootloader carries a VMware public key, verifies the kernel and a small set of components including a VIB verifier, and the verifier then checks every installed VIB.

There is an upgrade trap. VMware's vSphere 8.0 upgrade documentation warns that a host upgraded from a release without Secure Boot support, or upgraded with ESXCLI commands rather than an ISO, may not be able to turn Secure Boot on, because the bootloader or the VIB signatures were not refreshed. Leftover third party VIBs that the upgrade did not replace can block it too. If you plan to enable Secure Boot on long lived hosts, check this before you flip the firmware switch.

TPM 2.0 and attestation

Broadcom KB 312159 says to "select TPM 1.2 or 2.0 hardware" for vSphere 6.7 GA and later and to verify UEFI Secure Boot support when choosing TPM 2.0; its certification table shows TPM 2.0 requires Secure Boot, while TPM 1.2 with TXT did not. vSphere 8.0's release notes then removed TPM 1.2 entirely: "VMware discontinues support of TPM 1.2 and associated features such as TPM 1.2 with TXT." Servers bought for vSphere 6.x with a TPM 1.2 module soldered to the board cannot use these features on 8.0, and KB 312159 notes the TPM chip usually cannot be changed after purchase.

Configuration encryption

Broadcom KB 421634 is two lines long and worth quoting: in vSphere 7.0 U2 or later "the ESXi configuration is always protected by encryption", and on a host with a TPM "the ESXi configuration encryption key is sealed by the TPM". The hardening guide's control asks for TPM mode on hosts that have a TPM, so the key is sealed by hardware rather than left to the host's software alone. The documented command to switch an existing host to TPM mode cannot be undone, so test it on one host first.

execInstalledOnly and acceptance levels

These two settings answer the same question from different sides. Acceptance levels decide what may be installed: VMwareCertified, VMwareAccepted, PartnerSupported or CommunitySupported. Broadcom's guide says CommunitySupported VIBs "have not undergone testing by VMware or a VMware partner, and they do not have a digital signature". VMkernel.Boot.execInstalledOnly decides what may run: only binaries that came from an installed VIB. The guide says this "makes it harder for attackers to use prebuilt toolkits". Malicious VIBs and dropped binaries are a known technique on ESXi, which our posts on vSphere Installation Bundle persistence and the hypervisor command line cover in detail.

How ESXi patching works

Update releases, patch releases and express patches

Broadcom's build number KB uses two names for each release. The "Release Name" is the marketing name, such as "ESXi 8.0 Update 3e". The "Version" column is the engineering name, such as "ESXi 8.0.3 P05", where the third digit is the update number and the suffix says what kind of release it is.

The KB's own note explains the last column: versions marked "Patch" have no default installer ISO from Broadcom, although server makers may publish custom ISOs. That matters for Secure Boot, since an ISO upgrade refreshes the bootloader and an ESXCLI patch does not.

Two details in the 8.0 rows are easy to miss. First, Broadcom kept patching older update lines in parallel: ESXi 8.0 Update 2f shipped on 3 August 2026 and ESXi 8.0g, on the original 8.0 GA line, on 13 February 2026, long after 8.0 Update 3. A host on 8.0 Update 2 is not automatically unpatched, but you have to check the right line. Second, the letters in "Update 3e" are not a version number you can compare across lines; only the build number increases monotonically within a line.

Images, depots and VIBs

An ESXi installation is a set of VIBs (vSphere Installation Bundles) described by an image profile. Broadcom publishes offline bundles (depot ZIP files) that contain the VIBs and one or more image profiles for each release, for example a standard profile and a "no-tools" profile. Server makers add their own driver and management VIBs as vendor add ons. On a single host, esxcli software profile update moves the host to a new image profile from a depot; esxcli software vib list shows what is installed and at what acceptance level.

vSphere Lifecycle Manager: images replace baselines

Broadcom KB 322186 sets out the direction. vSphere Lifecycle Manager (vLCM) arrived in vSphere 7.0 "as a replacement for the legacy vSphere Update Manager (VUM)", using "an image-based, declarative model" that defines the ESXi version, firmware and drivers for a whole cluster. With vSphere 8.0, VMware deprecated baseline based patching. The capability "will continue to be supported" in vSphere 8 "until its removal in the next Major release". VCF customers can move existing baseline clusters to images only on VCF 5.2.2 or later, and the KB says older VCF versions "should NOT attempt this transition".

The vSphere 8.0 release notes add two smaller changes that catch people out: predefined baselines are restricted to VMware content, so third party async drivers need custom baselines, and the Patch Manager APIs are deprecated. If your patch automation still drives baselines or Patch Manager, it has a fixed end date tied to the move to 9.x.

Order of operations

The 8.0 release notes state the best practice that "the vCenter version is always greater than or equal to the ESXi version". In practice that means vCenter first, then hosts, cluster by cluster, with each host entering maintenance mode so its virtual machines move elsewhere before the update and reboot.

What changed after the Broadcom acquisition

The deal

Broadcom announced on 22 November 2023 that it had "completed its acquisition of VMware, Inc.", and VMware's stock stopped trading on the New York Stock Exchange.

Licensing

On 11 December 2023, Krish Prasad, who leads the VMware Cloud Foundation division, announced the end of sale of perpetual licenses, of Support and Subscription (SnS) renewals for perpetual offerings and of HPP and SPP credits, "beginning today (effective dates will vary)". Offerings would "solely be available as subscriptions or as term licenses". The same post said customers "may continue using perpetual licenses with active support contracts". Read together with the maintenance policy quoted earlier, a perpetual license holder whose support term lapses keeps the right to run the software but loses access to new patches.

The free hypervisor

VMware long offered a free edition of ESXi called vSphere Hypervisor. It was withdrawn after the licensing change, but we could not load Broadcom's own end of availability notice for it, so we do not give a date. What Broadcom does document is the return: KB 399823 says a "free hypervisor version" of ESXi 8.0 Update 3e is available from the Broadcom support portal's free downloads area (8.0 Update 3e is dated 10 April 2025 in the build KB). Its limits, per the KB:

• up to two physical CPUs per host and eight vCPUs per virtual machine
• managed only through the Host Client, not vCenter Server
• no vMotion, DRS, HA or VADP based backups
• API management not supported beyond read only information
• "No official Broadcom support"

The KB lists build 24677879 for the free download, while the main build table lists 8.0 Update 3e as 24674464. Check the build you actually installed before you compare it with an advisory. A free host is still a production grade build, but nobody is entitled to call Broadcom about it, and it updates only when you download and apply a newer image yourself.

Security advisories

VMware security advisories (VMSAs) are published at broadcom.com/support/vmware-security-advisories, which Broadcom's VCF security repository calls "the authoritative source". That repository also points to email notifications on the advisories page and to a JSON API for product security advisories (KB 408302) for automated retrieval, and it hosts supplementary questions and answers for advisories where remediation involves more than updating the product. The response policy itself is the VMware External Vulnerability Response and Remediation Policy. Advisories list the fixed build for each affected line, which is why the build inventory later in this post is the core of patch hygiene.

How the hardware compatibility guide strands older servers

Software support dates are only half of the lifecycle. Each ESXi release supports only the servers, CPUs and I/O devices listed for it in the Broadcom Compatibility Guide (BCG), and that list shrinks between major releases.

The vSphere 8.0 release notes made several hardware cuts at once. vSphere 8.0 "no longer supports CPUs which have been marked as End of Support or End of Life" by their makers. Legacy BIOS boot was deprecated, with a warning that some 8.0 hosts "might not successfully boot in legacy BIOS mode". SD card and USB devices are supported only for boot bank partitions with limitations, new platforms with SD cards are not certified, and Broadcom recommends a separate persistent local device of at least 32 GB for the ESX-OSData volume. TPM 1.2 was removed.

For the 9.x line Broadcom wrote down the process. KB 318697 describes a two step approach. In the Deprecated phase, the installer warns of an upcoming discontinuation, but the CPU series stays supported for the life of that major release, provided the server maker keeps listing the model in the BCG. In the Discontinued phase, the installer "will block or prevent the installation". KB 428874 adds a "VCF Supported. Confirm w/Vendor" status for servers whose maker did not certify them, and defines end of life hardware as not recognised by the ESX 9.x installer, warning that "upgrades from the previous release may also fail".

These lists move. KB 428874 was updated on 18 September 2026 to extend Intel Skylake-SP support, previously discontinued in VCF 9.0, to all of VCF 9.x in deprecated mode, while stating it "will not be extended to VCF releases beyond VCF 9.x". KB 318697 marks AMD EPYC 7001 (Naples) as deprecated in 9.x and discontinued in the next major release.

The practical consequence: a server that cannot run ESXi 8.0 is stranded on 7.0, which has had no new patches since its last listed build in July 2025. A server whose CPU is deprecated in 9.x can be upgraded but has a hard stop at the next major release. Hardware refresh and hypervisor upgrade are one plan, not two.

Walkthrough: inventory builds and map them to support dates and advisories

This routine works on a single host, a cluster or a mixed estate. Steps 1 to 4 only read state. Steps 6 and 7 change hosts; read the warnings first.

Step 1: read the version and build on a host

From the ESXi Shell or an SSH session (enable it only for the task, then turn it off again):

# Product, version, update level and build
esxcli system version get
vmware -vl

# Which image profile the host was built from
esxcli software profile get

esxcli system version get prints the product, version (for example 8.0.3), build and update level. The build number is what you look up in KB 316595.

Step 2: read the same data for every host through vCenter

PowerCLI gives you the whole estate in one table. This is the assessment command Broadcom's hardening guide uses for its "supported" control:

Connect-VIServer -Server vcenter.example.internal

Get-VMHost |
  Select-Object Name, Version, Build, ConnectionState,
    @{N='Cluster';E={$_.Parent.Name}} |
  Sort-Object Version, Build |
  Export-Csv -NoTypeInformation esxi-builds.csv

Export vCenter's own version too ($global:DefaultVIServer | Select Name, Version, Build), since vCenter must be at or above the ESXi version.

Step 3: map builds to release lines and EoGS

Keep a small lookup table from the KB articles in this post and join it to the export. A minimal Python version:

import csv

# End of general support from Broadcom KB 326984, 318892, 415405, 459135.
EOGS = {
    "6.0": "2020-03-12",
    "6.5": "2022-10-15",
    "6.7": "2022-10-15",
    "7.0": "2025-10-02",
    "8.0": "2027-10-11",
}

with open("esxi-builds.csv", newline="") as f:
    for row in csv.DictReader(f):
        line = ".".join(row["Version"].split(".")[:2])
        eogs = EOGS.get(line, "check Broadcom lifecycle matrix")
        print(f'{row["Name"]:30} {row["Version"]:8} build {row["Build"]:>9}  EoGS {eogs}')

Hosts on 9.x print "check Broadcom lifecycle matrix" on purpose: their dates are per minor release and should come from Broadcom, not from arithmetic.

Step 4: check hardening state while you are there

The same pass can read the settings that Broadcom's guide marks P0:

# Acceptance level and anything below PartnerSupported
esxcli software acceptance get
esxcli software vib list | grep -i community

# Configuration encryption mode and Secure Boot requirement
esxcli system settings encryption get

# Only signed, installed binaries may run
esxcli system settings kernel list -o execinstalledonly

# Is the SSH firewall ruleset enabled? (service state is checked in PowerCLI below)
esxcli network firewall ruleset list -r sshServer

# Lockdown mode, Secure Boot capability and services, per host
Get-VMHost | ForEach-Object {
  [pscustomobject]@{
    Host       = $_.Name
    Lockdown   = (Get-View ($_ | Get-View).ConfigManager.HostAccessManager).LockdownMode
    SecureBoot = ($_ | Get-View).Capability.UefiSecureBoot
    SSH        = ($_ | Get-VMHostService | Where-Object Key -eq 'TSM-SSH').Running
    Shell      = ($_ | Get-VMHostService | Where-Object Key -eq 'TSM').Running
  }
} | Format-Table

The Secure Boot capability check needs PowerCLI 13.3 or later, according to the guide.

Step 5: match builds against advisories

For each advisory that names ESXi or ESX, note the fixed build for each line you run, then flag every host whose build is lower on that same line. Pull advisories by email subscription or through the JSON API that Broadcom documents in KB 408302 rather than by reading news coverage. Remember the parallel lines: a fix in 8.0 Update 3k does not tell you the fixed build for a host that stays on the 8.0 Update 2 line.

Step 6: plan the move off unsupported lines

Warning: the commands in steps 6 and 7 change hosts and require a reboot. Confirm the host name and that its virtual machines have been evacuated before you run anything.

For each host on 7.0 or earlier, check its server model and CPU in the Broadcom Compatibility Guide for 8.0 or 9.x first. If the model is not listed, the plan is new hardware, not an upgrade. Convert clusters from baselines to images before you rely on vLCM for the jump.

Step 7: apply an image to one host (standalone example)

On clusters, use vLCM images from vCenter. For a standalone or free host, the depot route looks like this:

# 1. Confirm you are on the host you mean to change
hostname
esxcli system version get

# 2. Put it in maintenance mode (VMs must already be shut down or moved)
esxcli system maintenanceMode set --enable true

# 3. List profiles in the depot you downloaded from the Broadcom portal
esxcli software sources profile list -d /vmfs/volumes/datastore1/depot.zip

# 4. Dry run first, then apply the chosen profile
esxcli software profile update -d /vmfs/volumes/datastore1/depot.zip -p <profile-name> --dry-run
esxcli software profile update -d /vmfs/volumes/datastore1/depot.zip -p <profile-name>

# 5. Reboot, then confirm the new build and leave maintenance mode
reboot
esxcli system version get
esxcli system maintenanceMode set --enable false

Re-run step 4 afterwards. If you intend to turn on Secure Boot, prefer an ISO based upgrade for the reason given earlier.

ESXi compared with other hypervisor platforms

Each platform below publishes its own lifecycle; the table compares the models, not the products. Dates come from each vendor's own pages.

For the other two lifecycles in detail, see our Proxmox VE release history and the Windows Server release history. If you are weighing a homelab or small cluster move, our Proxmox VE homelab guide covers hardening on that side.

Common mistakes

• Running past end of general support. A 7.0 host has had no new patches since general support ended on 2 October 2025, and a 6.7 host since October 2022. Broadcom's hardening guide makes "not reached End of General Support" a P0 control for a reason.
• Reading the update letter instead of the build. "Update 3e" on one line and "Update 2e" on another are different builds with different fixes. Compare build numbers within a line.
• Assuming the free edition patches itself. It has no vCenter, no support entitlement and no lifecycle automation; it changes only when someone applies a newer image.
• Installing CommunitySupported VIBs to make a driver or tool work. They are unsigned by definition, drop the host's acceptance level and block Secure Boot.
• Leaving SSH and the ESXi Shell running after a support session. Both default to stopped and manual. Set UserVars.ESXiShellTimeOut (the guide suggests 600 seconds) so a forgotten session closes itself.
• Turning on Secure Boot without checking the upgrade history. Hosts upgraded through ESXCLI or carrying old third party VIBs may fail the check. Test on one host first.
• Never enabling lockdown mode. The guide's P0 control is normal lockdown, with the DCUI access list and exception users set first so you do not lock yourself out.
• Buying servers without TPM 2.0, or keeping TPM 1.2 boards. TPM 1.2 support ended with 8.0, and the chip is usually not replaceable.
• Planning the hypervisor upgrade separately from the hardware refresh. The compatibility guide decides which release a server can run; check it before the change window, not during it.
• Keeping patch automation on baselines. Baselines are deprecated in 8.0 and removed in the next major release.

FAQ

When does ESXi 8.0 reach end of support?

Broadcom KB 459135 gives ESXi 8.x an end of general support date of 11 October 2027, five years after its 11 October 2022 GA. KB 456708 lists the same date for vCenter 8.x, vSAN 8.x and NSX 4.x and says there are no new patches after it.

Is ESXi 7.0 still supported?

Not for patches. KB 415405 says general support for vSphere 7.0 ended on 2 October 2025, after a six month extension from 2 April 2025. The last 7.0 build in Broadcom's build table is 7.0 Update 3w, 15 July 2025.

What is the latest version of ESXi?

The newest build in Broadcom KB 316595 as of 25 October 2026 is ESX 9.1.1.0100, build 25782009, dated 12 October 2026. On the 8.0 line the newest is ESXi 8.0 Update 3k, build 25595708, dated 29 July 2026.

Why is ESXi called ESX again in version 9?

Broadcom's build table and documentation use "ESX" for every 9.x release. It is the same thin hypervisor that replaced the old service console ESX; the Linux service console did not come back.

How do I find the ESXi build number?

Run esxcli system version get or vmware -vl on the host, or Get-VMHost | Select Name, Version, Build in PowerCLI. Look the build up in Broadcom KB 316595 to see its release name and date.

Is the free version of ESXi available again?

Yes, for ESXi 8.0 Update 3e according to Broadcom KB 399823. It is limited to two physical CPUs per host and eight vCPUs per virtual machine, cannot be managed by vCenter and has no official Broadcom support.

What is the difference between an ESXi update and a patch?

An update (the third digit, as in 8.0.3) adds features and hardware support and usually ships as an ISO. Patches (P) and express patches (EP) are maintenance and out of band fix releases on an update line, often available only as offline bundles.

Are vSphere Lifecycle Manager baselines going away?

Yes. vSphere 8.0 deprecated baselines, and Broadcom KB 322186 says they will be removed in the next major release. Image based lifecycle management with vLCM is the replacement.

When did ESX become ESXi only?

From vSphere 5.0, released on 24 August 2011. ESX 4.0 and 4.1 shipped both editions, and the last classic ESX patch in Broadcom's build table is ESX 4.1 Patch 11a from 1 October 2014.

Can I run ESXi 8 on an old server?

Only if the server, CPU and I/O devices are listed for 8.0 in the Broadcom Compatibility Guide. vSphere 8.0 dropped CPUs their makers had marked end of life, deprecated legacy BIOS boot and removed TPM 1.2 support.

The hypervisor itself is a vendor product, so its fixes can only come from Broadcom, on the schedule this post describes. The software around it is a different matter: the automation scripts, Python and PowerShell modules, infrastructure as code providers and the applications and container images running in your virtual machines all carry open source dependencies that you build and ship yourself, and those you can fix on your own timetable.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Safeguard does not scan ESXi hosts, read their builds or apply Broadcom patches; the inventory and patch steps above are yours to run. Where it fits is the code you build around and on top of the hypervisor.

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. On the admin workstation or build host that holds your PowerCLI scripts, Python inventory tools and infrastructure as code, that is how you scan those repositories and the container images your virtual machines run.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow applies to a vulnerable dependency in an internal tool that talks to the vSphere API, where the fix is a dependency change you make and test yourself.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For a platform team, once it is connected you can ask which of your projects contain a given component and version while you plan the hypervisor change window, without leaving the conversation.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

For ESXi specific threats, our posts on ESXi ransomware campaigns in 2024, the ESXi admin command technique and the March 2025 Broadcom VMware zero days cover the incident side that this post leaves out.

Quick check

Sources

• Broadcom KB 316595: Build numbers and versions of VMware ESXi/ESX
• Broadcom KB 459135: End of General Support for vSphere 8.0
• Broadcom KB 415405: End of General Support for vSphere 7.0
• Broadcom KB 326984: End of General Support for vSphere 6.5/6.7/7.0
• Broadcom KB 318892: End of General Support for vSphere 6.0
• Broadcom KB 456708: Upcoming End of Service for vSphere 8, vSAN 8, Aria 8, NSX 4 and VCF 5
• Broadcom KB 399823: VMware ESXi 8.0 Update 3e now available as a Free Hypervisor
• Broadcom KB 322186: Managing ESXi host lifecycle operations with vSphere Lifecycle Manager Images
• Broadcom KB 312159: VMware vSphere support of TPM and TXT
• Broadcom KB 421634: ESXi configuration encryption
• Broadcom KB 318697: CPU Support Deprecation and Discontinuation in VCF Releases
• Broadcom KB 428874: Deprecated CPU Systems / Servers in ESX 9.0 and implications for support
• VMware vSphere 8.0 release notes (Broadcom TechDocs)
• VMware VCF blog: VMware Cloud Foundation 9 ushers in new support model and release cadence (16 July 2025)
• VMware VCF blog: Reminder, vSphere 7 to reach end of service October 2, 2025
• Broadcom: Broadcom Completes Acquisition of VMware (22 November 2023, archived copy)
• VMware by Broadcom: Dramatically simplifies offer lineup and licensing model (11 December 2023, archived copy)
• VMware press release: VMware unveils next generation hypervisor to be integrated in server hardware (10 September 2007, archived copy)
• VMware vSphere 5.0 release notes (2011, archived copy)
• VMware VCF Security and Compliance Guidelines repository
• VCF Security and Compliance Guidelines: VMware Security Advisory resources
• VMware vSphere 8 Security Configuration Guide controls (CSV)
• William Lam: ESX Server 1.0 trip down memory lane (2023)
• Proxmox VE FAQ: support lifecycle table
• Proxmox VE Roadmap
• Microsoft Lifecycle: Windows Server 2025
• Microsoft Lifecycle: Fixed Lifecycle Policy

Last reviewed: 25 October 2026. Support dates change; check Broadcom's knowledge base articles linked above before planning an upgrade.