VMSA-2026-0006 Is Rated Critical The Full Severity Picture, and the Remediation Map for Every Stream

Share
VMSA-2026-0006 Is Rated Critical The Full Severity Picture, and the Remediation Map for Every Stream

Two 9.8s on vCenter an authentication bypass and a remote code execution path plus a 9.3 guest-to-host escape out of Pwn2Own. No workarounds on any of them. The advisory’s 3 August revision also added 8.0 U2f patches. Here’s the architect’s read of the complete public advisory, and the patch target for every estate.

When I covered the 29 July Express Patch wave across three posts, I deliberately declined to characterise severity the advisory is the authoritative source, and same-day commentary shouldn’t guess. The public advisory has since been updated (VMSA-2026-0006.1, revised 3 August), and the full picture is now on the record: this advisory is rated Critical, with CVSSv3 scores ranging from 2.7 to 9.8 across five CVEs, affecting VMware ESX, vCenter, Workstation, Fusion, VCF, VVF, and Telco Cloud Platform/Infrastructure. If your estate hasn’t remediated yet, this post is the complete map.

 

The Five CVEs, In Architect’s Language

•      CVE-2026-59309 vCenter authentication bypass, CVSS 9.8, Critical. A flaw in the VMware Directory Service allows an actor with network access to vCenter to bypass authentication and gain unauthorised access. Read that plainly: reachability to vCenter is the entire exploitation precondition. Reported by Phil Brass and Matt South of Atredis Partners.

•      CVE-2026-59310 vCenter directory traversal, CVSS 9.8, Critical. A directory traversal in vCenter’s Syslog server allows an actor with network access to execute arbitrary code. Same precondition, worse outcome: network reachability to code execution on the management plane’s most important component.

•      CVE-2026-47876 ESX VMXNET3 out-of-bounds write, CVSS 9.3, Critical. A malicious actor with local administrative privileges inside a VM using a VMXNET3 adapter can execute code on the host the guest-to-host escape class. Non-VMXNET3 adapters are not affected. Credited to Nguyen Hoang Thach of STARLabs SG via the Pwn2Own competition with the Zero Day Initiative which means a working exploitation approach was demonstrated to earn that credit.

•      CVE-2026-41703 out-of-bounds read, CVSS 7.6 on ESX, Important. An actor with VM deployment privileges can trigger information disclosure or, more likely, denial of service of the host process. On Workstation and Fusion the impact reduces to information disclosure (2.7, Low).

•      CVE-2026-41709 ESX insufficient logging, CVSS 2.7, Low. A malicious administrator can perform certain operations without them being logged an audit-trail integrity issue rather than an access issue. Credited to Ian Barton of CrowdStrike.

 

One line from the advisory deserves its own paragraph: Workarounds None. On all five. There is no configuration change, no port to close, no feature to disable that substitutes for the patch. Patching is the control.

 

What the .1 Revision Added

The 3 August revision matters for one population specifically: estates on the vSphere 8.0 U2 line. The initial advisory’s 8.x fixed versions centred on U3k; the .1 revision adds ESXi 8.0 U2f and vCenter 8.0 U2f express patches a direct remediation path for U2-line estates without first absorbing the jump to U3. If your remediation plan last week assumed a U3 upgrade as a prerequisite, revisit it; the direct path now exists.

 

The Remediation Map Every Stream

Stream                  Fix target (per the advisory response matrix)
---------------------   ---------------------------------------------
VCF / VVF 9.1.x         vCenter 9.1.0.0300; ESX 9.1.0.0200
                        (41703/41709 fixed in 9.1.0.0 GA)
VCF / VVF 9.0.x         vCenter 9.0.2.0100; ESX 9.0.2.0100
vSphere 8.0 (U3 line)   vCenter 8.0 U3k; ESXi 8.0 U3k
                        (41703: U3i; 41709: U3j - cumulative)
vSphere 8.0 (U2 line)   vCenter 8.0 U2f; ESXi 8.0 U2f  [NEW in .1]
VCF 5.x                 vCenter async-patched to 8.0 U3k per
                        KB88287; ESX CVEs per 5.2.3 / 5.2.4 +
                        async guidance
Telco Cloud (TCP/TCI)   Per KB449886
Workstation / Fusion    26H1

 

Note the advisory’s own cumulativity reminder: patches are cumulative, so the newest version in each stream carries all prior fixes 9.1.0.0300 includes the 59309 fix that first shipped in 9.1.0.0200. Target the newest, not the first-fixed.

 

The Architect’s Read Beyond “Patch Now”

Patch now is the instruction; three design observations follow from how these CVEs work.

 

First: both 9.8s are network-precondition vulnerabilities against vCenter. The population that can exploit them is exactly the population that can reach your vCenter endpoints. This is the strongest argument in years for auditing management-plane network exposure which subnets, which jump paths, which automation systems, and which monitoring tools can open a connection to vCenter. Segmentation doesn’t substitute for the patch (no workarounds, remember), but the blast-radius difference between ‘vCenter reachable from the corporate LAN’ and ‘vCenter reachable from a controlled management zone’ is the difference in how much time an unpatched window actually exposes you to.

 

Second: the VMXNET3 escape reframes guest-admin trust. CVE-2026-47876’s precondition is local admin inside any VM with a VMXNET3 adapter which is to say, the default adapter on most modern templates, in estates where guest-admin rights are held by application teams, tenants, or VDI users. Multi-tenant platforms and VDI estates should treat host patching for this CVE as their top priority from this advisory, because their threat model includes exactly the actor the CVE requires. And the Pwn2Own provenance means the technique isn’t theoretical.

 

Third: the syslog attack surface earns attention. A code-execution path through vCenter’s Syslog server is a reminder that logging infrastructure is attack surface, not just telemetry plumbing worth pairing with the 9.x logging changes (unencrypted 514 blocked, TLS 1514 as the standard) when you review the management plane’s listening services.

 

On operational speed: everything from the earlier three posts stands. The ESX fixes ride Live Patch on eligible 9.x hosts and image-managed 8.x clusters; vCenter fixes ride the Quick Patch class on 9.x. For estates that adopted the lifecycle model, closing a Critical advisory is a same-week operation and for the ones that haven’t, this advisory is the sharpest version yet of the argument.

 

What to Do

•      Patch vCenter first, on every stream both 9.8s live there, and the vCenter operation is the fastest one you’ll run this week.

•      Then hosts prioritising clusters whose guests carry third-party or user-held admin rights (the VMXNET3 threat model).

•      VCF 5.x estates: follow the async patching guide (KB88287) for the vCenter path to 8.0 U3k and note this is the standing pattern for security currency on 5.x while the 9.x transition is planned.

•      Review vCenter network reachability while the patch change records are open the audit is free while the estate’s attention is already on the management plane.

•      Subscribe to VMware Security Advisories directly (link below) advisory-day speed starts with hearing about the advisory on advisory day.

 

Sources All Public

•      VMSA-2026-0006.1 full advisory and response matrices (Broadcom Support, notification 38017)

•      Broadcom Supplemental FAQ for VMSA-2026-0006

•      Broadcom VMware Security Advisories portal (subscribe here)

•      Broadcom KB 88287 VCF Async Patching Guide

 

Earlier Field Guide coverage of this advisory: the 9.0.2 wave, the 9.1 single-patch piece, and the 8.0 U3k live-patch-eligibility piece.