VMware and the revoked eMudhra certificates: this is not a hypervisor hole
Broadcom warned that emSign intermediates sit in the trust lists of VCF, Cloud Director, Workstation, Fusion, and neighboring products. Fixes are promised in upcoming releases. Do not confuse this with CVE-2026-41709.
Broadcom article 460199 says a simple thing: eight revoked eMudhra emSign intermediates were in the trusted lists of several products. Among them are VMware Cloud Foundation and vSphere Foundation 5.2.4 and 9.1.1, Cloud Director, Remote Console, HCX, PowerCLI, Telco Cloud, Workstation, and Fusion. Until the list inside the product is updated, the program can trust a certificate that the browser on the next laptop already rejects.
What that leads to
This is about impersonating a host on the network path, if someone can present a certificate signed by the weak key. It is not "a guest from the internet runs code on ESX." Workstation on a developer laptop and Cloud Director, which a company uses to hand out labs, are affected for one reason: they ship their own roots. Broadcom promises fixes in upcoming releases, not retroactively in the build you already have. A separate note, 460066, covers Tanzu stemcells, stacks, and buildpacks: those are updated from the portal too, and they do not pick up the system ca-certificates on their own.
It is worth updating things that are not named VMware but carry the same list: base images, Go, GitLab Runner. And do not file CVE-2026-41709 under the same task. The ESX log and certificate trust are fixed by different patches.
Related Lexora services
Labs on VMware, and it is unclear which patch to wait for
We can split it by product: where to wait for a Broadcom release, and where updating an image or Runner is enough.