Operations

VMSA-2026-0008: SDDC Manager has a critical flaw and no patch yet

CVE-2026-111497 sits in the Node.js runtime inside SDDC Manager. It is rated 9.8 on 9.1.1, CISA lists it as exploited, and every version is still waiting on a patch. What the workaround does and what to do this week.

Broadcom published VMSA-2026-0008 on 27 October and updated it the next day. It covers one flaw, CVE-2026-111497, and one component, SDDC Manager. As of 7 November there is still no fixed build for any version. Every row in the advisory's response matrix says "Patch pending". What exists is a workaround, and it is manual.

The same day Broadcom published, CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities catalogue. That is the line that should move this up your list. It means someone has evidence of the flaw being used, not just a proof of concept.

What the flaw actually is

SDDC Manager's UI runs on a bundled Node.js runtime, and that runtime includes Google's Brotli decoder. CVE-2026-111497 is an out-of-bounds write in the decoder. A request that arrives with a Brotli-compressed body, Content-Encoding: br, can be crafted to write outside the buffer it was given. That is the path to remote code execution, which is why the 9.1.1 rating is what it is.

Broadcom's portfolio article, KB 460791, checks the rest of the stack: vCenter, NSX, VCF Operations, HCX, Cloud Director, PowerCLI and the desktop products all appear in it. Its conclusion is that SDDC Manager on 9.1.1 is the only place the flaw is rated critical.

How bad it is depends on your version

SDDC Manager	CVSSv3	Severity	Fixed version	Workaround
9.1.1 (including EP)	9.8	Critical	Patch pending	KB 460732
9.0.x and 9.1.0	7.5	Important	Patch pending	KB 460734
5.2.x	7.5	Important	Patch pending	KB 460734

The uncomfortable part is the top row. Plenty of teams moved to 9.1.1 because it was the current release, and they now have the highest score of anyone. If you are midway through the staged path from 9.0 or 5.2, it does not change the plan, but it does mean the workaround has to be applied on whichever SDDC Manager you are running today, not the one you are heading to.

What the workaround does

For 9.1.1 the workaround tells nginx in front of the SDDC Manager UI to refuse any request body that declares Brotli encoding. Brotli is the only encoding the CVE affects, so legitimate traffic carries on. The KB offers it two ways: a script with check, apply and rollback commands, or the same change by hand.

Before either, the KB asks for three things, and they are worth taking seriously:

A backup or snapshot of the SDDC Manager appliance first.
No SDDC Manager task in flight. No upgrade, no workload domain operation, no certificate replacement.
Root on the appliance, so this goes through whoever owns SSH access to it, and probably through a change record.

Run check before apply. It changes nothing and tells you whether the UI is healthy and whether the workaround is already in place. If you apply the change by hand, roll it back by hand: the script will refuse to undo a manual change.

Broadcom is explicit that this is temporary and only covers this one CVE. When the patched build arrives, the patch is the fix and the nginx rule comes out.

What I would do this week

Find out which SDDC Manager version each instance is on. If you run more than one VCF instance, they may not match.
Check who can reach the SDDC Manager UI on 443. In most estates it sits on a management network, and that is your main mitigation until the workaround is in. If it is reachable from a general user network, that is the first thing to fix.
Take the backup, confirm it actually wrote something, then apply the workaround from the right KB for your version.
Write down that the workaround is in place and where. When the patch ships, someone has to remember to remove it, and that person may not be you.
Subscribe to VMSA-2026-0008 on the Broadcom support portal so you see the update when the fixed builds are published.

Step three is not padding. NSX has its own open issue at the moment, KB 459284, where a backup reports success and writes empty files when the SFTP target is full. Different product, same lesson: the green tick is not the evidence. If you want a structured way to check what you could actually restore, the Restore Evidence Check walks through it.