Then reboot. Promotion to the stable channel follows after beta validation.
Posted May 15, 2026 - 21:23 UTC
Update
AlmaLinux has published patched kernels to the testing repository (AlmaLinux advisory). Target versions:
CloudLinux 9 / AlmaLinux 9: kernel-5.14.0-611.54.6.el9_7 CloudLinux 10 / AlmaLinux 10: kernel-6.12.0-124.56.5.el10_1 Promotion to the production repositories is pending community verification.
New status for CL7h and CL8 - this bug persists in the kernel, but is not yet exploitable with the current exploit.
Posted May 15, 2026 - 12:36 UTC
Investigating
Right after the kernel privilege-escalation chain in the XFRM/ESP subsystem (Copy Fail, Dirty Frag, Fragnesia), Qualys disclosed a different Linux kernel issue. This time in the ptrace access-check path. No official name or CVE has been assigned at the time of writing (the working name will be filled in once Qualys / NVD publish). A public proof-of-concept exists. An unprivileged local user on an affected host can use it to read root-owned secrets (SSH host private keys and the shadow password database) without obtaining root privileges directly.
Affected CloudLinux versions:
CloudLinux 7 (CL7) No CloudLinux 7h (CL7h) No CloudLinux 8 (CL8) No CloudLinux 9 (CL9 ) Yes CloudLinux 10 (CL10) Yes
There are three layers of mitigation, applicable independently or in combination: 1) The recommended quick win is the CloudLinux-specific sysctl kernel.user_ptrace=0 . It blocks the issue at the kernel level host-wide and is reversible with a single sysctl. Followed by CageFS (already protects caged tenants by default) and SUID strip as a tactical fallback
Note: with kernel.user_ptrace=0, unprivileged users can no longer attach gdb -p, strace -p, or perf trace --pid to their own processes. Monitoring agents that ptrace-attach without CAP_SYS_PTRACE will also break. On typical shared-hosting workloads this is acceptable; on developer or CI hosts, expect attach-debug to break for non-root users.