The AI-Surfaced Linux Kernel Vulnerability “Copy Fail”: CVE-2026-31431 Impact and Response Guide¶

For / Key Points

For: Engineers, SREs, IT administrators, and security teams operating Linux servers, Kubernetes nodes, container hosts, CI runners, shared development servers, jump hosts, notebooks, or sandbox platforms.

Key Points:

CVE-2026-31431 “Copy Fail” is a High local privilege escalation issue, not a Critical remote code execution issue
Kubernetes nodes, CI runners, sandboxes, and shared hosts deserve the fastest review because low-privilege code execution is normal there
The durable fix is a patched kernel plus reboot; interim controls include disabling algif_aead and restricting AF_ALG

If low-privilege code runs on your Kubernetes nodes or self-hosted CI runners, CVE-2026-31431 belongs near the top of your Linux patch review queue.

The vulnerability, known as Copy Fail, is a Linux kernel local privilege escalation issue involving the crypto/ subsystem, AF_ALG, splice(), and the page cache. According to Theori / Xint, Xint Code surfaced the candidate finding after about an hour of scanning the Linux crypto/ subsystem¹².

That does not mean AI independently “hacked the Linux kernel.” Xint’s write-up says the work started from a human researcher’s understanding of the interaction between the Linux crypto subsystem and page-cache-backed data².

The operational question is simple: which Linux hosts can run untrusted low-privilege code, and have they rebooted into a fixed kernel?

This Is Not a Critical RCE, but That Is Not the Point¶

CVE-2026-31431 is not a vulnerability that gives an attacker direct remote entry over the internet.

As of April 30, 2026, NVD marks the record as “Awaiting Enrichment,” but it shows the kernel.org CNA CVSS 3.1 score as 7.8 High. The vector is AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, meaning local attack vector, low privileges required, no user interaction, and high impact to confidentiality, integrity, and availability³.

The practical interpretation is:

An attacker who can already run low-privilege code on a Linux host may be able to escalate to root.

So the first question is not merely whether you run Linux. The sharper question is whether untrusted low-privilege code can run on that Linux host.

Scope the Exposure with Three Questions¶

The object to inspect is the running host kernel, not the application package or container base image.

For Kubernetes, inspect the worker node kernel, not the Pod image. For CI, inspect the runner host, not only the job container. Start with:

cat /etc/os-release
uname -r

Do not make the final decision from uname -r alone. Distributions often backport security fixes without changing the upstream-looking kernel version in an obvious way.

Question	What to Check	Higher-Priority Examples
Is it a Linux host?	The running kernel	Linux VMs, physical servers, Kubernetes worker nodes
Can low-privilege code run there?	Users, CI jobs, Pods, user-supplied code	Shared dev servers, CI runners, notebooks, sandboxes
Has it rebooted into a fixed kernel?	Vendor advisory plus running kernel	Installed-but-not-booted kernels are not enough

For kernel updates, installation is usually not the finish line. The host must normally reboot into the fixed kernel before the fix is active.

P1 Means Kubernetes, CI, Sandboxes, and Shared Hosts¶

The highest-priority systems are hosts where low-privilege execution is part of normal operations.

Xint describes Copy Fail as giving an unprivileged local user a controlled 4-byte page-cache write primitive, which can be chained through a setuid binary to gain root². The dangerous part is that the modification happens in the page cache rather than as an ordinary on-disk file edit².

Priority	Environment	Why It Matters
P1	Kubernetes nodes / container hosts	Pods and containers share the host kernel
P1	Self-hosted CI runners / Jenkins agents	PRs and build scripts are an entry point for code execution
P1	Notebooks / AI sandboxes	User code is the workload, especially in multi-tenant setups
P1	Shared dev servers / jump hosts	A normal user or stolen credential can become the starting point
P2	Web / app / build servers	The issue becomes more serious when chained with RCE or credential theft
P3	Admin-only internal VMs / single-user test VMs	The local-execution precondition is harder to satisfy

The copy.fail guidance recommends blocking AF_ALG socket creation with seccomp for untrusted workloads such as containers, sandboxes, and CI, regardless of patch state¹.

Public Status as of April 30, 2026¶

Vendor state can change quickly. This section reflects public information checked on April 30, 2026.

NVD describes the issue in crypto: algif_aead, with the fix reverting algif_aead away from in-place operation³. The oss-security thread says the issue was introduced in Linux 4.14 by commit 72548b093ee3. It also lists fixed kernel commits for 6.18.22, 6.19.12, and 7.0⁴.

Source	Key Point on 2026-04-30
Linux kernel / oss-security	Introduced in 4.14, fixed commits listed for 6.18.22 / 6.19.12 / 7.0
Ubuntu	Priority High, reason “Trivial local privilege escalation,” CVSS 7.8 High⁶
Debian	bullseye / bookworm / trixie shown vulnerable; forky / sid shown fixed⁷
Amazon Linux	Multiple Amazon Linux 2 / 2023 kernel packages shown as Pending Fix⁸
SUSE / openSUSE	Many SLES, SUSE Linux Micro, and openSUSE Leap packages shown Affected⁹

Xint / Theori state that they verified root on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16 combinations¹². Treat that as researcher validation, not as a substitute for each vendor’s fixed or vulnerable package status.

Response Order: Patch, Reboot, Then Interim Restrictions¶

The durable fix is to update to a distribution-provided fixed kernel and reboot into that kernel.

On Debian / Ubuntu systems, check the running kernel and installed kernel images:

uname -r
dpkg -l | grep linux-image

On RHEL / Amazon Linux / SUSE-style systems, check RPM packages and the running kernel:

rpm -q kernel
uname -r

If you cannot update or reboot immediately, consider disabling the algif_aead module as an interim mitigation. The oss-security thread lists the same mitigation approach⁴.

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

This is not a universal fix. If the functionality is built into the kernel, it may not be removable as a module. If it is already in use, rmmod may fail.

For platforms that run untrusted workloads, consider restricting AF_ALG socket creation in addition to applying the fixed kernel. copy.fail recommends blocking AF_ALG with seccomp for containers, sandboxes, and CI regardless of patch state¹.

What Did AI Actually Do?¶

Copy Fail matters technically, but the discovery process is also part of the story.

The official copy.fail page says Copy Fail was surfaced by Xint Code after about an hour of scan time against the Linux crypto/ subsystem¹. Xint’s write-up says the operator prompt included the observation that splice() can deliver page-cache references of read-only files, including setuid binaries, to crypto TX scatterlists².

Calling this “AI independently found a zero-day” is too loose. Calling AI irrelevant is also too weak.

A more accurate reading is: a human researcher identified the attack surface, and AI helped traverse complex kernel code paths to surface a high-severity vulnerability candidate.

Bugcrowd’s David Brumley framed the point as “The bug matters. The way it was found matters more,” emphasizing that an AI system surfaced this class of Linux LPE in about an hour⁵.

Not Critical Does Not Mean Low Risk¶

CVE-2026-31431 is not a classic Critical RCE. The attack vector is local, low-privilege execution is required, and the CVE alone does not provide remote entry.

But Kubernetes nodes, CI runners, sandboxes, notebooks, and shared servers are different. On those systems, low-privilege code execution is not an edge case. It is part of the service model.

Risk = vulnerable kernel × likelihood of low-privilege execution × host-impact radius

With that lens, a self-hosted runner that executes PR code deserves attention before a single-purpose DB VM with no general user access.

The Larger Lesson Is Fast Asset Triage¶

Copy Fail is a Linux kernel vulnerability response problem. It is also a preview of AI-era vulnerability operations.

If AI expands the speed and scope of vulnerability discovery, defenders need faster impact scoping. The required inventory is concrete: host list, running kernel, distribution, Kubernetes node status, CI runner status, shared-login status, and whether the host has rebooted into a fixed kernel.

When that information is scattered, teams lose time before the real remediation even starts.

For Copy Fail, start by listing Linux hosts, prioritizing hosts that run low-privilege or untrusted code, and checking vendor CVE pages for fixed / vulnerable state. Then update to a fixed kernel and reboot. If immediate update is impossible, evaluate algif_aead disablement, and for CI / Kubernetes / sandbox platforms, evaluate AF_ALG restrictions.

AI may make vulnerability discovery faster. Operations needs to make exposure judgment faster too.

Summary¶

CVE-2026-31431 “Copy Fail” is a High Linux kernel local privilege escalation vulnerability. It is not a Critical RCE, but it is high priority for Kubernetes nodes, CI runners, sandboxes, and shared hosts.

The response path is inventory Linux hosts, check vendor advisories, update to a fixed kernel, and reboot into that kernel. Where immediate update is difficult, evaluate algif_aead disablement and AF_ALG restrictions as interim controls.