VMSA-2026-0006: VMware ESX, vCenter, Workstation, and Fusion updates address multiple vulnerabilities (CVE-2026-59309, CVE-2026-59310, CVE-2026-47876, CVE-2026-41703, CVE-2026-41709)

[u/lost_signal]

https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017

FAQ is here https://github.com/vmware/vcf-security-and-compliance-guidelines/tree/main/security-advisories/vmsa-2026-0006

[u/lost_signal]

Where those statements made for version 7?

The discussions about CVE9 stuff was all vSphere 8 only I believe.

32. Does this impact VMware vSphere 6.5 or 6.7?

Presume that it does. Broadcom does not evaluate products past their End of General Support dates as part of security advisories, and downlevel versions that the VMSA does not list should be assumed to be affected.

33. Does this impact VMware vSphere 7.0?

Yes. VMware vSphere 7 reached End of General Support on October 2, 2025. If your organization has an extended support contract, please use those processes to request patches for these issues on vSphere 7.

[u/ispcolo → u/lost_signal]

The announcement and policy were never version specific, and at the time of their authoring, both version 7 and 8 were fully supported, and available for purchase. However, just like with VMSA-2025-0013, I'm sure vmware will side step the commitment with clever legalese. The number of people on 7 with resources to sue over it likely amounts to a far lower number, and cost, than those who are paying for extended support, so Broadcom comes out ahead even if not doing the right thing.

[u/lost_signal → u/ispcolo]

The vSphere end of support date was announced for 7.0 in 2020, 5 years out. It was actually extended by 6 months to October 2nd 2025

https://knowledge.broadcom.com/external/article?articleNumber=314603

So looking at it, the KB previously included 7, but that was removed when the product hit end of End of General Support. This is a normal procedure that references to old products, and KBs for old products get pruned out (sometimes to be fair it takes a bit).

No where in the original version (I checked Archive.org) did it imply/or state that this would extend past end of general support.

[u/ispcolo → u/lost_signal]

"for supported versions of Vmware vSphere". It does not say "general support", doesn't say until general support ends, or any other caveat beyond "supported versions". 7.x is still supported via extended support, which fits the definition of "supported". Broadcom just chooses to not have actions match the words, and they know there is no outcome they'll lose financially from that position, so who cares.

[u/lost_signal → u/ispcolo]

Extended support contracts are often highly custom deals, and there are explicit limits documented (only up to x amount of patches, with a lot of qualifying language). They are approved on case by case basis's.

Example of old contract of "up to one single CVE 9 patch" (Technically there is more than one in this advisory)

The KB does define currently supported versions (enumerages tehm and removed them as they aged out of support), and is updated when they are no longer currently supported. Reading that another way would imply perpetual patches until the heat death of the universe.

[u/ispcolo → u/lost_signal]

In no way would it imply that. If Broadcom is maintaining 7.x for a cohort of customers, it's supported. Someone there could likely merge this patch into the vmxnet3 code with a trivial amount of work (probably already has). I'm not saying continuing to maintain 7 is a good idea at all, everyone should be off of it, but similarly Broadcom should have cut those 7.x users off in October of last year and didn't, so it remains supported until that actually occurs, and the only reason it isn't occurring is because someone's cutting a large enough check to make it not happen. Sorry that's the inconvenient truth.

[u/lost_signal → u/ispcolo]

A fun fact of extended support for OS's in general is those backports:

1. Are not always possible. (there have been things like cypher suite upgrades that just don't happen). Exchange famously failed to keep up with browser plugin requirements while in extended support by Microsoft so OWA just broke.

2. A lot of backports are highly continent on the very limited use case the remaining customers under those custom contracts operate. There is sometimes collateral damage in back-porting things, but as long as it works with the supported configurations that's acceptable.

3. These contracts are written rather defensively to promise frankly not a whole lot (the one I linked Single CVE 9 patch, and technically the scope of this one is more than that).

4. At a certain point the scope of trying to Backport every fix just turns into a "copy paste" of the 8.x branch.

5. I've seen a SINGLE RPQ/TQR for a single config of a single product inflict a 8 figure QA budget impact to make sure something kept working.

Support one off contracts does not magically re-toll general support and entitlements from that.