Fixed kernels are available for the affected, exposed platforms:
- CloudLinux 8 and CloudLinux 7 Hybrid: kernel-4.18.0-553.150.1.lve.1 or newer — yum update 'kernel*' then reboot. - CloudLinux 8 LTS and CloudLinux 9 LTS: kernel-lts-5.14.0-284.1101.{el8,el9}.tuxcare.11.els12 via TuxCare ELS — yum update kernel-lts then reboot.
CloudLinux 9 and CloudLinux 10 are not affected in practice: Red Hat has marked its 9 and 10 kernels "Will not fix", AlmaLinux tracks Red Hat, and ordinary accounts are not exposed in the default configuration.
Verify with uname -r. Full details in the blog post.
Posted Sep 26, 2026 - 03:24 UTC
Update
After further analysis, we've determined that this issue will not be addressed via KernelCare for EL8 through EL10. Our assessment found that the vulnerability cannot be practically promoted to a local privilege escalation (LPE) on these distributions, meaning the exploitability demonstrated on other platforms does not translate into a working attack path here.
Posted Aug 27, 2026 - 12:03 UTC
Identified
Summary
A local privilege escalation vulnerability has been identified that allows an unprivileged user (uid=1000) to escalate to root within the initial namespace. The issue was reproduced on stock Ubuntu 22.04.5, kernel 5.15.0-187-generic (5.15.0-187.197), on a four-vCPU VM with memory-cgroup accounting enabled and nokaslr as the only exploit-specific boot argument.
Verification
The exploit was independently verified beyond its own reported success output: a persistent journald oops captured during a successful run cross-matches the forged modprobe_path write at the instruction level.
Reliability
Exploitation is unreliable and disruptive when it fails — approximately 1 success in 8 attempts, with 6 of the 8 failed attempts causing a kernel oops or hang.
Affected Platforms
Any kernel containing commit 470502de5bdb is affected — this corresponds to Linux 5.1 and later, including vendor backports that carry this commit. CloudLinux kernels are detailed below: - CloudLinux 7 (3.10) — Not affected, predates the vulnerable code. No action. - CloudLinux 7 Hybrid (4.18) — Affected. User namespaces enabled by default; corruption and host panic confirmed. Action required. - CloudLinux 8 (4.18) — Affected. User namespaces enabled by default; corruption confirmed. Action required. - CloudLinux 8 LTS (5.14, TuxCare ELS) — Code present, stock config blocks the exploit (user.max_user_namespaces=0). - CloudLinux 9 (5.14) — Code present, stock config blocks the exploit. - CloudLinux 9 LTS (5.14, TuxCare ELS) — Code present, stock config blocks the exploit. - CloudLinux 10 (6.12) — Code present, stock config blocks the exploit. - CloudLinux for Ubuntu 22.04 (5.15) — Code present, blocked by the CloudLinux sysctl overlay at /etc/sysctl.d/90-cloudlinux.conf.
Mitigation
Recommended on CloudLinux 8 and CloudLinux 7 Hybrid (no reboot required):
- CloudLinux 7 hybrid and 8: The upstream fix is being backported. Still in progress. - CloudLinux 9 and 10: In progress. - CloudLinux for Ubuntu 22.04: kernel fix comes from Canonical through Ubuntu USN. - KernelCare patchsets are currently in progress for the affected CloudLinux platforms.