Copy Fail - One WordPress away from root

Thursday, April 30, 2026

One WordPress away from root

A new Linux kernel vulnerability has been published, known as Copy Fail and tracked as CVE-2026-31431.

In short: if an attacker manages to run local code as an unprivileged user, under certain conditions they may be able to escalate privileges to root. This is not a direct remote vulnerability, but for hosting environments that distinction is not very comforting.

Why? Because in a shared hosting environment, the discussion does not start with “does someone have SSH access?”. It starts with much more common scenarios:

  • a compromised WordPress website;
  • a vulnerable plugin;
  • a webshell uploaded through a poorly protected form;
  • a compromised customer account;
  • a PHP script that ends up executing local commands.

This is why we call it: One WordPress away from root.

What Copy Fail does

The vulnerability is in the Linux kernel, in the crypto subsystem, more specifically in mechanisms related to algif_aead / authencesn.

Without going into exploitation details, the issue may allow a local user to modify content in the page cache for certain readable files. Under specific conditions, this can affect how the system loads a privileged binary, such as /usr/bin/su, which may lead to code execution with root privileges.

In plain terms: the attacker does not need to know the root password. If they can execute local code on a vulnerable system, they may be able to abuse the kernel bug to jump directly to administrative privileges.

Is it remotely exploitable?

Not directly.

Copy Fail is a local privilege escalation vulnerability. The attacker must already have some form of local code execution on the server.

The problem is that, in hosting, local code execution can come from many places. A single compromised website may be enough as a starting point. For this reason, the practical impact is serious for shared hosting servers, cPanel servers, DirectAdmin servers, multi-user systems, containers, CI runners, and any environment where code from different users is executed on the same system.

Which systems are affected

Affected systems are Linux systems running vulnerable kernels with the affected module available or loaded.

Based on public information, the vulnerability affects several major Linux distribution families, including:

  • Debian;
  • Ubuntu;
  • RHEL;
  • AlmaLinux;
  • Rocky Linux;
  • SUSE;
  • Amazon Linux.

Not all versions are affected in the same way, and the public exploit does not behave identically across all distributions. That does not automatically mean a system is safe. It only means the exact kernel version and the vendor patch status must be checked.

AlmaLinux / RHEL 9 and 10

On AlmaLinux/RHEL 9 and 10, the public exploit appears not to work in the same form on all systems, or is not as straightforward, depending on the kernel version, configuration, and available modules.

This should not be interpreted as “not affected”. The correct interpretation is:

If the vendor has not clearly confirmed that your exact version is not vulnerable, treat the system as potentially affected and apply the kernel update when it becomes available.

In production, we do not recommend relying on the fact that a public PoC does not work. The public PoC is only one implementation. The actual vulnerability is in the kernel.

Temporary workaround

Until a fixed kernel is installed, the recommended workaround is to disable the algif_aead module:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

This command blocks the vulnerable module from being loaded and attempts to unload it if it is already loaded.

Verification:

lsmod | grep algif_aead

If nothing is returned, the module is not loaded.

Please note: this workaround is temporary. The correct fix remains a kernel update and reboot.

Update and reboot

On AlmaLinux / Rocky / RHEL:

dnf update kernel
reboot

After reboot:

uname -r

If dnf-utils is installed, you can check whether the system still requires a reboot:

needs-restarting -r

On Debian / Ubuntu:

apt update
apt upgrade
reboot

After reboot:

uname -r

Which servers should be prioritized

  • shared hosting servers;
  • cPanel / WHM servers;
  • DirectAdmin servers;
  • servers with SSH users;
  • servers hosting many web applications that are hard to fully control;
  • virtualization or container nodes;
  • CI/CD runners;
  • any system where customer or third-party code is executed.

A server with a single static website and no access for other users has a lower practical risk. A shared hosting server with hundreds of websites has a much higher risk.

What we are doing

We are monitoring the situation, checking kernel versions, and applying the necessary measures on the infrastructure we manage.

Where possible, we are applying the temporary workaround. As Linux distributions publish stable kernel updates, these will be installed and servers will be rebooted in a controlled manner.

For customers with managed servers, the recommendation is simple: allow kernel updates to be applied and plan a reboot. Without a reboot, a vulnerable kernel may remain active even after the new package has been installed.

Copy Fail is another example of why account isolation, timely updates, and limiting local code execution matter. A compromised website should not be treated as only a WordPress problem. On a vulnerable system, it can become the first step toward a full server compromise.

« Back