Update - 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.
Sep 24, 2026 - 20:00 UTC
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.
Sep 24, 2026 - 20:00 UTC
Update - 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.
Sep 23, 2026 - 19:42 UTC
Sep 23, 2026 - 19:42 UTC
Update - Status summary as of September 23, 2026
CloudLinux 7:
Patch under assessment. Not exposed to ordinary accounts by default.
CloudLinux 7h and CloudLinux 8 (exposed by default):
Fixed kernel 4.18.0-553.157.1.lve.2 is in the beta channel; KernelCare livepatch is on the testing feed kcarectl --update --prefix test.
Stable/main-feed release will follow the normal schedule.
CloudLinux 8 LTS (exposed by default):
Patched kernel in preparation. KernelCare does not cover this kernel line. Keep the modprobe mitigation in place until the fixed kernel ships.
CloudLinux 9:
KernelCare livepatch on the main feed kernel 5.14.0-687.46.1.el9_8.
Not exposed to ordinary accounts by default.
CloudLinux 9 LTS:
Patch in preparation. Not exposed to ordinary accounts by default.
CloudLinux 10: KernelCare livepatch on the main feed kernel 6.12.0-211.53.1.el10_2.
Not exposed to ordinary accounts by default.
Verify a KernelCare-patched server with:
kcarectl --patch-info | grep CVE-2026-72389
Full details and mitigation instructions: https://blog.cloudlinux.com/bridge-stp-uaf-cve-2026-72389-kernel-update-cloudlinux
Sep 22, 2026 - 23:05 UTC
CloudLinux 7:
Patch under assessment. Not exposed to ordinary accounts by default.
CloudLinux 7h and CloudLinux 8 (exposed by default):
Fixed kernel 4.18.0-553.157.1.lve.2 is in the beta channel; KernelCare livepatch is on the testing feed kcarectl --update --prefix test.
Stable/main-feed release will follow the normal schedule.
CloudLinux 8 LTS (exposed by default):
Patched kernel in preparation. KernelCare does not cover this kernel line. Keep the modprobe mitigation in place until the fixed kernel ships.
CloudLinux 9:
KernelCare livepatch on the main feed kernel 5.14.0-687.46.1.el9_8.
Not exposed to ordinary accounts by default.
CloudLinux 9 LTS:
Patch in preparation. Not exposed to ordinary accounts by default.
CloudLinux 10: KernelCare livepatch on the main feed kernel 6.12.0-211.53.1.el10_2.
Not exposed to ordinary accounts by default.
Verify a KernelCare-patched server with:
kcarectl --patch-info | grep CVE-2026-72389
Full details and mitigation instructions: https://blog.cloudlinux.com/bridge-stp-uaf-cve-2026-72389-kernel-update-cloudlinux
Sep 22, 2026 - 23:05 UTC
Update - KernelCare livepatches for CloudLinux 7h and CloudLinux 8 have reached the testing feed. The CloudLinux 7h patch covers kernel 4.18.0-553.157.1.lve.2.el7h. Servers on the default feed do not have these yet; to take one from the testing feed now:
kcarectl --update --prefix test
Sep 22, 2026 - 23:05 UTC
kcarectl --update --prefix test
Sep 22, 2026 - 23:05 UTC
Update - 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.
Sep 19, 2026 - 04:00 UTC
Sep 19, 2026 - 04:00 UTC
Update - The KernelCare livepatch for CloudLinux 9 is now on the main feed, covering kernel 5.14.0-687.46.1.el9_8. Subscribed servers receive it automatically on the next update cycle, or immediately with kcarectl --update; verify with kcarectl --patch-info | grep CVE-2026-72389.
Sep 15, 2026 - 23:51 UTC
Sep 15, 2026 - 23:51 UTC
Identified - 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 beta channel; promotion to stable follows on the normal schedule. → 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): in preparation. → Stream 3
KernelCare livepatch: in preparation. → 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
Sep 10, 2026 - 17:53 UTC
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 beta channel; promotion to stable follows on the normal schedule. → 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): in preparation. → Stream 3
KernelCare livepatch: in preparation. → 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
Sep 10, 2026 - 17:53 UTC
Update - Patched kernels are available for all affected platforms:
- CloudLinux 7h / 8: kernel-4.18.0-553.139.3.lve.el7h / kernel-4.18.0-553.139.3.lve.el8 or newer, in the stable channel — yum update 'kernel*' and reboot; testing-channel steps are no longer needed
- CloudLinux 9 / 10: in the AlmaLinux production repositories (kernel-5.14.0-687.23.1.el9_8, kernel-6.12.0-211.31.1.el10_2 or newer) — dnf update kernel and reboot
- CloudLinux 8 LTS / 9 LTS: patched kernel-lts in the TuxCare ELS stable repository — yum update kernel-lts and reboot
KernelCare livepatches are on the main feed for CloudLinux 8, 9, 10, and CloudLinux for Ubuntu 22.04, and in the testing feed for CloudLinux 7h.
Sep 03, 2026 - 20:02 UTC
- CloudLinux 7h / 8: kernel-4.18.0-553.139.3.lve.el7h / kernel-4.18.0-553.139.3.lve.el8 or newer, in the stable channel — yum update 'kernel*' and reboot; testing-channel steps are no longer needed
- CloudLinux 9 / 10: in the AlmaLinux production repositories (kernel-5.14.0-687.23.1.el9_8, kernel-6.12.0-211.31.1.el10_2 or newer) — dnf update kernel and reboot
- CloudLinux 8 LTS / 9 LTS: patched kernel-lts in the TuxCare ELS stable repository — yum update kernel-lts and reboot
KernelCare livepatches are on the main feed for CloudLinux 8, 9, 10, and CloudLinux for Ubuntu 22.04, and in the testing feed for CloudLinux 7h.
Sep 03, 2026 - 20:02 UTC
Monitoring - The patched kernels are in the AlmaLinux production repositories:
CL9 / AlmaLinux 9 kernel-5.14.0-687.23.1.el9_8 or newer.
CL10 / AlmaLinux 10 kernel-6.12.0-211.31.1.el10_2 or newer.
A plain dnf update kernel followed by a reboot is sufficient. The testing-repository steps below are no longer needed.
Aug 25, 2026 - 22:19 UTC
CL9 / AlmaLinux 9 kernel-5.14.0-687.23.1.el9_8 or newer.
CL10 / AlmaLinux 10 kernel-6.12.0-211.31.1.el10_2 or newer.
A plain dnf update kernel followed by a reboot is sufficient. The testing-repository steps below are no longer needed.
Aug 25, 2026 - 22:19 UTC
Update - Patched kernel-lts package for CloudLinux 8 LTS and CloudLinux 9 LTS being prepared, installed from the TuxCare ELS repository, a pipeline separate from the stock CloudLinux 8 and 9 kernel rebuild. Install with yum update kernel-lts and reboot.
The KernelCare livepatch is available as a no-reboot alternative.
Jul 31, 2026 - 12:06 UTC
The KernelCare livepatch is available as a no-reboot alternative.
Jul 31, 2026 - 12:06 UTC
Update - NEW el9 / CL9 family:
-- K20260710_58 (rhel9)
-- K20260710_60 (almalinux9 = CL9)
-- K20260710_63 (oel9)
-- K20260710_65 (rockylinux9)
Still OPEN:
-- UEK:
uek6, uek7
-- amazon2
-- ubuntu-bionic
Jul 29, 2026 - 09:14 UTC
-- K20260710_58 (rhel9)
-- K20260710_60 (almalinux9 = CL9)
-- K20260710_63 (oel9)
-- K20260710_65 (rockylinux9)
Still OPEN:
-- UEK:
uek6, uek7
-- amazon2
-- ubuntu-bionic
Jul 29, 2026 - 09:14 UTC
Update - KernelCare livepatch for Januscape, by CloudLinux platform:
Fully rolled out on the main feed: CloudLinux 10 and CloudLinux for Ubuntu 22.04.
On the main feed (staged rollout): CloudLinux 8.
In the testing feed: CloudLinux 7h.
Still in preparation: CloudLinux 9.
Jul 11, 2026 - 03:15 UTC
Fully rolled out on the main feed: CloudLinux 10 and CloudLinux for Ubuntu 22.04.
On the main feed (staged rollout): CloudLinux 8.
In the testing feed: CloudLinux 7h.
Still in preparation: CloudLinux 9.
Jul 11, 2026 - 03:15 UTC
Update - Patched CloudLinux CL7h/CL8 kernels are released to the beta/testing channel. Target versions:
- CL7h kernel-4.18.0-553.139.3.lve.el7h or newer.
- CL8 kernel-4.18.0-553.139.3.lve.el8 or newer.
Promotion to the stable channel follows after the testing period.
AlmaLinux 9/10 has published patched kernels to its testing repository. Target versions:
- CL9 / AlmaLinux 9: kernel-5.14.0-687.20.3.el9_8 or newer.
- CL10 / AlmaLinux 10: kernel-6.12.0-211.30.3.el10_2 or newer.
For more detailed information and instructions on updating and mitigation, please visit our blog post: Januscape (CVE-2026-53359): Mitigation and Kernel Update on CloudLinux
Jul 07, 2026 - 17:08 UTC
- CL7h kernel-4.18.0-553.139.3.lve.el7h or newer.
- CL8 kernel-4.18.0-553.139.3.lve.el8 or newer.
Promotion to the stable channel follows after the testing period.
AlmaLinux 9/10 has published patched kernels to its testing repository. Target versions:
- CL9 / AlmaLinux 9: kernel-5.14.0-687.20.3.el9_8 or newer.
- CL10 / AlmaLinux 10: kernel-6.12.0-211.30.3.el10_2 or newer.
For more detailed information and instructions on updating and mitigation, please visit our blog post: Januscape (CVE-2026-53359): Mitigation and Kernel Update on CloudLinux
Jul 07, 2026 - 17:08 UTC
Identified - KernelCare is rolling out live patches for CVE-2026-53359 + CVE-2026-46113 (both required; tracked under the "CVE-2026-46113 and follow-up N-day kvm fixes" tickets).
Release state below is from the live release data
In feed now (by release):
EL10:
K20260703_15 (rhel10),
K20260703_16 (oel10),
K20260703_17 (rockylinux10),
K20260703_18 (almalinux10)
Debian 13: K20260706_09 (test feed)
Ubuntu Jammy: K20260706_01 (+ _02 arm64, _03 azure, _04 aws) (test feed)
Ubuntu Focal-on-Jammy-HWE: K20260706_06 (+ _05 azure, _07 aws) (test feed)
Proxmox VE 7 (5.15): K20260706_08 (test feed)
Not yet in any feed: el8, el9, ubuntu-noble, debian11, debian12, plain ubuntu-focal, uek6/uek7, ubuntu-bionic.
They are in active development (pushing to the release)
LibCare: out of scope (kernel-only).
kcarectl --update --prefix test # from testing feed
kcarectl --update # once promoted to main
Verify:
kcarectl --info | grep kpatch-build-time # build dated 2026-07 or later
kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113' # both fixes needed for Januscape
Hosts that do NOT run VMs but have KVM loaded by default — remove the attack surface entirely:
# unload now (fails if a VM is running → that host isn't a candidate)
sudo modprobe -r kvm_intel kvm # kvm_amd on AMD
# prevent load on boot ("install /bin/false" also blocks dependency/explicit loads,
# which a plain "blacklist" line does not)
printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
| sudo tee /etc/modprobe.d/disable-kvm.conf
Verify: lsmod | grep kvm is empty and ls /dev/kvm → No such file. Revert: remove /etc/modprobe.d/disable-kvm.conf and modprobe kvm_intel (or reboot).
Hosts that DO run VMs — cannot unload; they depend on the livepatch. Partial hardening for the unprivileged-local vector on RHEL-family (where /dev/kvm is 0666) only:
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | sudo tee /etc/udev/rules.d/65-kvm.rules
# then: sudo udevadm control --reload && sudo udevadm trigger (or reboot)
Perm-tightening does not stop a malicious VM guest — the guest→host escape still works via QEMU. Full coverage on a VM host = the livepatch.
Jul 07, 2026 - 15:10 UTC
Release state below is from the live release data
In feed now (by release):
EL10:
K20260703_15 (rhel10),
K20260703_16 (oel10),
K20260703_17 (rockylinux10),
K20260703_18 (almalinux10)
Debian 13: K20260706_09 (test feed)
Ubuntu Jammy: K20260706_01 (+ _02 arm64, _03 azure, _04 aws) (test feed)
Ubuntu Focal-on-Jammy-HWE: K20260706_06 (+ _05 azure, _07 aws) (test feed)
Proxmox VE 7 (5.15): K20260706_08 (test feed)
Not yet in any feed: el8, el9, ubuntu-noble, debian11, debian12, plain ubuntu-focal, uek6/uek7, ubuntu-bionic.
They are in active development (pushing to the release)
LibCare: out of scope (kernel-only).
How to update?
kcarectl --update --prefix test # from testing feed
kcarectl --update # once promoted to main
Verify:
kcarectl --info | grep kpatch-build-time # build dated 2026-07 or later
kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113' # both fixes needed for Januscape
How to mitigate until the patch will be available?
Hosts that do NOT run VMs but have KVM loaded by default — remove the attack surface entirely:
# unload now (fails if a VM is running → that host isn't a candidate)
sudo modprobe -r kvm_intel kvm # kvm_amd on AMD
# prevent load on boot ("install /bin/false" also blocks dependency/explicit loads,
# which a plain "blacklist" line does not)
printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
| sudo tee /etc/modprobe.d/disable-kvm.conf
Verify: lsmod | grep kvm is empty and ls /dev/kvm → No such file. Revert: remove /etc/modprobe.d/disable-kvm.conf and modprobe kvm_intel (or reboot).
Hosts that DO run VMs — cannot unload; they depend on the livepatch. Partial hardening for the unprivileged-local vector on RHEL-family (where /dev/kvm is 0666) only:
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | sudo tee /etc/udev/rules.d/65-kvm.rules
# then: sudo udevadm control --reload && sudo udevadm trigger (or reboot)
Perm-tightening does not stop a malicious VM guest — the guest→host escape still works via QEMU. Full coverage on a VM host = the livepatch.
Jul 07, 2026 - 15:10 UTC
Investigating - Confirmed exploitable in our lab.
Any KVM hypervisor host with the kvm_intel / kvm_amd modules loaded and /dev/kvm present is affected — i.e. the default posture on the KVM/enterprise fleet.
Impact ranges from host DoS (unprivileged, reliable) up to a full guest→host escape running as root .
On RHEL-family, /dev/kvm is world-accessible (0666), so an unprivileged local user can trigger it directly.
Jul 07, 2026 - 15:05 UTC
Any KVM hypervisor host with the kvm_intel / kvm_amd modules loaded and /dev/kvm present is affected — i.e. the default posture on the KVM/enterprise fleet.
Impact ranges from host DoS (unprivileged, reliable) up to a full guest→host escape running as root .
On RHEL-family, /dev/kvm is world-accessible (0666), so an unprivileged local user can trigger it directly.
Jul 07, 2026 - 15:05 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.
Aug 27, 2026 - 12:03 UTC
Aug 27, 2026 - 12:03 UTC
Identified -
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.
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.
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.
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.
Recommended on CloudLinux 8 and CloudLinux 7 Hybrid (no reboot required):
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-rtabrace.conf
sysctl -p /etc/sysctl.d/99-rtabrace.conf
- 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.
Aug 14, 2026 - 10:50 UTC
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):
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-rtabrace.conf
sysctl -p /etc/sysctl.d/99-rtabrace.conf
Current Status
- 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.
Aug 14, 2026 - 10:50 UTC
Update - KernelCare live patches shipped for el8 + el9 kernels:
(RHEL/CentOS/Oracle/CloudLinux/Alma/Rocky, including cl8, cl7h and el9 FIPS/LTS)
el10, UEK R6/R7, and Amazon Linux 2/2023 still in progress.
Deploying the livepatch:
kcarectl --update --prefix test # from testing feed
kcarectl --update # once promoted to main
How to verify you are patched:
uname -r # fixed if: 5.14.0-687.26.1.el9_8+ / 4.18.0-553.144.1.el8_10+ / 6.12.0-211.34.1.el10_2+
kcarectl --info | grep kpatch-build-time # el8/el9 livepatch build dated 2026-07-16/17 or later
kcarectl --patch-info | grep -iE 'xfs|CVE-2026-64600' # silent releases carried no CVE ref at ship time
Jul 23, 2026 - 06:09 UTC
(RHEL/CentOS/Oracle/CloudLinux/Alma/Rocky, including cl8, cl7h and el9 FIPS/LTS)
el10, UEK R6/R7, and Amazon Linux 2/2023 still in progress.
Deploying the livepatch:
kcarectl --update --prefix test # from testing feed
kcarectl --update # once promoted to main
How to verify you are patched:
uname -r # fixed if: 5.14.0-687.26.1.el9_8+ / 4.18.0-553.144.1.el8_10+ / 6.12.0-211.34.1.el10_2+
kcarectl --info | grep kpatch-build-time # el8/el9 livepatch build dated 2026-07-16/17 or later
kcarectl --patch-info | grep -iE 'xfs|CVE-2026-64600' # silent releases carried no CVE ref at ship time
Jul 23, 2026 - 06:09 UTC
Monitoring - The patched CL8 kernel is available in our rollout repositories. Target version:
- CL8: kernel-4.18.0-553.144.1.lve.el8 or newer
To update, please run:
dnf update 'kernel*' --enablerepo=cloudlinux-rollout*
The patched CL9/CL10 are available in the stable repository. Target versions:
- CL9: kernel-5.14.0-687.26.1.el9_8 or newer
- CL10: kernel-6.12.0-211.34.1.el10_2 or newer
Jul 23, 2026 - 00:10 UTC
- CL8: kernel-4.18.0-553.144.1.lve.el8 or newer
To update, please run:
dnf update 'kernel*' --enablerepo=cloudlinux-rollout*
The patched CL9/CL10 are available in the stable repository. Target versions:
- CL9: kernel-5.14.0-687.26.1.el9_8 or newer
- CL10: kernel-6.12.0-211.34.1.el10_2 or newer
Jul 23, 2026 - 00:10 UTC
Investigating - RefluXFS (CVE-2026-64600), an XFS reflink direct-I/O race. A lock-drop window in the copy-on-write allocation path lets an unprivileged local user overwrite the on-disk contents of any file they can read (e.g.,/etc/passwd or a SUID-root binary) on any XFS with reflink=1 (the mkfs default since 2019, so the CloudLinux default). Result is full root.
CloudLinux 8, 9, and 10 are affected. The mitigation, patched kernel packages, and KernelCare live patch are currently in preparation. There is no fixed kernel to update to and no live patch in the feeds at this time.
Jul 22, 2026 - 19:06 UTC
CloudLinux 8, 9, and 10 are affected. The mitigation, patched kernel packages, and KernelCare live patch are currently in preparation. There is no fixed kernel to update to and no live patch in the feeds at this time.
Jul 22, 2026 - 19:06 UTC
About This Site
Welcome to CloudLinux status page. Here you can see if there are any ongoing issues with the CloudLinux network or other services.
CloudLinux OS Components
Operational
Alt-PHP
Operational
CageFS
Operational
MySQL Governor
Operational
EasyApache4 PHP packages
Operational
CloudLinux Kernel
Operational
Mod_lsapi
Operational
PHP Selector
Operational
Python Selector
Operational
Ruby Selector
Operational
Node.js Selector
Operational
CloudLinux Network
Operational
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance