Most kernel CVEs follow a predictable rhythm for hosting providers: read the advisory, schedule a maintenance window, reboot during off-peak. Copy Fail (CVE-2026-31431) breaks that rhythm. It's deterministic, universal across Linux distributions, and lets a single compromised account on a shared host pivot to root over every other account on the same node. CISA added it to the actively-exploited list with a 15-day federal patch deadline. A severe combination for shared hosting: high impact on multi-tenant servers, and a fix that requires a reboot on every box.

CVE-2026-31431 (Copy Fail) is a Linux kernel local privilege escalation vulnerability in the algif_aead module (AF_ALG). Any unprivileged local user can gain root via a 732-byte Python exploit. All kernels since 2017 are affected.

CVE-2026-31431 (Copy Fail) is a Linux kernel local privilege escalation in the algif_aead module (AF_ALG). Any unprivileged local user can gain root via a 732-byte Python exploit. All Linux kernels since 2017 are affected.

A lot has shipped since the Q1 edition of CloudLinux Product Pulse. The Q2 session on April 29 at 4pm CET / 10am ET covers all of it: what's new, what it means for your hosting operations, and where the product roadmap is heading next

Here's a preview of the topics we'll cover.

Cached WordPress pages, 3x faster

Starting May 1, 2026, CloudLinux will sign new packages for CloudLinux 7, 8, and 9 exclusively with a new GPG key.

CloudLinux now supports cgroup v2 on CloudLinux 8, 9, 10, and Ubuntu 22. New installations of CloudLinux 10 following this release will use cgroup v2 by default. On all other versions, cgroup v1 remains the default, and you can switch to v2 when you're ready.

From a day-to-day operations standpoint, practically nothing changes. Your LVE limits, control panel interface, and resource monitoring all continue to work the same way.

MAx Cache is now generally available as part of CloudLinux subscriptions at no additional cost. After testing in beta, both the Apache and Nginx modules are now production-ready.

MAx Cache is a pair of native web server modules that serve cached WordPress pages directly from Apache or Nginx, without running PHP. Hosting providers deploy it at the server level. Site owners enable it through the AccelerateWP plugin in WordPress. If you followed the beta, the workflow is the same. If you're hearing about MAx Cache for the first time, read on.

Hosting servers with Apache can now handle 18% more traffic with 20% faster response times, without any configuration changes. Today we're announcing the beta release of .htaccess cache, a new feature in MAx Cache that compiles .htaccess files into memory, eliminating the per-request disk I/O that slows down every page load on a server.

This new feature builds on the MAx Cache for Apache module we released in December 2025 and the MAx Cache for Nginx module that followed in early 2026. If you already run MAx Cache for Apache, you get .htaccess caching with a single package update. No new packages, no new configuration.

This release also adds CloudLinux 10 support across the entire MAx Cache stack: Apache module, Nginx module, and .htaccess caching..