SURIQ
Broadcom's VMSA-2026-0005, published July 14, closes seven flaws in VMware Avi Load Balancer, and the shape of the pile matters more than any single score. Four of the seven put an attacker on or against the Avi Controller, the management brain that pushes config to every load-balancing engine you run. The worst of them, CVE-2026-47865 at CVSS 9.8, lets someone with network access bypass authentication and reach that control plane outright. No login, no phishing, no foothold first.
There is no in-the-wild exploitation reported yet, and Broadcom published no workaround for any of the seven. Read those two facts together and the plan writes itself: the fix is the patch, the clock is the gap between now and the first working exploit, and the only thing you control in the meantime is who can reach the controller at all.
The four flaws that reach the control plane
Group the seven by what an attacker actually needs, and the priority order is obvious.
The pre-authentication set is the emergency. CVE-2026-47865 (9.8) is the authentication bypass into the control plane. Sitting next to it is CVE-2026-47867 (8.7), a remote code execution flaw that Broadcom describes as reachable by a malicious user with network access, again with no stated authentication requirement. A bypass that gets you in and a code-execution bug that runs on the same plane are the combination you least want on an appliance that programs your traffic path.
The authenticated set still matters, because a bypass plus an authenticated bug is a chain. CVE-2026-47869 (8.7) lets an authenticated network user inject and run code. CVE-2026-47871 (8.8) is a directory traversal from bad file-path validation, and CVE-2026-47866 (8.3) is an authorization bypass that exposes a limited slice of the control plane. Two more round it out: CVE-2026-47870 (7.1), an authenticated path to remote code, and CVE-2026-47868 (7.8), a local privilege escalation to root. Broadcom credits Filip Waeytens of NATO NCSC with the first five and Lang Khuong Duy of Viettel IDC with the last two.
Which builds are affected
The batch spans four release trains, and one of them has no home to patch to.
| Release train | Affected versions | Fixed build |
|---|---|---|
| 32.1.x | 32.1.1 | 32.1.2 |
| 31.x | 31.1.1 - 31.2.2 | 31.2.2-2p3 |
| 30.x | 30.1.1 - 30.2.6 | 30.2.7 |
| 22.1.x | 22.1.1 - 22.1.7 | no direct fix, move to 30.2.7+ |
The fixed builds are 32.1.2, 31.2.2-2p3, and 30.2.7. The top authentication bypass is listed against the 31.x (31.1.1 through 31.2.2), 30.x (30.1.1 through 30.2.6), and 22.1.x (22.1.1 through 22.1.7) trains; the other flaws also reach 32.1.1. If you are on the 22.1.x line there is no in-place patch, so the fix is a jump to 30.2.7 or later. That is a version migration, not a maintenance update, and it is the reason 22.1.x sites need to start planning today rather than treating this as a same-evening reboot.
This is the appliance-management-plane pattern again
Step back from the CVE numbers and this looks familiar. The management plane of an edge or application-delivery appliance keeps turning out to be the softest, most valuable target on the network. Citrix NetScaler, F5 BIG-IP, and Ivanti's gateways have each been the subject of publicly reported pre-authentication vulnerabilities in this kind of console over the past two years, several of which reporting tied to mass-exploitation events within days of a patch, precisely because the fix itself tells attackers where to look. Another load balancer makes the timing case plainly: Kemp LoadMaster's pre-auth root flaw was reported exploited within hours of the writeup that described it.
The lesson those carried, and the one that applies here, is that a load balancer's controller is not a web server you can leave exposed and firewall later. It sits in the traffic path, it holds TLS material and backend topology, and code execution on it is a foothold with a view of everything behind it. Broadcom reports no exploitation yet. The right way to read "yet" on a 9.8 pre-auth bypass with a public patch is as a countdown, not an all-clear.
Reduce reachability while you stage the patch
With no vendor workaround, the interim control is network reachability, and it is one you already own. The Avi Controller's management interface should never be reachable from the internet or from general user VLANs. Confirm that the controller and its API are restricted to a management network, that access runs through a bastion or VPN, and that any allow-list in front of it is as tight as your operations actually need. Shrinking who can touch the control plane does not remove the vulnerability, but it removes most of the people who could use it before your patch lands.
How to tell if the controller was reached
Patching closes the door. It does not answer whether anyone walked through it first. For a control plane you cannot fully rule out was exposed, spend an hour on the record before you reboot into the fixed build.
Pull the controller's authentication and audit logs and look for the signatures of a bypass being used: successful control-plane or API sessions that do not line up with a real admin login, access from source addresses outside your management range, new or unexpected API tokens and user accounts, and configuration changes with no change-ticket behind them. Because two of the flaws end in code execution as root, also check for unexpected processes, cron or systemd additions, and outbound connections from the controller to addresses you do not recognize. Map what you find to MITRE ATT&CK for the write-up: initial access via a public-facing interface, then persistence through new accounts or scheduled tasks. If the controller was internet-facing before today, treat unexplained control-plane activity as an incident until you have ruled it out, not as noise.
The honest summary is short. Seven flaws, four of them touching the control plane, a 9.8 that needs no credentials, and no workaround to hide behind. Patch to a fixed build, tighten who can reach the controller, and read the logs before you assume the window stayed shut.