CVE-2026-72389, tracked internally as bridge-stp-uaf, is a use-after-free in the Linux kernel's bridge Spanning Tree Protocol timer code. CloudLinux disclosed it on 5 August 2026 and published the advisory on 15 August 2026. CVSS is 7.0 (Red Hat, Moderate) and 7.8 (NVD, High) — the disagreement is typical for local kernel bugs, where the practical severity depends entirely on who has bridge access on your box.
The impact statement from the advisory is blunt: "a local unprivileged user who can configure a network bridge can turn it into root on the host." On a stock shared-hosting server that's a narrow population — ordinary cPanel or Plesk accounts don't get CAP_NET_ADMIN. It stops being narrow the moment you run Docker, libvirt, or LXC on the box, since those workloads routinely create and tear down bridges as part of normal operation.
Root cause
Two gaps in the bridge teardown path combine into the bug:
- The topology-change detection function skipped an up-flag check, so it can arm a timer on a bridge that is administratively down.
- Bridge deletion bypasses the timer-shutdown code that normal bridge takedown uses.
A timer armed on a bridge that then gets deleted without going through timer shutdown fires against freed memory — a classic use-after-free with a well-established route from there to arbitrary kernel execution.
Which CloudLinux versions need action
| Version | Kernel | Status |
|---|---|---|
| CloudLinux 7h | 4.18 | Reachable as shipped — patched kernel in beta |
| CloudLinux 8 | 4.18 | Reachable as shipped — patched kernel in beta |
| CloudLinux 8 LTS | 5.14 | Reachable as shipped, fix in preparation |
| CloudLinux 9 | 5.14 | Not exposed by default, awaiting the upstream Red Hat fix |
| CloudLinux 10 | 6.12 | Not exposed by default, awaiting the upstream Red Hat fix |
| CloudLinux for Ubuntu 22.04 | 5.15 | Not exposed by default, Canonical fix in progress |
7h and 8 are the priority — they are reachable in a stock configuration and the only branches with a patched kernel available right now, even if it's still in beta.
Check your exposure
uname -r
Compare against the patched builds below. If you've already applied the mitigation, confirm it's active:
cat /etc/modprobe.d/bridge-stp-uaf.conf
lsmod | grep '^bridge '
The second command should return nothing — the mitigation only works if the bridge module hasn't already been loaded.
Apply the mitigation
A modprobe install override, effective without a reboot as long as bridge isn't loaded yet:
tee /etc/modprobe.d/bridge-stp-uaf.conf > /dev/null <<'EOF'
install bridge /bin/false
EOF
Install the patched kernel
Both available fixes are on beta/testing channels, not the main feed yet:
# CloudLinux 7h
yum update 'kernel*' --enablerepo=cl7h_beta
reboot
# CloudLinux 8
yum update 'kernel*' --enablerepo=cloudlinux-updates-testing
reboot
Target builds are kernel-4.18.0-553.157.1.lve.2.el7h and kernel-4.18.0-553.157.1.lve.2.el8. CloudLinux 8 LTS and 9 LTS have a fix in preparation with no published version yet; CloudLinux 9 and 10 are waiting on AlmaLinux to ship the upstream Red Hat kernel fix before CloudLinux can rebuild against it.
KernelCare live patching
Livepatches are in preparation for CloudLinux 7h, 8, 9, and 10 but not yet available on the testing or main feed. Once one lands for your platform:
kcarectl --update
kcarectl --patch-info | grep CVE-2026-72389
That closes the bug with no reboot and no maintenance window, which is the whole case for running KernelCare on your fleet instead of coordinating kernel-update windows across every shared server you own. One exception: KernelCare does not cover the CloudLinux 8 LTS kernel line, so that branch needs the reboot-and-update path regardless.
Exploitation status
The public disclosure includes helper code for talking to the bridge subsystem, not a working exploit, and no public proof-of-concept has surfaced as of this writing. That is not the same as low risk — the use-after-free-to-root chain here is a well-trodden pattern, and disclosure of the root cause is usually what turns into a working exploit fastest.