Broadcom released VMware vSphere 8.0 Update 3k on 29 July 2026, delivering critical security fixes for both vCenter Server and ESXi.
Normally, the recommendation would be straightforward: review the release notes, validate the patch in a test environment, and deploy it as quickly as your change-management process allows.
This release, however, comes with an important complication:
After upgrading vCenter Server to 8.0 Update 3k, you cannot currently upgrade that vCenter to VMware Cloud Foundation 9.1 or any existing vCenter release based on the 9.1.0 branch.
Broadcom has explicitly identified this as a back-in-time upgrade restriction. A supported forward upgrade path will only become available with a future VMware Cloud Foundation 9.1.x release.
That leaves administrators with a difficult but important decision: remediate critical vulnerabilities now and temporarily lose the VCF 9.1 upgrade path, or complete a planned VCF 9.1 migration before installing the 8.0 U3k patch.
vSphere 8.0 Update 3k Release Information
The two primary components released for vSphere 8.0 are:
| Component | Release | Version or build |
|---|---|---|
| vCenter Server | vCenter Server 8.0 Update 3k | 8.0.3.01000, build 25600417 |
| ESXi | ESXi 8.0 Update 3k | ESXi80U3k, build 25595708 |
Both releases were published on 29 July 2026.
The patches form part of VMSA-2026-0006, which addresses multiple vulnerabilities affecting VMware ESX, vCenter Server, VMware Cloud Foundation, VMware vSphere Foundation, Workstation, Fusion and VMware Telco Cloud products.
Broadcom rates the overall advisory as Critical, with CVSS scores ranging from 2.7 to 9.8.
The Critical vCenter Vulnerabilities
vCenter Server 8.0 Update 3k resolves two critical vulnerabilities, both carrying a maximum CVSSv3 score of 9.8.
CVE-2026-59309: vCenter Authentication Bypass
CVE-2026-59309 is an authentication-bypass vulnerability in the VMware Directory Service, commonly associated with the vCenter Single Sign-On and identity infrastructure.
According to Broadcom, an attacker with network access to vCenter may be able to exploit the vulnerability to bypass authentication and obtain unauthorised access to the system.
The important part is that the attack vector does not require an existing authenticated vCenter account.
Broadcom lists:
- Severity: Critical
- Maximum CVSSv3 score: 9.8
- Attack requirement: Network access to vCenter
- Workaround: None
- Fixed vCenter 8.0 release: 8.0 Update 3k
For administrators, this reinforces a security principle that should already be standard practice: vCenter Server should never be unnecessarily exposed to general user networks or directly to the Internet.
Access to the vCenter management interface should be restricted to dedicated management networks, administrative jump hosts, VPN connections and explicitly authorised systems. Network isolation reduces exposure, but it does not replace the patch.
CVE-2026-59310: vCenter Directory Traversal and Remote Code Execution
CVE-2026-59310 is a directory-traversal vulnerability affecting the vCenter Syslog server.
A malicious actor with network access to vCenter may be able to exploit the vulnerability to execute arbitrary code on the appliance.
Broadcom also rates this vulnerability as Critical with a maximum CVSSv3 score of 9.8.
Broadcom lists:
- Severity: Critical
- Maximum CVSSv3 score: 9.8
- Attack requirement: Network access to vCenter
- Potential impact: Arbitrary code execution
- Workaround: None
- Fixed vCenter 8.0 release: 8.0 Update 3k
The combination of authentication bypass and arbitrary code execution makes vCenter 8.0 Update 3k a high-priority security release.
The Critical ESXi Vulnerability
CVE-2026-47876: VMXNET3 Out-of-Bounds Write
ESXi 8.0 Update 3k resolves CVE-2026-47876, an out-of-bounds write vulnerability in the VMXNET3 virtual network adapter.
An attacker with local administrative privileges inside a virtual machine configured with a VMXNET3 adapter may be able to exploit the vulnerability and execute code on the ESXi host.
This represents a potential guest-to-host escape path.
Broadcom lists:
- Severity: Critical
- Maximum CVSSv3 score: 9.3
- Required access: Local administrative privileges inside a virtual machine
- Affected adapter: VMXNET3
- Potential impact: Code execution on the ESXi host
- Workaround: None
- Fixed ESXi 8.0 release: ESXi80U3k-25595708
Virtual machines using non-VMXNET3 virtual network adapters are not affected by this specific vulnerability.
VMXNET3 is widely used in production VMware environments because it provides better performance and functionality than emulated adapters. Therefore, the fact that the issue specifically affects VMXNET3 does not meaningfully reduce the urgency for most enterprise environments.
ESXi 8.0 U3k Is Live-Patchable
Broadcom describes ESXi 8.0 Update 3k as a live-patchable release.
That can potentially reduce disruption by allowing the security fix to be applied without a complete host reboot when all live-patching requirements are satisfied.
However, administrators should not assume that every host remediation will automatically be rebootless.
The final remediation behaviour can depend on:
- The current ESXi build
- Additional components included in the desired image
- OEM vendor add-ons
- Driver and firmware changes
- Cluster image compliance
- The lifecycle-management method being used
Always review the remediation impact displayed by vSphere Lifecycle Manager before proceeding.
Other Vulnerabilities Included in VMSA-2026-0006
VMSA-2026-0006 also includes two additional ESX-related vulnerabilities.
CVE-2026-41703
This is an out-of-bounds read vulnerability that may allow a user with VM deployment privileges to cause information disclosure or, more likely, a denial-of-service condition affecting the host process.
For ESXi 8.0, Broadcom identifies ESXi 8.0 Update 3i as the first fixed release.
CVE-2026-41709
This is an insufficient-logging vulnerability that may allow a malicious administrator to perform certain operations without those operations being recorded correctly.
For ESXi 8.0, Broadcom identifies ESXi 8.0 Update 3j as the first fixed release.
Because ESXi patches are cumulative, ESXi 8.0 Update 3k also contains these earlier fixes.
What Does “Back in Time” Mean?
A back-in-time upgrade does not necessarily mean that the destination product has a lower major version number.
Instead, it means that the proposed destination release was created without some of the code or security changes already present in the source release.
Broadcom defines a back-in-time scenario as an upgrade path that could deliberately regress code or security fixes. Such upgrade paths are not supported.
In this case:
- vCenter Server 8.0 Update 3k was released on 29 July 2026.
- The currently available vCenter 9.1.0 releases do not provide a supported upgrade path from 8.0 U3k.
- Installing the currently available 9.1.0 destination over 8.0 U3k could effectively move the environment to a destination that does not recognise or preserve everything contained in the newer 8.0 patch branch.
Therefore, despite moving numerically from version 8 to version 9, the operation is treated as a back-in-time upgrade.
The Exact Upgrade Restriction
The vCenter Server 8.0 Update 3k release notes state that upgrading from vCenter 8.0 U3k to the following destinations is not supported:
- vCenter 9.1.0
- Any currently available patch based on vCenter 9.1.0
Broadcom states that a supported forward upgrade path will become available in a future 9.1.x release.
This is the most important operational consideration associated with the release.
Important Clarification About VCF 9.1
It would not be entirely accurate to say that there is no secured VMware Cloud Foundation 9.1 release.
Existing VCF 9.1 environments have security fixes available:
| VCF 9.1 component | Fixed release |
|---|---|
| vCenter | 9.1.0.0300 |
| ESXi | ESXi-9.1.0.0200-25557999 |
The problem is specifically the upgrade path from vCenter 8.0 Update 3k into the current 9.1.0 branch.
In other words:
- Existing VCF 9.1 environments can be patched.
- vSphere 8 environments can be patched to 8.0 U3k.
- An environment already running vCenter 8.0 U3k cannot currently be upgraded directly to the available VCF 9.1 targets.
- A future VCF 9.1.x destination release will restore that forward upgrade path.
What Should Administrators Do?
There is no single answer that fits every environment, but the following scenarios should help with planning.
Scenario 1: You Are Staying on vSphere 8.0
If there is no immediate plan to move to VCF 9.1, the decision is relatively straightforward.
Validate and deploy:
- vCenter Server 8.0 Update 3k
- ESXi 8.0 Update 3k
The two critical vCenter vulnerabilities have no documented workaround, and both carry CVSS scores of 9.8. The ESXi VMXNET3 vulnerability is rated 9.3 and also has no workaround.
Scenario 2: You Are About to Upgrade to VCF 9.1
This scenario requires careful sequencing.
When an upgrade to VCF 9.1 is already approved and scheduled, one possible path is:
- Confirm that your existing pre-U3k vCenter release has a supported upgrade path to the intended VCF 9.1 target.
- Complete the VCF 9.1 upgrade.
- Apply the current VCF 9.1 security patches immediately after the upgrade.
- Verify that vCenter and ESXi are running the fixed 9.1 component versions.
Do not assume that a path is supported simply because the source and target major versions look correct. Validate the exact source and target builds in Broadcom’s interoperability and upgrade-planning tools.
Scenario 3: You Have Already Installed vCenter 8.0 U3k
Do not attempt to force an upgrade to vCenter 9.1.0 or one of its currently available patches.
Do not attempt to bypass installer pre-checks or manually manipulate version information.
Remain on the secured 8.0 U3k branch until Broadcom publishes a future VCF 9.1.x release that explicitly supports the upgrade.
Scenario 4: You Are Running VMware Cloud Foundation 5.x
VCF-managed environments must follow the VCF lifecycle-management process.
Broadcom’s response matrix identifies vCenter 8.0 U3k and ESXi 8.0 U3k as asynchronous patches for affected VCF 5.x environments. These patches should be introduced through the supported Async Patch Tool and SDDC Manager lifecycle workflow, rather than patched independently as though the components were part of a standalone vSphere deployment.
The Async Patch Tool integrates individual component patches with SDDC Manager lifecycle automation and records the patched versions so that future VCF upgrades do not attempt to overwrite them with older components.
Check Your Current Versions
Check vCenter in PowerCLI
Connect-VIServer vcenter.example.com
$global:DefaultVIServer |
Select-Object Name, Version, Build
The fixed vCenter 8.0 release should report:
Version: 8.0.3
Build: 25600417
You can also verify the version through:
- vSphere Client: Menu > Administration > System Configuration
- vCenter Server Management Interface:
https://vcenter-fqdn:5480 - The vSphere Client About dialog
Check ESXi Host Versions
From an ESXi shell or SSH session:
vmware -vl
Alternatively:
esxcli system version get
The fixed ESXi build is:
VMware ESXi 8.0 Update 3k
Build 25595708
To review all connected hosts through PowerCLI:
Get-VMHost |
Select-Object Name, Version, Build |
Sort-Object Name
Inventory Virtual Machines Using VMXNET3
The following PowerCLI command identifies virtual machines configured with VMXNET3 adapters:
Get-VM |
Get-NetworkAdapter |
Where-Object {
$_.Type -eq "Vmxnet3"
} |
Select-Object `
@{Name = "VM"; Expression = { $_.Parent.Name }},
Name,
Type
This inventory can help determine how widely VMXNET3 is used, but changing adapter types should not be treated as a replacement for installing the ESXi security update.
Changing a production VM’s virtual network adapter can also require guest operating system changes, new network interface identification, IP reconfiguration and application downtime.
Suggested Patching Workflow
For a normal standalone vSphere environment, I would use the following high-level process:
- Review VMSA-2026-0006 and both 8.0 U3k release notes.
- Confirm the current vCenter and ESXi builds.
- Check whether a VCF 9.1 migration is scheduled.
- Validate backup and recovery procedures for vCenter.
- Confirm that the vCenter file-based backup is current and usable.
- Take configuration backups of relevant infrastructure components.
- Patch vCenter Server to 8.0 Update 3k.
- Validate vCenter services, authentication, certificates, inventory and external integrations.
- Perform a vSphere Lifecycle Manager compliance check.
- Review OEM add-ons, firmware and driver compatibility.
- Remediate ESXi hosts one at a time or according to cluster policy.
- Confirm whether live patching or a reboot will be required.
- Validate HA, DRS, vSAN, networking, storage paths and VM health.
- Record the final component builds in the change evidence.
For VCF environments, replace the standalone component-patching steps with the appropriate SDDC Manager or Async Patch Tool workflow.
My Recommendation
Security should take priority.
CVE-2026-59309 and CVE-2026-59310 are network-accessible, critical vCenter vulnerabilities with maximum CVSS scores of 9.8 and no documented workarounds. CVE-2026-47876 introduces a potential VMXNET3 guest-to-host code-execution path and is rated 9.3.
For environments that are not immediately moving to VCF 9.1, I would patch vCenter and ESXi after completing the normal validation process.
For environments already in the final stages of a VCF 9.1 migration, I would urgently review whether it is safer and operationally possible to complete the supported VCF upgrade first and then apply the fixed VCF 9.1 patches.
What I would not recommend is remaining indefinitely on a vulnerable vCenter build merely to preserve a future upgrade path.
The back-in-time restriction must be considered, documented and communicated, but it should not be used as an excuse to ignore two unauthenticated, network-accessible vCenter vulnerabilities with critical severity scores.
Final Thoughts
vSphere 8.0 Update 3k is not a routine maintenance release.
It fixes serious vulnerabilities affecting the core management plane and the ESXi virtualisation boundary. At the same time, it creates a temporary fork in the upgrade strategy for organisations planning to adopt VMware Cloud Foundation 9.1.
Before installing the update, administrators need to answer one question:
Are we securing and remaining on vSphere 8 for now, or are we immediately completing a supported move to VCF 9.1 and applying its corresponding security patches?
Once vCenter 8.0 Update 3k is installed, the currently available path to VCF 9.1 closes until Broadcom publishes a compatible future 9.1.x destination.
Patch urgently—but understand exactly where that patch places your environment on the upgrade roadmap.