CVE-2026-31431 "Copy Fail": What This Linux Kernel Vulnerability Means and How to Respond

On April 29, 2026, a Linux kernel vulnerability called Copy Fail (CVE-2026-31431) was publicly disclosed. It is a logic flaw in the kernel's cryptographic API that lets any local user, including any low-privilege account on a shared hosting server, escalate to root in seconds. The bug has existed quietly in every major Linux distribution since 2017. A working proof-of-concept exploit is publicly available, fits in 732 bytes of Python, and works without modification on Ubuntu, AlmaLinux, Rocky, Debian, and most cloud Linux images.

If you are a Gotekky managed server customer, this vulnerability has been mitigated centrally on your server. You do not need to take action. The rest of this guide explains what the bug is, why it matters, what we did about it, and what you should do if you also operate self-managed Linux servers elsewhere.

What Copy Fail actually is, in plain language

The Linux kernel has a feature called the userspace crypto API that lets normal programs ask the kernel to perform cryptographic operations on their behalf. It is used by some VPN software, some IPsec tools, and a few other niche applications. A 2017 optimization to one specific corner of that API, the part that handles a wrapper called authencesn, accidentally introduced a flaw: when a user-controlled cryptographic operation fails in a particular way, the kernel writes 4 attacker-controlled bytes into the in-memory copy of any file the attacker can read.

That sounds limited. It is not. The Linux kernel keeps recently-used files in memory for performance, including the executable code of programs like sudo and su. By writing 4 carefully chosen bytes into the in-memory copy of a privileged binary like /usr/bin/su, an attacker temporarily replaces a small piece of its code. The next time anyone runs su, the modified version executes and grants the attacker root. The disk file is never modified, so file integrity monitors like AIDE and Tripwire see nothing wrong. A reboot reverts the change because memory is cleared.

The bug was discovered by the offensive security firm Theori using an AI-assisted code scanner. Reportedly the scan took about an hour. That detail matters: this kind of vulnerability discovery is becoming faster and cheaper, which means more bugs of this class will surface in the coming months and years.

Who is actually at risk

Copy Fail is a local-only vulnerability. It cannot be exploited over the network on its own. To use it, an attacker needs to already be able to run code on your server as some user. That sounds like a high bar but it is not, because there are many ways to land in that position:

• You run shared hosting and a paying customer wants to escalate to root
• One of your customers' websites was compromised through a vulnerable plugin and the attacker has PHP code execution as that customer's user
• You operate a VPS where multiple developers have shell access and one developer's laptop is compromised
• You run a CI/CD system that executes pull-request code from contributors
• You operate Kubernetes nodes that share a kernel between containers

For Canadian hosting customers running a single small business website on a managed VPS or shared hosting plan, where you are the only user of the server, the risk profile is much lower. There is no realistic path for an attacker to reach the local-execution stage on a hardened, monitored, single-tenant managed server. The risk is concentrated in shared environments and any system where untrusted code already runs.

What Gotekky has done about it on managed servers

Within hours of the disclosure, we deployed the recommended kernel module mitigation across every managed server in our Toronto infrastructure. The fix is to disable the algif_aead kernel module, which is the entry point the exploit needs and which no production hosting workload requires. The mitigation is persistent across reboots, has no measurable performance impact, and breaks no application we have ever seen on a hosting server. Once distribution-supplied kernel patches arrive (Ubuntu has already shipped some, AlmaLinux and Debian are rolling out, others are imminent), we will apply those during routine maintenance windows and the module mitigation becomes redundant but harmless.

Customers on Gotekky managed plans do not need to do anything. We have already verified the mitigation on every server we manage. If you want to confirm on your own server, our support team can walk you through the verification steps.

If you also run self-managed Linux servers, do this today

The interim fix is straightforward and works on every modern Linux distribution. As root, run:

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

This blacklists the vulnerable module persistently. To verify it cannot be loaded:

modprobe algif_aead && echo "STILL LOADABLE" || echo "BLOCKED"

Output should be BLOCKED. Almost no real-world workload uses algif_aead. Disk encryption (LUKS, dm-crypt), TLS (kTLS, OpenSSL, GnuTLS), SSH, IPsec, and Kubernetes networking are all unaffected. The only applications that could be affected are some software explicitly bound to OpenSSL's afalg engine, which is rare. You can audit existing AF_ALG socket usage with lsof | grep AF_ALG before applying the change if you want to be cautious.

After applying the workaround, watch your distribution's security advisory feed and apply the kernel update when it ships. The relevant trackers are the Ubuntu Security Notices, the Debian security tracker page for CVE-2026-31431, the Red Hat customer portal CVE database, and your distribution's standard update channel. Once you have a patched kernel installed and the system rebooted, the modprobe blacklist becomes optional, though leaving it in place is harmless.

What this means for shared hosting and multi-tenant servers specifically

If you operate a cPanel, Webuzo, Plesk, or DirectAdmin server with multiple customer accounts, Copy Fail is genuinely high-priority. The threat model is exact: any one of your customers, or any successful PHP exploit against any one of their sites, becomes a candidate for taking over the entire server. Apply the modprobe blacklist now. Do not wait for the kernel patch. The blacklist takes 30 seconds to deploy and a reboot is not required for it to take effect.

Apply the same logic to any CI/CD runner, any Kubernetes node, any developer shell server, and any container host where untrusted or semi-trusted code runs. AWS Lambda, Fargate, and Cloudflare Workers are not affected because they run on per-tenant microVMs or isolates rather than a shared kernel. Standard EC2, GCE, and Azure VMs running Linux are affected.

An update: Dirty Frag is the second-stage problem

A week after Copy Fail, security researcher Hyunwoo Kim disclosed a related family of vulnerabilities collectively named Dirty Frag (CVE-2026-43284 in the IPsec ESP subsystem and CVE-2026-43500 in the rxrpc module). Dirty Frag affects every major Linux distribution including Ubuntu, Red Hat Enterprise Linux, AlmaLinux, Rocky, Fedora, Debian, and openSUSE. It produces the same outcome as Copy Fail (instant local privilege escalation to root) but through a different code path, and critically, the algif_aead module mitigation that protects against Copy Fail does not protect against Dirty Frag. They are separate problems requiring separate fixes.

Gotekky has published a dedicated guide on Dirty Frag covering the full distribution coverage, the mitigation steps for both CVEs, the interactions with IPsec VPN and AFS workloads (which the Dirty Frag mitigation can affect), and the patched kernel versions as they ship. If you have applied the Copy Fail mitigation from this guide, that protection remains valid, but it does not cover Dirty Frag. Read the Dirty Frag guide as the immediate next step.

The bigger pattern

Copy Fail is not isolated. It coincided this week with CVE-2026-41940, a critical authentication bypass in cPanel and WHM that has been actively exploited in the wild since late February. Together, the two vulnerabilities form a complete chain: an attacker can take over a cPanel server remotely with no credentials, drop into an unprivileged shell, and immediately escalate to host root using Copy Fail. If you have not yet patched cPanel as well, that is the more urgent of the two issues. We have published a separate guide on CVE-2026-41940 covering the cPanel side.

The lesson worth taking from this week is that the standard pattern of shared-kernel multi-tenancy plus a single internet-facing control daemon is being aggressively probed by both researchers and attackers, and the patch cadence for self-managed servers is no longer enough on its own. Defense in depth (kernel hardening, prompt patching, monitoring, isolation between customer accounts, restricted shell access) matters now in ways it did not five years ago. If you are running infrastructure that you have not seriously security-reviewed in a while, this is a good week to start.