TL;DR - A new vulnerability in the Linux bridge spanning-tree protocol landed on r/netsec this week and it is the kind of CVE that never makes the news cycle but sits right in the network path of every VM and container on a Linux host. If your KVM boxes, Proxmox nodes or Docker daemons run a Linux bridge, they are in scope, and the fix is a kernel update plus a reboot plus a five-second check that the patch actually landed. What you need to do: identify every host that runs a Linux bridge (almost certainly all of them), confirm the running kernel is from a build that includes the bridge STP fix, schedule the reboot, and verify the post-patch state on the box before you call it done.
Disclosures like this one hit my reader as an r/netsec thread, not a headline. A few hundred upvotes, a long technical comment section, and a CVE number that will not survive the news cycle. But the host in front of me while I read it was the usual shape: a KVM box with a dozen VMs on br0, a separate Docker bridge for the host's own services, and a third bridge that nobody could quite remember the purpose of. Three bridges, all using the same kernel code path, all in the blast radius.
That is the shape of a Linux kernel CVE for me. It does not matter whether the host is a small Proxmox box at a suburban MSP or a hyperscale fleet at a Fortune 500; the bridge is one of the bits of plumbing we all share and almost none of us read the code for. The disclosure that just landed is the reason to read the code once and then move on.
By The Numbers
| Number | What it means |
|---|---|
| 9 Aug 2026 | Date the disclosure hit r/netsec as the top-of-week post in that subreddit |
| 1 | The Linux bridge subsystem (net/bridge/) affected, regardless of distro packaging |
| 3 | The bridge-using stacks in the blast radius on a typical ANZ SMB host: KVM/QEMU VMs, Proxmox VMs and LXC, and Docker (default docker0 plus any user-defined bridge networks) |
| 2 | Things you need to update: the kernel package, and any container runtime that vendors its own bridge handling. Kernel-only is not enough if the runtime ships its own bridge code path |
| 0 | Publicly confirmed in-the-wild exploitation at the time of the disclosure |
| Seconds, not minutes | The order of magnitude the verification takes on a single host once you know the right files to look at |
What a Linux bridge actually is
A Linux bridge is a Layer 2 virtual switch that the kernel implements in software. It joins two or more interfaces (physical NICs, virtual NICs, bonds, VLAN sub-interfaces, veth pairs) into a single broadcast domain and forwards Ethernet frames between them based on a forwarding database. The same code path runs whether you are connecting two physical NICs, wiring twelve VMs onto a host, or attaching a Docker container's veth pair. The spanning-tree protocol (STP, IEEE 802.1D, and its faster cousin RSTP) sits on top of that forwarding path: the bridge sends Bridge Protocol Data Units out of every port, listens for BPDUs from other bridges, and prunes redundant paths so a loop cannot take the network down. The implementation lives in net/bridge/br_stp.c and the forwarding-path files around it, which is why a malformed BPDU is the kind of input that reaches parts of the kernel the network is not normally allowed to touch.
Why the disclosure is the kind that does not make the news
The CVE I am writing about is not a marketing CVE. It does not have a logo, a ransomware crew claiming it, or a flashy remote-code-execution demo. The disclosure landed on r/netsec, got a few hundred upvotes and a long technical thread, and will not turn up on the front page of any mainstream outlet. That is the point of writing about it: the CVE that does not get press is the one that quietly gets skipped in the next patch cycle. The shape of the disclosure, as best the public write-up describes it, is a bug in the bridge STP handling that can be reached by a peer bridge or by an attacker on the same Layer 2 segment sending crafted BPDUs. The impact ranges from a denial of service (a kernel panic, a hung bridge, a forwarding-database corruption) to a memory-corruption class that could be a precursor to a more serious exploit. The patch is in mainline and the stable trees, and the distribution kernels will carry it within days.
What the blast radius looks like
Almost every Linux host with a workload has a bridge. KVM connects VMs to virbr0 (NAT) or a custom bridge. Proxmox connects VMs and LXC to vmbr0 plus a storage and a couple of internal bridges. Docker creates docker0 by default and a user-defined bridge for every docker network create; Podman the same, Kubernetes via the CNI plugin. (Open vSwitch hosts are the notable exception: OVS has its own userspace STP, so OVS-bridged ports do not go through the in-kernel net/bridge/ path - see the FAQ.)
The question is which bridges forward BPDUs from places you do not control. A bridge between two trusted VM networks inside a host is not exposed, but a bridge that connects a VM to a physical network (a colo, a shared switch fabric, a multi-tenant cloud) is exposed. A host with a default virbr0 and one VM is exposed to the host's own local network, which is more than enough reach for a peer to send a crafted BPDU.
The hardest case is the bridge that someone forgot about. Every Linux host I have audited in the last three years has had at least one bridge that nobody on the current team can name the purpose of. The "third bridge" nobody can name is not unusual; it is the rule. Those forgotten bridges are the highest-risk hosts in your fleet, because they are also the ones nobody is monitoring, nobody is logging, and nobody is patching.
The fix in three steps
The fix is ordinary. The discipline is what tends to slip.
- Identify every bridge on every host. A
bridge linkorbrctl showon each host gives you the list. Cross-reference against the host's expected configuration. Anything not in the list is a candidate for "do we still need this?" and a candidate for immediate patching if the answer is "yes." - Patch the kernel. The fix is in mainline and in the stable trees the major distributions backport from. On Debian and Ubuntu, a normal
apt upgradepulls the new kernel. On RHEL, AlmaLinux, Rocky, and Oracle Linux, the vendor update channel carries it. On Proxmox, thepve-managerpackage pulls the new kernel along with its own updates. The kernel is not the only thing in the patch; the bridge utilities, the iproute2 package, and the network scripts may also need updating, depending on the distro. - Reboot and verify. The new kernel does not take effect until the host reboots. On KVM and Proxmox hosts, the reboot is the part that has to be scheduled, not skipped, because every VM on the bridge depends on the host kernel for bridge forwarding. Once the host is back up, a
bridge linkand abridge vlan showwill confirm the bridge is back, and acat /proc/versionconfirms the running kernel is the patched one. Thedmesgoutput should show no warnings about the bridge subsystem on the way up.
Three short checks after the patch, in order:
- Kernel version.
uname -rshould match the patched build for your distro. On a5.15 LTSor6.1 LTSkernel, the patch is usually backported into a build that does not change the major version number, so the version comparison is against the distro's advisory feed, not against a number you remember. - Bridge STP state.
bridge linkshows the STP state on each bridge port. After the patch, the state should beforwardingordisabled(the expected state, depending on configuration) and notblockingdue to a state-machine corruption from the old code path. - Forwarding database.
bridge fdb showshould show the expected MAC addresses. A corrupted forwarding database is one of the visible signs of the bug class, and a clean FDB after the patch is a useful sanity check that the bridge came back to a known state.
Where this lands in your patching rhythm
For most ANZ SMB sysadmins the patching rhythm is some flavour of monthly. The bridge STP vulnerability is the kind of bug that wants to be in the next change window, not the one after, because a bridge sits in the network path of every VM and container on the host. The hardest version of this problem is the "we do not reboot our KVM hosts" shop, where the change window is months away. There are good operational reasons for that posture, and there is also a good reason to break it once a quarter to pick up the kernel CVEs that have landed. This is one of those reasons. A one-hour reboot is cheaper than a box that is compromised through a bridge bug that was fixed in August. The way to know whether your six-month-old LTS kernel already carries the fix is the distro advisory feed, not the calendar.
The honest reassurance
The bridge STP disclosure is not a panic. There is no public proof of exploitation in the wild, no ransomware crew has claimed it, and the bug is the kind that is most useful to an attacker who is already on your Layer 2 segment, which is a smaller attacker pool than the one that reaches your public-facing services. The reason to write it up is the same reason to write up the TONTOU CPU side-channel from earlier in the month and the TrueConf backdoored installer disclosure: the small CVEs are the ones that slip through the patching gap, and the patching gap is the place most small fleets actually lose. The fix is a kernel update and a reboot. The verification is a bridge link and a uname -r. The audit is a sweep of every host in the fleet for every bridge you can name, and an honest decision about every bridge you cannot.
If you look after a Linux fleet with KVM, Proxmox or Docker on it, this is the week to confirm your bridge hosts are patched. The same instinct that says "audit the bridge subsystem" applies at home too, where a phishing email is just an attacker asking your brain to forward a crafted frame. Same idea, smaller blast radius.
Get my Personal Security Quick-Start Guide - the practical handbook for the controls that actually change your day. 193 pages, no jargon.
FAQ
Does this affect Docker, even if I never touched brctl?
Yes. Docker creates the docker0 bridge by default on install and creates a new user-defined bridge for every docker network create you run. If you have ever run a container, you have a bridge. The fix lands in the kernel, which Docker (and the container runtime in general) uses; updating the kernel is the path. There is no separate Docker-side patch you have to apply beyond the kernel update and a container runtime restart.
What about Open vSwitch? I run OVS on my Proxmox hosts.
OVS has its own userspace implementation of STP, and OVS-bridged ports do not go through the in-kernel net/bridge/ code path. If you are running OVS end-to-end, this CVE is unlikely to apply. If you are running a mix (OVS for some bridges, kernel bridge for others), the kernel bridge portions are still in scope. Run ovs-vsctl list-br and bridge link on the host and confirm which bridges are which. The Linux kernel bridge and the OVS bridge are not interchangeable; the audit has to look at both.
How urgent is this? I cannot reboot my KVM hosts until the next change window.
The urgency is moderate, not critical. There is no public proof of exploitation in the wild, and the attacker pool is limited to peers on the same Layer 2 segment. The fix is in the next change window, not necessarily tonight. If your next change window is more than a month out, the calculus changes; consider an out-of-cycle reboot for the bridge hosts specifically, because a one-hour reboot is cheaper than a box that is compromised through a bridge bug that was fixed in August. If your next change window is within a week or two, the patch can ride in the normal flow.
Further reading
- New Linux bridge STP vulnerability (r/netsec) - the disclosure this post is built around
- Linux kernel bridge documentation (kernel.org) - the canonical reference for
bridge link,bridge fdb, and the in-kernel STP implementation - iproute2 bridge command reference - the
bridgecommand that drives the audit on a modern distro - Linux Foundation: netdev wiki - bridge subsystem - the upstream maintainers' own reference for how the bridge is built and where the STP code lives
- ACSC: Essential Eight maturity model - patching cadence - the Australian framework this audit maps into
- SecureInSeconds: TONTOU sidesteps Spectre v2 fixes: patch your Linux kernels - the related CPU-side-channel disclosure from the same week, with the same "kernel plus microcode" patch shape
- SecureInSeconds: TrueConf shipped backdoored installers: how to check your fleet - the related vendor-side disclosure from the same week, with the same fleet-audit shape
- SecureInSeconds: Three claimed CISA KEV additions - the IT-pro verification and triage checklist - the triage discipline that applies to bridge kernel CVEs too
Forward this to whoever runs the bridge on your KVM and Proxmox hosts. The audit is a one-line command per host, the patch is in the next kernel, and the verification is a bridge link after the reboot.
Mathew Clark / Founder, SecureInSeconds / Currently: deleting a bridge nobody on the team could name, and feeling good about it.
