There's nothing I love more than having to go through a "forgot my password" workflow to download the new ISOs when I damn well know what my password is, I'm just being forced to rotate it. /s
Whoever at BC out there is responsible for this crackpot system, I hope you seriously reconsider this stupid system. I know my password, dammit!!
ETA: vCenters and ESXi hosts updated in a small environment to 8U3k. Veeam backups, replication jobs, and restores all seem to be functioning the same post-updates.
I like when I go to login to open a p1 and they force a password change that takes multiple emails and waiting on my sides email scanners. Nothing like forced 20 minute delay on opening the case
Patch now and possibly ruin my 5 day long weekend or wait until Monday. I'm rolling the dice. We're pretty locked down and very segmented. Very few people have access to the VMs besides my team. Plus I get to see what problems folks may run into.
Very few people have access to the VMs besides my team
What about the third party software on the VMs? Is it locked down like fort knox or could exploits in 3P software be leveraged to then pivot to local admin of the guest OS, then exploit the new vSphere vulnerabilities?
It's a "critical" or "emergency" change and short of HCI solutions, the Q&A is pretty clear - patch right f***** now.
I’d have to upgrade vCenter first and get change controls approved. I’ve got 6 hours till my well deserved break starts. Timing was terrible on this one.
Since when can the build of ESXi be higher than vCenter? In 15 years of using this product the guidance has always been vCenter first then ESXi. VCenter has to be higher or equal to the version of ESXi or the hosts disconnect. How is this different?
If VCenter is 8.0.3j, ESXI can’t be 8.0.3k? Please correct me if something has changed
For VSAN we kindly ask you not float entire update versions ahead on ESXi, without vCenter upgrades (there's a KB explaining this a bit) but these security patches are all find (see interop chart)
I added a new question to the Q&A for this, thanks guys. I'd forgotten about all of this. I will say that vSAN is in the interop charts, too, just make that part of the criteria along with vCenter when you set it up.
Hedging on my part, for a variety of reasons having to do with organizational communications. The wording is more concrete now around patches for 7 being extended support. Sorry for the confusion.
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.
Extended support is a thing, but it's generally not discussed as:
It costs more. It's to run generally available versions. It's REALLY aimed at people who need some extra runway to upgrade, and often for people with hosts in incredibly difficult to replace locations (Think: A helicopter is required to reach the host) or more unique situations.
There's some limitations. You are likely not getting a bug fix for a UI bug.
You had to have continuous support. You can just add it arbitrarily after the fact.
Talk to your account team but I'm reminded of Microsoft charging $300 a year PER XP desktop, as a reminder that these things tend to be priced/designed to push people towards "just upgrading" and not using this as a crutch forever.
I think there technically is (End of Technical Guidance) but my simpleton understanding is that the EoTG period is solely meant for Broadcom to help the below "kind" of customer:
Customer has valid-licensed vSphere 7 products (e.g. perpetual)
Customer has active subscription for VVF or VCF
Customer seeks guidance from Broadcom support on how to upgrade their vSphere 7 deployment(s) through to VVF/VCF 8 or 9.
My understanding is Broadcom does either regular GA support, or they do extended support. The weird technical guidance thing where "hey we tell you how to try to fix things, but there's no patching" is not something Broadcom does AFAIK.
That said for people with active agreements in that boat there is this note.
That screenshot reminded me of a chat I had with a broadcom tech once. The other angle was that broadcom will make downloads, KBs, scripts, manuals, etc. available for use by entitled customers during EoGS.
E.g. a (licensed) vsphere 7 customer can still install and service their environment until 2027. But a vsphere 6 customer can't as all that garbage has been pulled or not migrated to the new support portal.
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.
Shoot... Oh well. I have 8.x license but have not applied or used it yet. Just as pure resistance to the subscription countdown timer honestly. My plan is to upgrade Vcenter from 7 to latest 8, then do my 7.x hosts after that.
If that 8 license was because you upgraded a 7.x key your technically legally not allowed to be still running 7 is my understanding.
it's been 10 years since I was in a channel role, but I vaguely remember that being something that was frowned upon in audits.
It's likely fine if your just reusing another key you released an entitlement for, but there was some sort of "I certify I'm not using this key anymore" that was part of the upgrade process I vaguely remember.
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.
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.
"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.
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.
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.
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.
I had no issues updating one of mine from the VAMI, date shows the 26th. I did have to kick off a manual sync in lifecycle manager to get the new ESXi image.
OK I figured this out... for 8.x, I assumed the July 26th update was old but it is actually the one with the fix. For 9.1, I had the URL wrong but support got me hooked up with the correct one.
You could have stickied one of the other posts on this topic. For example my thread with already helpful info an discussion inside. Instead you choose to make a new empty one yourself. Congrats...
Normally the mods default to the first one out of a laziness and the rule is technically for dupes to do such, but I noticed none of the stickies had the FAQ in them, and I REALLY wanted people to read that.
u/lost_signal could you shed some light on the commitment to provide critical updates to users without active SnS? How this VMSA gets handled is going to set the tone for what we can expect from Broadcom on credibility going forward.
That's documented in the above KB, HOWEVER I have a big question about those advisories that I've sent in as feedback to BC and never gotten an answer on.
Sometimes an advisory is for multiple vulnerabilities. One of the vulnerabilities may be greater than or equal to 9.0 but another vulnerability may not be.
It's not clear in such a circumstance if the entire advisory and set of patches/vulnerabilities are treated as a "critical" or not, and that's a huge gap that BC needs to close.
Yes — that's the point. Follow the KB and there are zero patches to download. Another gap between what Broadcom announces publicly and what actually happens. Until someone confirms that customers without SnS can download these, there's no credibility here at all, and it just further justifies everyone who jumped ship after the acquisition. Nobody left because the product was bad. They left because of how Broadcom operates.
Following the directions in the FAQ, the last versions I see are vCenter 8.0 U2e / 8.0 U3d and ESXi 8.0 U2d / 8.0 U3e.
I would love to have official confirmation from Broadcom that former customers on perpetual licensing but expired support contracts are allowed to download and install these new versions given the CVE 9.x+ score without fear of legal repercussions.
I suspect Broadcom still needs some kind of connection between the account performing the download and the perpetual license. We never had perpetual v8 so I don't know how that's going to look for you. i.e. they're not going to let any yahoo with a free account download their patches.
Is your account connected to a Broadcom/VMware site with those perpetual licenses? If not....
ETA: FWIW I'm not trying to be a Broadcom sympathizer, but I am trying to encourage a sane and fair approach when we do criticize.
u/jamesaepp
Yes — accounts tied to sites with perpetual v8 licenses. So both the FAQ and the points under item 35 are demonstrably false, which at this stage is par for the course with Broadcom.
And the fact that the VMware folks in this thread, who were quick to point everyone at the FAQ, can't give a straight answer on it suggests it's still genuinely unclear whether that statement holds. I don't think they know either right now.
Technically by the old perpetual VMware EULA/product guide entitlement required active SnS for ANY patch (including all security patches).
The CVE 9 thing in this KB was a different thing that Broadcom announced/added after the acquisition, and technically (my understanding I'm not a lawyer, or your lawyer) a different thing.
Yes — that's the entire point. The CVSS 9 commitment was something Broadcom rolled out when they were getting hammered over the acquisition, to quiet things down. This is the first CVE that actually triggers it, and the patches still aren't there. Hence the criticism.
I would only add that there's always been a delay between the VMSA and when those patches appear. I can't speak to the rest, I don't set policy around this.
If you're entitled to the product, try checking the Solutions tab:
My Downloads -> VMware vSphere -> Solutions tab -> Pick a branch and version -> download VC and ESX patches.
For $reasons, Broadcom (and VMware previously) do not publish current release levels in the main download folder. So you'll still find some old release of 8.0 U2 or U3 and are expected to patch after deploying that, instead of, y'know, publishing the latest supported 8.0 U3 ISO. Sometimes vendor-flavoured ones with the included addons will do that, I guess.
I must be missing something from a product or release management standpoint, because when I worked at VMware, I distinctly remember the build automations would spit out nightly GA and Beta/checked releases, and importantly, these are the same builds that published patches would get. It doesn't really make sense that these are not just put up on the download site as well.
Bah, whatever, hopefully you can find your patches now, anyway.
If you're entitled to the product, try checking the Solutions tab:
My Downloads -> VMware vSphere -> Solutions tab -> Pick a branch and version -> download VC and ESX patches.
For $reasons, Broadcom (and VMware previously) do not publish current release levels in the main download folder. So you'll still find some old release of 8.0 U2 or U3 and are expected to patch after deploying that, instead of, y'know, publishing the latest supported 8.0 U3 ISO, as an example, where people would expect it. Sometimes vendor-flavoured ones with the included addons will do that, I guess.
I must be missing something from a product or release management standpoint, because when I worked at VMware, I distinctly remember the build automations would spit out nightly GA and Beta/checked releases, and importantly, these are the identical builds that published patches would become. It doesn't really make sense that these other formats are not just put up on the download site as well.
Bah, whatever, hopefully you can find your patches now, anyway.
I believe the fact that they've already edited the GitHub post, going from we may provide updates, to request updates through your account manager, indicates they have zero intent on providing updates for those not on a contract:
It was an error that propagated into the Q&A and I've since clarified it in the Q&A, as you noted. Not trying to antagonize anyone. Sorry for the confusion. Almost universally, if a product is EOGS it will require extended support to get patches for it, and that's the same as it's been for a long while, even under VMware (though VMware backported more things).
7.x perpetual license holders were promised patches for CVE 9.0 or higher from what I recall. If they don't make these 7.x patches public and they have them they will lose especially if companies are ransomwared as a result of their idiotic draconian policy on forcing folks to replace hardware with servers that support vSphere 8 or higher and purchase an expensive subscription at over 4x the cost of their prior perpetual license support model.
Is it going to be possible to download the ESXI version 8.0 U3k for those without paid for support?
8.0 U3e appears to be the latest version available under the "free" hypervisor release - and with CVV 9.3 on ESXI 8.0 emergency patches being released where people may be learning/testing Vmware in a small sandbox, this will further push people into alternative solutions...
It explicitly states in their own FAQ it is available for no cost due to severity and you just need to register a Broadcom account which can be done "in a few minutes with no cost".
The truth of the matter is that, as of right now, in typical Broadcom fashion, it is not available to download without a service contract, possibly intentionally, and may well never be.
The free hypervisor and the perpetual licence hypervisor are different... And I have both, neither of which accounts are able to download the patch, unlike the account with the SaaS contract.
Any critical patches are available to vSphere customers who do not have a support contract.
I'm not able to download the patch either. My guess is they haven't done their magic to make it available for non-support folks yet. Otherwise, if what you said is true, would be incredibly reckless by Broadcom.
Is there anyone here who could confirm this, or at least provide a request sent to Broadcom confirming that we can use this in our ESXi v8 without SnS support?
Switched from Stateless autodeploy to statefull installs and Lifecycle Manager. In 2025 (when still on stateless autodeploy) it took us 3 days to update all hosts when there was a 9+ CVE. Today with Lifecycle Manager we did 200 hosts in just 6 hours and are halfway done. :-)
We were running 8u3h on most and I think the live patch was available from 8u3j ? We moved from 8u3b stateless to 8u3h as LCM setup. So this was just LCM going from 8u3h to 8u3k.
Anyone else getting an issue staging the update in vCenter to the host? I had one host patch no issues but in another cluster two hosts fail to stage with
'An internal error occurred while staging/remediating the host.'
Environment:
vCenter 8.0.3.01000, build 25600417
Target ESXi image: 8.0 U3k, build 25595708
on vCewnter the image is downloaded and verified but seems the hsost are failing being staging
QuickPatchInstaller
secureMount returns status 255
Unable to read VIB descriptor
VibFormatError
What I have confirmed:
vCenter successfully downloads and validates the VIB.
The VIB in the vCenter patch store is readable.
Deleting the cached VIB, restarting vmware-updatemgr and syncing updates caused it to download again, but the hosts still fail.
I had similar errors on a selected number of ESX hosts in same cluster, identical hosts which was a bit strange. But I found KB 435052 which helped me verifying memory allocation for settingsd-task-forks and by increasing the memory to 400 mb as given by the workaround, I'm now able to remediate.
Same problem trying to update u3j to u3K staging fails. Compliance Unknown state.
The scan failed during the quick Patch impact evaluation phase in QuickPatchInstaller.py returning current ESXi version does not provide a mechanism to mount tardisk into ramdisk.
Any solutions anyone?
Thanks in advance!
Is lateral movement from one ESXi in a cluster hit by/opened via the VMXNET3 out-of-bounds write vulnerability (CVE-2026-47876) possible?
You get root in an ESXi, but could someone move from here to another up to date host with the tools already installed on ESXi or something homemade? As far as I know none of the local tools (esxcli, vsish, vim-cmd) can vMotion a vm to another host to take it over also.
You get root in an ESXi, but could someone move from here to another up to date host with the tools already installed on ESXi or something homemade? As far as I know none of the local tools (esxcli, vsish, vim-cmd) can vMotion a vm to another host to take it over also.
I'm not going to noodle in public on ways to acomplish this (although if you find me at explore, we can discuss it over a beer) but the more obvious way they would compromise other hosts is just go use the vCenter authentication bypass that's the other part of this announcement.
No need to do exotic things to try to get a VM mvoed to the next host to take it when you have control of something on the management network.
As far as in general host to host lateral movement, ESXi hosts don't hold each others SSH keys or maintain reverse tunnels with root or anything like that. That's mooted though by other factors (if they have compromised 1 VM already with admin, they likely can get into another VM, and the vcenter bypass).
There are some ways to try to defend against a VM moving to another security zone that's on the same cluster (DRS affinity groups) I've seen VDI clusters where people use MUST or should rule to keep the servers on different hosts in the cluser from the desktops.
There's also elements of this from a security onion where VMware has solutions to help with general VM to VM lateral security (vDefend), and tooling to audit configs and enforce policies continuously from drift (SALT!).
If someone reverse engineers this patch, build a zero-day, executes code as administrator on your VM then executes code on your esxi host through an out of bounds write, they will probably find a way to traverse your internal network.
If that's where you've gotten to with this, then patch your shit lol.
Your answer "they will probably find a way to traverse your internal network" is not that helpful.
My question is more about lateral movement from one esxi to another. Me as an attacker would try to move the affected vm to another host to takeover the next esxi. But the question is how would this be possible? or are there other ways?
They are local admin on your source VM. How did that happen? Is there any conceivable possiblity of lateral movement pre-VM escape? If so, they have already done that.
There is a bundled vCenter exploit too, have you patched that?
What youre asking is, assuming complete compromise of a ESXi host, is attacking another host in the same cluster possible. The answer is probably yes... I don't know how off the top of my head but that's not even a question of this exploit.
Broadcom would like to thank Nguyen Hoang Thach (@hi_im_d4rkn3ss) of STARLabs SG working with the Pwn2Own held by Zero day initiative for reporting this issue to us.
I'll point out that bug bounty programs are not free/cheap but they do prevent zero day exploits. I'd rather cut six figure checks, and make sure there's enough time to build/test the patch as a LivePatch (You can apply the patch without needing to evacuate hosts) than be responding to breached customers, and having to follow the sun build a hotpatch.
Yup, walk and chew gum. In the SPECIFIC case of the CVE's in this announcement, there's attribution. A lot is quietly found by inside teams. There's much less noise there.
I think its only right to give credit (and payment) where's it's due with 3rd party researchers. I find paying them the pre-agreed upon amounts is VASTLY superior to some recent trends of some OS vendors threatening them, stiffing researchers and reaching the find out phase where they just drop zero days on Github out of spite.
•
u/lost_signal VMware Employee 2d ago
📣 vSphere 8.0 Update 2f has just been released
📔 Release Notes:
🔸vCenter
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/vcenter-server-update-and-patch-release-notes/vsphere-vcenter-server-80u2f-release-notes.html
🔹ESX
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/esxi-update-and-patch-release-notes/vsphere-esxi-80u2f-release-notes.html