Update - 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.
Oct 07, 2026 - 16:09 UTC
Oct 07, 2026 - 16:09 UTC
Update - 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.
Oct 02, 2026 - 20:15 UTC
Oct 02, 2026 - 20:15 UTC
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 - Update, October 7, 2026
The fixed build, kmod-lve 2.1-80, is in the beta channel since October 7. The package changelog lists CLKRN-2367 (changelog.cloudlinux.com does not show 2.1-80 yet). To install it on an affected CloudLinux 8 server with cgroup v1, run as root and then reboot:
dnf update kmod-lve --enablerepo=cloudlinux-updates-testing
reboot
If you added kmod-lve to the exclude= line in /etc/dnf/dnf.conf earlier, remove it first, otherwise dnf will skip the package
A staged rollout of 2.1-80 to the stable channel has been requested, and this incident will be updated when it lands
Please note that kmod-lve 2.1-78 reached the stable channel on October 6, so a regular dnf update now installs it. If your CloudLinux 8 server runs cgroup v1 and has not been updated yet, add kmod-lve to (or keep it on) the exclude= line in /etc/dnf/dnf.conf until the fixed build is in the stable channel, or install 2.1-80 from the beta channel as shown above. Servers on cgroup v2 are not affected
Oct 07, 2026 - 16:07 UTC
The fixed build, kmod-lve 2.1-80, is in the beta channel since October 7. The package changelog lists CLKRN-2367 (changelog.cloudlinux.com does not show 2.1-80 yet). To install it on an affected CloudLinux 8 server with cgroup v1, run as root and then reboot:
dnf update kmod-lve --enablerepo=cloudlinux-updates-testing
reboot
If you added kmod-lve to the exclude= line in /etc/dnf/dnf.conf earlier, remove it first, otherwise dnf will skip the package
A staged rollout of 2.1-80 to the stable channel has been requested, and this incident will be updated when it lands
Please note that kmod-lve 2.1-78 reached the stable channel on October 6, so a regular dnf update now installs it. If your CloudLinux 8 server runs cgroup v1 and has not been updated yet, add kmod-lve to (or keep it on) the exclude= line in /etc/dnf/dnf.conf until the fixed build is in the stable channel, or install 2.1-80 from the beta channel as shown above. Servers on cgroup v2 are not affected
Oct 07, 2026 - 16:07 UTC
Update - A fixed kmod-lve build will list CLKRN-2367 in its changelog: https://changelog.cloudlinux.com/search?value=CLKRN-2367
Oct 06, 2026 - 23:22 UTC
Oct 06, 2026 - 23:22 UTC
Identified - On some CloudLinux 8 servers using cgroup v1, after updating to kmod-lve 2.1-78 or 2.1-79 and rebooting, LVEs cannot be created.
Websites return 508 Resource Limit Is Reached, and the kernel log repeats lines like these (the numbers differ per server and account):
LVE: [NNNN] init_lve: subsys 2 lveNNNN err -2
LVE: [NNNN] _lve_enter: Can't alloc ve #NNNN lvp #0, rc -22
CloudLinux 8 servers on cgroup v2 are not affected.
Workaround:
Go back to kmod-lve 2.1-76 and keep it until the fixed build is released. Run as root (use 2.1-79 in the remove command if that is the installed build):
dnf install kmod-lve-2.1-76.el8
dnf remove kmod-lve-2.1-78.el8
reboot
Then add kmod-lve to the exclude= line in /etc/dnf/dnf.conf; otherwise, the next update installs the affected build again.
An alternative that keeps 2.1-78/2.1-79 is described in the article below.
For more info, please check:
https://cloudlinux.zendesk.com/hc/en-us/articles/30857405854620-LVE-Creation-Fails-with-init-lve-subsys-2-err-2-After-Updating-kmod-lve-to-2-1-78
Oct 06, 2026 - 23:09 UTC
Websites return 508 Resource Limit Is Reached, and the kernel log repeats lines like these (the numbers differ per server and account):
LVE: [NNNN] init_lve: subsys 2 lveNNNN err -2
LVE: [NNNN] _lve_enter: Can't alloc ve #NNNN lvp #0, rc -22
CloudLinux 8 servers on cgroup v2 are not affected.
Workaround:
Go back to kmod-lve 2.1-76 and keep it until the fixed build is released. Run as root (use 2.1-79 in the remove command if that is the installed build):
dnf install kmod-lve-2.1-76.el8
dnf remove kmod-lve-2.1-78.el8
reboot
Then add kmod-lve to the exclude= line in /etc/dnf/dnf.conf; otherwise, the next update installs the affected build again.
An alternative that keeps 2.1-78/2.1-79 is described in the article below.
For more info, please check:
https://cloudlinux.zendesk.com/hc/en-us/articles/30857405854620-LVE-Creation-Fails-with-init-lve-subsys-2-err-2-After-Updating-kmod-lve-to-2-1-78
Oct 06, 2026 - 23:09 UTC
Identified - On September 18, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalogue: CVE-2025-39964 (a crypto-socket flaw), CVE-2026-53266 (a bridge-firewall flaw), and CVE-2025-39682 (a kernel-TLS flaw). They are three separate bugs in different parts of the kernel. Fixing one has nothing to do with the others.
Which versions each one affects is in the affected table. In short: the crypto flaw affects every CloudLinux version; the bridge flaw affects every version but is reachable by an ordinary account only on some; the TLS flaw affects only CloudLinux 8 LTS, 9, 9 LTS, and 10.
The three flaws:
CVE-2025-39964, the crypto-socket flaw: a public exploit escalates an ordinary account to root. → details
CVE-2026-53266, the bridge-firewall flaw: memory corruption or privilege escalation, reachable by an ordinary account only where private network spaces are open. → details
CVE-2025-39682, the kernel-TLS flaw: can leak kernel memory or crash the machine on affected systems. → details
Two fix routes: a KernelCare livepatch applies with no reboot where one is available; otherwise the fix is a kernel update and reboot. The fix-status table gives both routes per version, and the update instructions carry the streams.
Check whether a server is patched → How to verify
How the bugs work → Technical details
Oct 07, 2026 - 12:48 UTC
Which versions each one affects is in the affected table. In short: the crypto flaw affects every CloudLinux version; the bridge flaw affects every version but is reachable by an ordinary account only on some; the TLS flaw affects only CloudLinux 8 LTS, 9, 9 LTS, and 10.
The three flaws:
CVE-2025-39964, the crypto-socket flaw: a public exploit escalates an ordinary account to root. → details
CVE-2026-53266, the bridge-firewall flaw: memory corruption or privilege escalation, reachable by an ordinary account only where private network spaces are open. → details
CVE-2025-39682, the kernel-TLS flaw: can leak kernel memory or crash the machine on affected systems. → details
Two fix routes: a KernelCare livepatch applies with no reboot where one is available; otherwise the fix is a kernel update and reboot. The fix-status table gives both routes per version, and the update instructions carry the streams.
Check whether a server is patched → How to verify
How the bugs work → Technical details
Oct 07, 2026 - 12:48 UTC
Update - The published attack doesn’t work on the CloudLinux 7h and 8 kernels, according to our analysis of their code, so no update is needed for these versions. Red Hat lists RHEL 8 as affected by CVE-2026-64507 and not affected by CVE-2026-64508. If Red Hat releases a fix for RHEL 8, CloudLinux 7h and 8 will pick it up once AlmaLinux 8 has it, and we’ll note it here.
Oct 07, 2026 - 12:34 UTC
Oct 07, 2026 - 12:34 UTC
Identified - BTR (CVE-2026-64507, CVE-2026-64508, Moderate per Red Hat) is a Spectre v2 variant that lets a local unprivileged user read kernel memory. It does not give root by itself. A public proof-of-concept exists for two Intel processor microarchitectures, and no exploitation in the wild has been reported.
Affected: every CloudLinux version except CloudLinux 7. → Affected CloudLinux versions
Processors: whether an attack can succeed also depends on the processor. The published exploit works on two Intel microarchitectures only. → Which processors are at risk
Mitigation: none. → Is there a mitigation?
Fix status: fixed upstream on July 25, 2026. Red Hat, AlmaLinux and Canonical haven’t released it yet. → Update instructions
CloudLinux 7h and 8 kernel: CloudLinux builds it once AlmaLinux 8 has the fix.
AlmaLinux kernel (CloudLinux 9, 10): follows Red Hat, which lists its kernels as affected and has released no fix yet.
LTS kernels (CloudLinux 8 LTS, 9 LTS): follow Red Hat’s release.
KernelCare livepatch: follows the vendor fixes.
CloudLinux for Ubuntu 22.04: the fix comes from Canonical, which hasn’t released it for 22.04 yet.
Why it matters: on a shared host, a compromised site is enough to run the attack. → Why this matters on a shared host
How the bug works: the processor keeps old branch predictions when the kernel reuses memory for a new filter program. → Technical details of the bug
Oct 05, 2026 - 16:10 UTC
Affected: every CloudLinux version except CloudLinux 7. → Affected CloudLinux versions
Processors: whether an attack can succeed also depends on the processor. The published exploit works on two Intel microarchitectures only. → Which processors are at risk
Mitigation: none. → Is there a mitigation?
Fix status: fixed upstream on July 25, 2026. Red Hat, AlmaLinux and Canonical haven’t released it yet. → Update instructions
CloudLinux 7h and 8 kernel: CloudLinux builds it once AlmaLinux 8 has the fix.
AlmaLinux kernel (CloudLinux 9, 10): follows Red Hat, which lists its kernels as affected and has released no fix yet.
LTS kernels (CloudLinux 8 LTS, 9 LTS): follow Red Hat’s release.
KernelCare livepatch: follows the vendor fixes.
CloudLinux for Ubuntu 22.04: the fix comes from Canonical, which hasn’t released it for 22.04 yet.
Why it matters: on a shared host, a compromised site is enough to run the attack. → Why this matters on a shared host
How the bug works: the processor keeps old branch predictions when the kernel reuses memory for a new filter program. → Technical details of the bug
Oct 05, 2026 - 16:10 UTC
dnf update aborts on CL9 + EPEL: ea-php81-85-php-gd and alt-php GD require libavif.so.15, EPEL 9 libavif 1.1.1 clashes with alt-common libavif/svt-av1-libs
Subscribe
Update - Two new security builds of the GD extension in the PHP ELS repository, alt-php74-gd-7.4.33-75 and alt-php81-gd-8.1.34-32, were built against an older version of the libavif image library than the rest of your system uses, so dnf was unable to install them. Our developers have already prepared corrected builds (alt-php74-gd-7.4.33-78 and alt-php81-gd-8.1.34-36), which also include the security fixes from the affected builds.
They have already been released and are available in the stable repository.
Oct 02, 2026 - 17:36 UTC
They have already been released and are available in the stable repository.
Oct 02, 2026 - 17:36 UTC
Monitoring - We have rebuilt every GD package against libavif.so.16 and now ship the same versions as EPEL, so the dependency conflict no longer occurs.
- If you applied the temporary workaround, remove the excludepkgs=libavif* svt-av1* (or exclude=) line from the [epel] section of /etc/yum.repos.d/epel.repo (and from any other repo file you edited).
- Run dnf clean metadata && dnf update --nobest. It now completes with no libavif, svt-av1 or libdav1d problems. A server that never had the workaround just needs dnf update --nobest.
- Restart the PHP handlers so the GD module loads the new library. /scripts/restartsrv_httpd and /scripts/restartsrv_apache_php_fpm.
To confirm you have the fix: rpm -q --requires ea-php8X-php-gd | grep avif should show libavif.so.16.
Known residual issue: After the libavif fix, dnf update may now stop on the alt-phpXX database add-ons, for example:
package alt-php84-mariadb1011-8.4.25-1.el9.x86_64 from @System requires alt-php84-common = 8.4.25, but none of the providers can be installed
This is a separate packaging issue: the mariadb/mysql add-ons have not yet been rebuilt to the matching versions. This is being addressed under an internal task (ALTPHP-2631).
As a temporary measure, run dnf update --nobest. This applies the rest of the update from the stable repositories and leaves only the not-yet-rebuilt add-ons at their current version. Once the rebuilt add-ons land, a plain dnf update completes with nothing skipped.
Oct 01, 2026 - 20:51 UTC
- If you applied the temporary workaround, remove the excludepkgs=libavif* svt-av1* (or exclude=) line from the [epel] section of /etc/yum.repos.d/epel.repo (and from any other repo file you edited).
- Run dnf clean metadata && dnf update --nobest. It now completes with no libavif, svt-av1 or libdav1d problems. A server that never had the workaround just needs dnf update --nobest.
- Restart the PHP handlers so the GD module loads the new library. /scripts/restartsrv_httpd and /scripts/restartsrv_apache_php_fpm.
To confirm you have the fix: rpm -q --requires ea-php8X-php-gd | grep avif should show libavif.so.16.
Known residual issue: After the libavif fix, dnf update may now stop on the alt-phpXX database add-ons, for example:
package alt-php84-mariadb1011-8.4.25-1.el9.x86_64 from @System requires alt-php84-common = 8.4.25, but none of the providers can be installed
This is a separate packaging issue: the mariadb/mysql add-ons have not yet been rebuilt to the matching versions. This is being addressed under an internal task (ALTPHP-2631).
As a temporary measure, run dnf update --nobest. This applies the rest of the update from the stable repositories and leaves only the not-yet-rebuilt add-ons at their current version. Once the rebuilt add-ons land, a plain dnf update completes with nothing skipped.
Oct 01, 2026 - 20:51 UTC
Update - We are continuing to investigate this issue.
Sep 29, 2026 - 16:28 UTC
Sep 29, 2026 - 16:28 UTC
Investigating - On CL9 cPanel servers with EPEL enabled (default best=True), `dnf update` / upcp aborts completely:
"package ea-php8X-php-gd ... requires libavif.so.15()(64bit), but none of the providers can be installed".
To let updates proceed, add this line to the [epel] section of /etc/yum.repos.d/epel.repo and run your update again:
excludepkgs=libavif* svt-av1*
This is a temporary workaround. Remove the exclude once the fix (ALTPHP-2626) is released. A regular dnf update will then complete normally.
Sep 29, 2026 - 15:33 UTC
"package ea-php8X-php-gd ... requires libavif.so.15()(64bit), but none of the providers can be installed".
To let updates proceed, add this line to the [epel] section of /etc/yum.repos.d/epel.repo and run your update again:
excludepkgs=libavif* svt-av1*
This is a temporary workaround. Remove the exclude once the fix (ALTPHP-2626) is released. A regular dnf update will then complete normally.
Sep 29, 2026 - 15:33 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