Broadcom's fixed version for vCenter 7.0 is a support contract

Broadcom issued VMSA-2026-0006 on July 29, 2026 for CVE-2026-59310, a CVSS 9.8 directory traversal in the vCenter syslog server. The response matrix gives a build number for every vCenter line except one. The row for vCenter 7.0 reads, in full: "Contact Broadcom Support if you have extended support contract."

That row was not in the original advisory. The change log entry for VMSA-2026-0006.2, dated August 19, says: "Added ESX/vCenter 7.0 patch guidance for Critical severity issues." By then the bug had been exploited for sixteen days and had been in CISA's Known Exploited Vulnerabilities catalog for one.

Broadcom's description: "A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code." Workarounds: None. In the intrusions QUIRSO investigated, reported by The Hacker News on August 12 and August 17, the first artifact was a malformed file under /etc/cron.d named zz-poc59310-syslog.log, which cron ran as root. From root the actor added cron jobs named after VMware services, created vSphere SSO administrators, pulled the vmdir machine credentials, and created local accounts on the ESXi hosts. On the one appliance analysed in depth, a Babuk-derived locker then wrote .babyk files on ESXi; QUIRSO could not say whether it reached other victims. First contact with attacker infrastructure was August 3, five days after disclosure, across 361 victim IPs in 47 countries, 41 in the US. As of September 15, no victim has been named.

The full vCenter matrix for the two critical CVEs, quoted from the advisory:

Seven rows name a build, a patch path, or a KB. One names a commercial relationship. Broadcom's supplemental FAQ says vSphere 7 reached End of General Support on October 2, 2025, and that contract holders should "use those processes to request patches." The same FAQ, as revised August 19 and still live on September 15, says Broadcom "has no information to suggest that exploitation of these issues has occurred in the wild."

The structural problem is how trackers model a fix. Most key "patch available" to the CVE, not to the instance, so the 7.0 ticket closes with the rest. There is no field for "the fix on this version is a contract you may not hold."

Treat the fixed version as a per-instance fact

Record, for every vCenter you run, the advisory's fixed version for that major version, and refuse to close a ticket on a row that names no build. For 7.0 that leaves three paths, each with a cost.

The extended support contract. If you hold one, the patch exists but has no public build number; you request it through support, and the case number is what the ticket tracks. If you do not hold one, this is a procurement conversation, and security should open it.

The upgrade to 8.0 U3k. This is a migration, not a patch window. Check the interoperability matrix for your ESXi versions, and read the FAQ's note that some of these updates impose a "back-in-time" upgrade restriction. Give it a date; until then the 7.0 hosts are unpatched.

Network placement, for hosts on neither path. The Workarounds column says None, so reachability is the one control the vendor does not supply. The syslog listener and management interface should answer only to the ESXi management network and an admin jump host. That costs every tool and engineer that reaches vCenter directly today, which is why it rarely happens before an incident. Start with the 7.0 instances.

The KEV row also changed after most teams filed this CVE. CISA added it to KEV on August 18 with a due date of August 21, the three-day window BOD 26-04 now assigns. The catalog dated 2026.09.04 carried the ransomware flag as "Unknown." The catalog dated 2026.09.11 carries it as "Known." The due date did not move. A tracker that ingested the row once has a stale flag, and a program that waits on KEV to trigger a patch was three weeks late when it changed. End-of-support infrastructure has the same ownership gap as legacy systems mid-migration: nobody owns the row.

How to check

• On every vCenter appliance, run vpxd -v and list the 7.0 instances by name.
• For each 7.0 instance, record whether an extended support contract exists and the support case number for the patch. No case number means no patch.
• List /etc/cron.d on every vCenter. Files ending in -syslog.log or named vmware-vpxd-stats-* or vmware-perf-* are QUIRSO's indicators, as is /etc/sudoers.d/vmware-perf. Then confirm, from a workstation subnet, that the syslog port and port 443 do not answer.
• List the vSphere SSO Administrators group and the local accounts on each ESXi host. adminuser and vcadmin were the names QUIRSO saw; any account you did not create is the finding.
• Re-read the KEV row for CVE-2026-59310 today, not the ticket that quoted it in August.

North InfoSec runs AI-assisted penetration testing and security assessments, including the kind that follows a reachable vCenter through to the ESXi hosts it manages. northinfosec.com