bridge-stp-uaf (CVE-2026-72389) local root vulnerability: kernel update and mitigation for CloudLinux

Every Linux kernel in use today carries the bug behind bridge-stp-uaf (CVE-2026-72389), a flaw in the network bridge code that lets a local unprivileged user gain root on the host. It was disclosed on August 5, 2026 by the researchers n132 and sven sze through SSD Secure Disclosure.

The flaw is old. The vulnerable code has been in the kernel since at least Linux 2.6.12 in 2005, which is as far back as the kernel’s version history reaches. What differs between systems is whether an attacker can reach it. On CloudLinux that splits by version: an ordinary hosting account reaches it as shipped on CloudLinux 7h, CloudLinux 8 and CloudLinux 8 LTS, while the other versions close that path by default.

There is no fixed kernel from Red Hat. It rates the flaw Moderate, lists RHEL 7 through 10 as affected, and had published no fix at the time of writing. So the CloudLinux 7h and 8 kernels below are our own backport of the upstream fix.

The disclosure contains helper code for talking to the bridge subsystem, not a working exploit, and reports that a public proof-of-concept was released are inaccurate. That does not make the bug theoretical. The route from this class of flaw to root is well understood, and the update is due now on the exposed versions.

Here “local” does not mean an insider or a customer you trust. On a shared server the local user is whoever just got into one of the sites you host through an outdated plugin. Because the corruption lands in the kernel every tenant shares, success means every account on the machine: their files, their databases, their sessions.

Affected CloudLinux versions

The vulnerable code is present in every kernel CloudLinux ships. What differs is whether an ordinary hosting account can reach it in the shipped configuration. “Not exposed by default” means exactly that: the path an ordinary account would take is closed by a hardening default CloudLinux ships. However, a container that has been granted elevated network rights is not covered by it.

^† CloudLinux for Ubuntu 22.04 runs the stock Ubuntu kernel with the CloudLinux stack on top. The default that keeps this version from being exposed is CloudLinux’s, while the kernel fix arrives from Canonical through apt. Canonical released the fixed 22.04 kernel 5.15.0-198.208 on October 6, 2026 (USN-8875-1): run apt update && apt upgrade and reboot. The optional 6.8 HWE kernel is not fixed yet.

What to do on the versions that are not exposed by default. No action is needed today on a stock CloudLinux 7, 9, 9 LTS, 10 or CloudLinux for Ubuntu 22.04 host. Two limits apply. If you run containers with elevated network rights on any version, remove those rights where the workload does not need them; where it does, treat that host as exposed until it has the kernel update or the livepatch. And the vulnerable code is still in the kernel, so apply the update when it reaches your version.

Is there a mitigation?

Yes. On CloudLinux 7h, CloudLinux 8 and CloudLinux 8 LTS, apply it now on any server you cannot update and reboot right away. It closes the entry point the flaw depends on: creating a bridge makes the kernel load the bridge module on demand, and blocking that load stops the sequence before it starts.

echo 'install bridge /bin/false' > /etc/modprobe.d/bridge-stp-uaf.conf

It needs no reboot on a host where the module is not already loaded. Check with lsmod | grep '^bridge '. If that prints nothing, the rule is in force as soon as the file exists.

It does not help on a host that already bridges. Docker holds the module in the kernel through its default docker0 bridge, and libvirt and LXC do the same for their own networks. The rule cannot unload a module that is already present, so those hosts need the kernel update or the livepatch instead. If lsmod prints a bridge line, plan the update.

It must be the install bridge /bin/false form. A plain blacklist bridge line stops user-space tools from loading the module by name but does not stop the kernel loading it on demand, which is exactly what this flaw relies on. A blacklist alone does not close it.

Compatibility. Do not apply this on hosts that need bridging: virtualization hosts, Docker or LXC hosts, and anything with a bridged VM or container network.

On the versions that are not exposed by default, the shipped configuration already closes the path for ordinary accounts. The same rule is reasonable hardening there on hosts that do not bridge.

Revert once the server runs a fixed kernel or the livepatch:

rm /etc/modprobe.d/bridge-stp-uaf.conf

Update instructions

The mitigation above closes the entry point. The fixes below remove the vulnerability itself. Deploy whichever applies to your version as it becomes available.

Stream 1: CloudLinux 7h and CloudLinux 8 kernel

The kernels carry CloudLinux’s own backport of the upstream fix on our kernel line. Install them through the standard update path:

yum update 'kernel*'
reboot

After the reboot, uname -r should report 4.18.0-553.157.1.lve.2.el8 on CloudLinux 8 or 4.18.0-553.157.1.lve.2.el7h on CloudLinux 7h. Once a server runs one of these kernels, the module rule is no longer needed on it.

Stream 2: AlmaLinux kernel (CloudLinux 9 and CloudLinux 10)

No action is required on a stock CloudLinux 9 or 10 host today, but hosts running containers with elevated network rights should follow the note under the table. The KernelCare livepatch is on the main feed for CloudLinux 9 and CloudLinux 10 (Stream 4); neither depends on the vendor kernel. When a fixed AlmaLinux kernel ships, the standard update path applies:

dnf update 'kernel*'
reboot

Stream 3: CloudLinux 8 LTS and CloudLinux 9 LTS (TuxCare ELS)

CloudLinux 8 LTS is reachable as shipped and KernelCare does not cover its kernel line, so the module rule is the interim step there and a reboot into the fixed kernel is the fix. CloudLinux 9 LTS is not exposed by default and needs no action on a stock host. Once released, the kernel-lts package arrives through the standard ELS update path.

Stream 4: KernelCare livepatch

kcarectl --update --prefix test

The livepatch closes the vulnerability on a running kernel with no reboot. Subscribed servers take it on their next update cycle once it is on the main feed, or on demand:

kcarectl --update

Each family’s release will be added here as it lands.

How to verify you are patched

For a kernel update, compare uname -r against the target version in the Status callout of your stream above.

For the KernelCare livepatch:

kcarectl --patch-info | grep CVE-2026-72389

A patched server prints a line naming the CVE. Use --patch-info for this check: kcarectl --info prints the patch-level summary and returns nothing for a specific CVE even on a fully patched server, which is the usual reason a patched host gets reported as unpatched.

For the mitigation, confirm the rule file exists and the module is not loaded:

cat /etc/modprobe.d/bridge-stp-uaf.conf
lsmod | grep '^bridge '      # expected: no output

The rest of this advisory is background for readers: how the attack plays out on a shared host, and the technical detail of the underlying bug. Neither is required to apply the fix above.

Why this matters on a shared host

On a multi-tenant CloudLinux host (a shared cPanel or Plesk box, a VPS that gives customers shell access, a CI runner that executes customer code), the chain is short.

1. A site on the server is compromised. An outdated plugin, theme or CMS gives an attacker code execution as an unprivileged web process, confined to one account. That one account is all the access the attacker needs.
2. From that process, they set up a private network space of their own. Inside it they hold network-administration rights, which is all the next step needs; nothing on the host itself has to be misconfigured, and the host does not need to be doing any bridging. On CloudLinux 7h, 8 and 8 LTS an ordinary account can take this step as shipped. On the other versions the shipped configuration closes it for ordinary accounts, which is what the table’s “not exposed by default” rows record.
3. They create a bridge, switch on kernel STP (the Spanning Tree Protocol) on it, and delete the bridge while a timer is armed. Three operations, all of them ordinary network configuration inside their own space.
4. The kernel now has a timer queued against memory it has already freed. An attacker who controls what gets allocated into that memory controls what the kernel does when the timer fires. That is the standard route from a use-after-free to arbitrary kernel execution, and from there to root.
5. Root on the shared kernel is root over every tenant. Every per-account boundary the kernel enforces is now enforced by code the attacker controls.

With the bridge module blocked, step 3 fails at its first operation. With the fixed kernel, step 4 never happens: the timers are stopped before the bridge is freed. Either way, a compromised website stays a compromised website, one account to clean up instead of a server to rebuild.

Technical details of the bug

A Linux network bridge keeps three periodic Spanning Tree Protocol timers inside the bridge device’s own private data: a hello timer, a topology-change timer and a topology-change-notification timer. The code assumes that none of them is armed while the bridge is administratively down. Every call site that arms one checks the interface’s up flag first, and taking the bridge down stops all three.

Two gaps broke that assumption. The topology-change detection function never checked whether the bridge was up; it only bailed out when kernel STP was disabled. So with kernel STP enabled, a topology change could arm the timer on a bridge that had already been brought down. And the teardown path used when a bridge is deleted did not stop the timers at all, because deleting a bridge does not go through the same code as taking it down. The result was a freed bridge with a live timer still queued against it.

The upstream fix does both halves: it adds the missing up-flag check to the topology-change detection, and it shuts all three timers down before the bridge is freed. The bug has been present since the kernel’s version history begins.

References

• SSD Secure Disclosure, “Linux Bridge STP Timer Use-After-Free”, n132 and sven sze, August 5, 2026
• Upstream fix 2a00517db8de, “bridge: stp: Fix a potential use-after-free when deleting a bridge”, Ido Schimmel
• CVE-2026-72389 record, Linux CNA, published August 15, 2026
• Red Hat CVE page (CVSS 7.0, Moderate)
• NVD entry (scored 7.8 High by the kernel CNA; both scores use a local attack vector)
• Ubuntu security tracker for CVE-2026-72389
• CloudLinux status page incident for this advisory