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

📋 TL;DR — last updated November 5, 2026, 11:10 UTC

bridge-stp-uaf (CVE-2026-72389, CVSS 7.0, Moderate per Red Hat) is a vulnerability in the Linux kernel’s bridge Spanning Tree Protocol timers. A local unprivileged user who can configure a network bridge can turn it into root on the host. The researchers published helper code rather than a working exploit, and none has appeared publicly since.

• Affected: → Affected CloudLinux versions
• — CloudLinux 7h, CloudLinux 8 and CloudLinux 8 LTS, where an ordinary hosting account reaches the flaw as shipped.
• — The vulnerable code is in every CloudLinux kernel, but CloudLinux 7, 9, 9 LTS, 10 and CloudLinux for Ubuntu 22.04 are not exposed to ordinary accounts by default.
• Mitigation: one modprobe rule that stops the bridge module from loading. No reboot on hosts that do not bridge. → Is there a mitigation?
• Fix status → Update instructions
• — CloudLinux 7h and 8 kernel: patched kernels 4.18.0-553.157.1.lve.2 are in the stable channel as of October 6, 2026. → Stream 1
• — AlmaLinux kernel (CloudLinux 9, 10): no fixed kernel yet. Red Hat lists its kernels as affected with no fix published, and AlmaLinux follows Red Hat. Both versions are not exposed by default. → Stream 2
• — CloudLinux 8 LTS and 9 LTS kernel (TuxCare ELS): patched kernels kernel-lts-5.14.0-284.1101.tuxcare.11.els14 are in the stable channel as of October 21, 2026. → Stream 3
• — KernelCare livepatch: available for CloudLinux 7h, 8, 9, 9 LTS, 10 and CloudLinux for Ubuntu 22.04. → Stream 4
• Verify: uname -r against the target version in your stream; kcarectl --patch-info | grep CVE-2026-72389 once a livepatch ships. → How to verify you are patched
• Why it matters: on a shared host the local user is whoever compromised one of your sites, and root on the kernel is root over every tenant. → Why this matters on a shared host
• How the bug works: a topology-change timer can be armed on a bridge that is already down, and deleting the bridge frees it with the timer still queued. → Technical details of the bug

This advisory is also tracked on the CloudLinux status page; subscribe there for status updates.

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

💡 Another kernel reboot cycle?

bridge-stp-uaf is the latest in a run of Linux kernel privilege-escalation issues that have each called for a patch and a reboot on affected hosts. If emergency-patching and rebooting servers on this cadence is not sustainable for you, KernelCare is the alternative we recommend. It patches the running kernel in place. No reboot, no customer downtime. Livepatches for this issue are on the main feed for CloudLinux 7h, 8, 9, 9 LTS, 10 and CloudLinux for Ubuntu 22.04, and any further versions will be listed in Stream 4 as they land.

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

Update: October 7, 2026.

The patched CloudLinux 7h and CloudLinux 8 kernels are in the stable channel. The staged rollout completed on October 6, 2026, so the standard update path now installs them on every server: run yum update 'kernel*' and 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.

Update: September 24, 2026.

The patched CloudLinux 7h and CloudLinux 8 kernels have moved out of beta. A staged rollout to the stable channel began on September 23, 2026, so servers on the stable channel pick the update up progressively rather than all at once. Target versions are unchanged: kernel-4.18.0-553.157.1.lve.2.el8 and kernel-4.18.0-553.157.1.lve.2.el7h.

To install now rather than wait for the rollout to reach your server, use the beta-channel commands below and reboot. Once the rollout completes, the standard yum update 'kernel*' followed by a reboot is enough.

Status: September 10, 2026.

Patched CloudLinux 7h and CloudLinux 8 kernels carrying the fix are in the beta channel:

• CloudLinux 8: kernel-4.18.0-553.157.1.lve.2.el8
• CloudLinux 7h: kernel-4.18.0-553.157.1.lve.2.el7h

Promotion moves the same build to the stable channel on the normal schedule. This section will be updated when it happens.

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)

Status: September 10, 2026.

CloudLinux 9 and CloudLinux 10 run AlmaLinux kernels, and AlmaLinux follows Red Hat for this fix. Red Hat currently lists its RHEL 9 and RHEL 10 kernels as affected, with no fix published and no date. Both versions are not exposed to ordinary accounts by default, so this wait is routine. This section will be updated when a fixed kernel appears or Red Hat’s assessment changes.

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)

Update: October 29, 2026.

The patched CloudLinux 8 LTS and CloudLinux 9 LTS kernels have been in the stable channel since October 21, 2026, so the standard ELS update path now installs them: run yum update kernel-lts kmod-lve-lts and reboot. After the reboot, uname -r should report 5.14.0-284.1101.el8.tuxcare.11.els14 on CloudLinux 8 LTS or 5.14.0-284.1101.el9.tuxcare.11.els14 on CloudLinux 9 LTS. CloudLinux 8 LTS has no livepatch for this issue, so this kernel update is its fix.

Update: October 1, 2026.

Patched CloudLinux 8 LTS and CloudLinux 9 LTS kernels carrying the fix are in the beta channel: kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els14 on CloudLinux 8 LTS and kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els14 on CloudLinux 9 LTS. Promotion to the stable channel follows on the normal schedule, and this section will be updated when it lands.

Status: September 10, 2026.

CloudLinux 8 LTS and CloudLinux 9 LTS run 5.14 kernels delivered through TuxCare Endless Lifecycle Support. Patched LTS kernels are in preparation, with no date yet. Target versions will be added here on release.

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. The kernel-lts package arrives through the standard ELS update path.

Stream 4: KernelCare livepatch

Update: November 5, 2026.

The KernelCare livepatch for CloudLinux for Ubuntu 22.04 has been on the main feed since November 4. Subscribed servers take it on their next update cycle, or you can apply it now with no reboot:

kcarectl --update

Update: October 14, 2026.

The KernelCare livepatch for CloudLinux 9 LTS is on the main feed. Subscribed servers take it on their next update cycle. Coverage for CloudLinux 7 is still to be confirmed.

Update: September 23, 2026.

KernelCare livepatches for CloudLinux 7h and CloudLinux 8 are on the main feed. The CloudLinux 7h patch covers the kernel 4.18.0-553.157.1.lve.2.el7h. Subscribed servers take them on their next update cycle.

Update: September 22, 2026.

KernelCare livepatches for CloudLinux 7h and CloudLinux 8 have reached the testing feed. The CloudLinux 7h patch covers the kernel 4.18.0-553.157.1.lve.2.el7h. Servers on the default feed do not have these patches yet. To take one from the testing feed:

kcarectl --update --prefix test

Once the patches reach the main feed, subscribed servers take them on their next update cycle. This advisory will be updated then.

Update: September 17, 2026.

The KernelCare livepatch for CloudLinux 10 is on the main feed and covers the CloudLinux 10 kernel 6.12.0-211.53.1.el10_2. Subscribed servers take it on their next update cycle. Livepatches for CloudLinux 7h and CloudLinux 8 are still in preparation.

Update: September 14, 2026.

The KernelCare livepatch for CloudLinux 9 is on the main feed and covers the CloudLinux 9 kernel 5.14.0-687.46.1.el9_8. Subscribed servers take it on their next update cycle. Livepatches for CloudLinux 7h, CloudLinux 8 and CloudLinux 10 are still in preparation.

Status: September 10, 2026.

KernelCare livepatches for this issue are in preparation for CloudLinux 7h, CloudLinux 8, CloudLinux 9 and CloudLinux 10. Patches have not reached the testing or main feed yet. Coverage for CloudLinux 7 and CloudLinux 9 LTS will be confirmed here. KernelCare does not cover the CloudLinux 8 LTS kernel line, which takes the fix as a kernel update (Stream 3). CloudLinux for Ubuntu 22.04 takes its kernel fix from Canonical, and KernelCare for Ubuntu delivers that fix as a livepatch once Canonical publishes it.

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