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 a deterministic vulnerability, 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 May 15 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.
Copy Fail is a bug in a part of the Linux kernel that lets unprivileged user programs interact with the kernel's cryptography (an interface called AF_ALG). It was introduced by a 2017 optimization to that interface and has been silently exploitable for nine years. The bug lets a local user write four attacker-chosen bytes into the kernel's in-memory cache of file contents.
That matters because the kernel doesn't read executable files from disk every time they run. It serves them from this in-memory cache. When you execute /usr/bin/su or any setuid binary, the kernel runs the cached copy. An attacker who can edit those cached bytes has effectively rewritten the program in memory without touching the file on disk. The next process that invokes su runs the attacker's modified version, configured to launch a root shell.
Theori, the firm that disclosed the vulnerability, drew an explicit contrast with two well-known prior kernel LPEs. Unlike Dirty Cow (2016) and Dirty Pipe (2022), "Copy Fail can be exploited without having to win a race condition, and the same exploit will work on many systems." The proof of concept is a 732-byte Python script using only the standard library, and it roots Ubuntu, RHEL, SUSE, and Amazon Linux without modification. Deterministic, universal, tiny: the trifecta that makes a vulnerability genuinely dangerous.
For hosting providers, the more important property is one researchers and CERT-EU emphasized post-disclosure: the page cache is shared across all processes on a host, regardless of how those processes are isolated. A single malicious customer (or a single compromised customer site running attacker code) can edit the kernel's view of a setuid binary, escalate to root, and from there reach every other account on the box. On a server hosting hundreds of tenants, that's the textbook nightmare scenario.
CISA added Copy Fail to its Known Exploited Vulnerabilities catalog on May 4, with a federal patch deadline of May 15. That's active exploitation in the wild and a hard clock for US government agencies. C and Python ports of the exploit are publicly available. The skill floor for using it has dropped to almost zero.
The standard answer to a kernel CVE is straightforward: install the patched kernel, reboot, verify. But every reboot on a shared hosting server is a customer-visible event. Sites go down for the duration. Email queues stop. Background workers terminate and restart. SSH sessions drop. For customers running anything that doesn't degrade gracefully (a busy ecommerce site, a cron job mid-execution, a long-running database export), the reboot is operationally disruptive.
Hosting providers respond by managing reboots through scheduled maintenance windows: announced in advance, and timed for low-traffic periods. Maintenance windows are scarce and contested, and "doing an extra one this week" burns customer goodwill.
So when a kernel CVE arrives that genuinely warrants immediate response, two things have to be balanced: the security exposure on one hand, and the customer-facing operational cost on the other. The bigger the fleet, the harder the task.
There are two viable paths to a patched kernel.
Apply the patched kernel from the appropriate channel as described in the advisory, schedule the reboot, verify at the end. For small fleets, this is straightforward.
The patch is applied to the running kernel without a restart. The same upstream fix lands in the same kernel memory, but no reboot is needed and no customer-visible event occurs. KernelCare-subscribed servers receive the Copy Fail livepatch automatically, in the background. Once applied, the running kernel includes the fix in memory, and subsequent kernel calls use the patched code path.
Both update paths produce the same security outcome: a patched kernel running the upstream fix. The difference is operational. For a fleet of any size where reboots are expensive, and on shared hosting they often are, livepatching is the path that doesn't trade security against customer impact.
KernelCare integrates directly with CloudLinux. Once the subscription is active, the agent can be installed as a single package, and it starts polling for patches without further configuration. For most CloudLinux customers, enabling KernelCare is a one-server, one-command task.
If server reboots are a painful exercise, get started with KernelCare at cloudlinux.com/kernelcare-hosting.
Find more information about installation and usage in our documentation.