CVE-2026-31431 (Copy Fail): What the Linux Kernel Vulnerability Affects and How to Mitigate It

CVE-2026-31431 Copy Fail is a Linux kernel local privilege escalation issue that moved quickly from technical disclosure to operational priority. As of August 19, 2026, the official record shows a high-severity flaw in the algif_aead component, fixed kernel packages from every major Linux distributor, and inclusion in CISA's Known Exploited Vulnerabilities catalog since May 1, 2026. The picture has moved since disclosure: the temporary module-disabling mitigations published at the end of April were a stopgap, and vendors have since shipped fixed kernels and started retiring them.

This article stays narrow on purpose. It does not reproduce the exploit, estimate prevalence, or repeat third-party claims about reliability. It focuses only on what the official records currently support: what the vulnerability affects, where the exposure matters most, what temporary mitigations exist, and how to validate patch status without creating blind spots or operational regressions.

For the broader process of auditing isolated environments, see Air-Gapped Network Security Audit: How to Review Isolated Environments Without False Confidence. For a companion guide on offline-capable workflows and tooling, see What Security Tools Work in Isolated Networks Without Internet Access? A Practical Guide to Offline-Capable Security Workflows.

What Is CVE-2026-31431 (Copy Fail)?

CVE-2026-31431 is a Linux kernel vulnerability in algif_aead, a component tied to the kernel cryptographic interface. The NVD record inherits the upstream kernel description of the fix path: the vulnerable behavior is addressed by reverting algif_aead to out-of-place operation rather than the more complex in-place handling introduced earlier.

The official severity that matters most for defenders is the kernel CNA score of CVSS 3.1 7.8 HIGH, with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Red Hat and cve.org publish the same score and the same vector. NVD carries two weakness classifications from different contributors — CWE-669 (Incorrect Resource Transfer Between Spheres, the classification CISA also uses in KEV) and CWE-1288 (Improper Validation of Consistency within Input, from Red Hat) — and lists eight kernel.org patch references tied to stable branches.

On the version axis the upstream record is explicit. The regression was introduced by commit 72548b093ee3, so the CVE affects Linux 4.14 and later, with fixes landing in stable releases 5.10.254, 5.15.204, 6.1.170, 6.6.137, 6.12.85, 6.18.22 and 6.19.12. Distributions map that to their own package versions: Ubuntu states the issue affects every release before Resolute (26.04), and SUSE states it affects kernels 4.14 and newer, from SLES 12 SP5 through SLES 16.0, with SLES 11 too old to be affected.

Operationally, vendors are treating this as a local privilege escalation problem in the Linux kernel. That matters because local privilege escalation is not a purely academic boundary. If an attacker already has code execution as a normal user, or can run an untrusted workload in the wrong place, a reliable path to local root can change the trust boundary of a bastion, a shared host, or a container node very quickly.

What the Official Advisories Confirm So Far

The official picture is already clear enough to support immediate triage.

A second operational signal is the KEV status. NVD explicitly notes that this CVE is in CISA's Known Exploited Vulnerabilities Catalog, with Date Added: May 1, 2026 and Due Date: May 15, 2026; the entry is still in the catalogue today. Even if your organization does not follow federal deadlines, that is still a useful prioritization input: the vulnerability is no longer just "new" or "interesting". It is already in the class of issues that defenders should treat as urgent.

That listing is not speculative. Red Hat's bulletin publishes a remediation timeline stating that the reporter released a blog post, technical write-up and proof-of-concept on April 29, 2026, that a Metasploit module was published the same day, and that CISA added the CVE to KEV two days later. Ubuntu confirms the published exploit targets deployments without container workloads. This article does not reproduce any of it — but a working public exploit is a triage input, and it explains why the vendor timelines compressed the way they did.

Where Copy Fail Matters Most

This is not a remote unauthenticated edge-service bug. The exposure depends on the presence of a local foothold or an execution path on a Linux system. That still leaves several high-value scenarios.

Hosts with local users or local code execution

Ubuntu states that on deployments without container workloads, the vulnerability allows a local user to elevate privileges to root. That means the first question is not "Is my internet-facing service directly exploitable from outside?" The first question is whether the host can already execute untrusted or semi-trusted code under a low-privilege account.

Typical examples include:

• shared administrative Linux hosts
• bastions or jump systems used across teams
• CI runners and build systems
• multi-user servers with shell access
• management servers adjacent to identity infrastructure

Containerized environments

Ubuntu also documents a separate concern for container deployments that may execute potentially malicious workloads: the vulnerability may facilitate container escape scenarios. Red Hat's RHSB-2026-002 bulletin carries separate product-specific mitigation sections for OpenShift 4 and for managed OpenShift (ROSA Classic, ROSA HCP, ARO and OpenShift Dedicated), which confirms the vendor treats container platforms as their own operational track. SUSE makes the same distinction from the other side: Rancher Prime, RKE2 and K3s are not directly affected, but privileged containers running untrusted workloads can still be used to reach the kernel flaw, so SUSE points at Pod Security Admission and equivalent controls rather than at a product patch.

That distinction matters. A fleet team should not write "container escape" as a blanket claim across every Kubernetes or container deployment. The correct statement is narrower: vendor guidance says containerized environments deserve separate attention, and container-node triage should not be mixed into simple workstation or server patch queues.

Administrative and identity-adjacent systems

Even though this is a Linux kernel issue rather than an Active Directory or Entra issue, local root on the wrong Linux host still matters to identity and infrastructure teams. Bastions, provisioning nodes, automation runners, VPN appliances, PAM jump hosts, and Linux systems used to administer Windows or cloud infrastructure are part of the effective identity plane. A local privilege escalation there can change the trust model around credentials, tokens, management keys, and automation paths.

That is also why teams that already run Audit Active Directory Security: What to Review First and How to Prove Remediation or Hardening Active Directory: What to Lock Down First and How to Validate It should not treat Linux administrative hosts as outside the scope of identity assurance. If your administrative paths already drift over time, the same operational pattern described in Privileged Access Drift Active Directory: How Admin Rights Creep Back After Audits usually applies to bastions and adjacent Linux tooling as well.

Temporary Mitigations and Their Tradeoffs

The temporary mitigation story is important because the official vendor guidance does not describe it as a neutral toggle.

At disclosure, the Ubuntu Security Team released a mitigation that disables the affected algif_aead module through the kmod package. Ubuntu has since updated that advisory: fixed kernel packages are now available and the kmod mitigation will be reverted, so module blocking is a fallback for hosts that cannot take the kernel update yet, not the destination. SUSE documents an equivalent modprobe workaround (blacklist algif_aead plus install algif_aead /bin/false) and has released updates for all maintained SUSE Linux Enterprise and openSUSE Leap distributions.

Red Hat is the exception worth knowing about. On RHEL the affected code is built into the kernel and cannot be blocklisted as a module, so the documented stopgap is a boot argument — initcall_blacklist=algif_aead_init, or initcall_blacklist=af_alg_init to block the AF_ALG interface entirely — with an explicit warning about performance impact on anything using kernel cryptographic functions. A modprobe rule copied from a Debian or SUSE runbook will do nothing there.

Each of these buys time, and each comes with tradeoffs.

The mitigation is not behavior-free

Ubuntu explicitly warns that the mitigation disables a module used for hardware-accelerated cryptography. The expected behavior is fallback to userspace cryptographic functions, but Ubuntu also notes that some applications may not handle this gracefully. In addition, already running applications may be affected if the module is disabled or unloaded, and a reboot may be needed to force fallback behavior consistently.

That means the mitigation decision should be treated like a real operational change, not a harmless emergency flag.

The practical rule is simple: if you use the workaround, document that it is temporary, validate crypto-dependent applications, and confirm the system later reaches a fixed kernel state instead of staying indefinitely on a workaround path. Since the fixed kernels are out, any host still sitting on a workaround in August 2026 is carrying an unfinished remediation, not a mitigation.

How to Check Exposure and Patch State

The safest check sequence is vendor-first. Do not assume that a generic kernel version headline from social media is enough to determine whether a fleet is exposed.

Ubuntu checks

Ubuntu provides concrete commands in its advisory:

uname -r

dpkg -l 'linux-image*' | grep ^ii

dpkg -l kmod

Ubuntu also documents how to verify whether the affected module is still loaded:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Those checks are useful even beyond Ubuntu because they reflect the right logic: check the running kernel, check installed packages, and check the module state separately.

Ubuntu's advisory also carries a per-release table of fixed linux and kmod versions, so the output above should be compared against that table rather than against a generic kernel version headline. Ubuntu's own remediation is sudo apt update && sudo apt upgrade followed by a reboot; unattended-upgrades pulls the packages within 24 hours on 16.04 LTS and later, but the reboot is still required.

SUSE checks

SUSE exposes a public CVE page with product/package state and released fixed package versions. For SUSE-managed environments, the authoritative path is to compare the installed kernel-related packages against the versions listed on the CVE page and any linked advisory entries, rather than relying on a generic distro-family statement.

Red Hat checks

Red Hat's bulletin RHSB-2026-002 is now marked Resolved and states that all fixes are available. Two Red Hat pages are genuinely public and carry the authoritative product state: the bulletin itself, and the Red Hat CVE page for CVE-2026-31431, which lists the affected products, the released errata, Red Hat's own Important rating, and its CWE assignment. The RHEL, OpenShift 4 and ROSA/OpenShift Dedicated how-to articles linked from those pages are subscriber-exclusive content, so an engineer sent to them needs a Red Hat account before the link is useful.

What to record during triage

For each system or cluster group, record at least:

• current running kernel version
• installed kernel package version
• whether algif_aead is loaded
• whether a temporary mitigation has been applied
• vendor advisory state for that product line
• whether a reboot is still pending after patch or mitigation

That is enough to turn a noisy vulnerability headline into a real remediation queue. If you already run recurring infrastructure reviews, the same evidence discipline described in Recurring AD Audit Workflow: Why Annual Audits Drift and How Continuous Posture Monitoring Works applies here: capture the state, rerun after remediation, and keep proof that the temporary mitigation was actually retired.

What to Validate After Applying Fixes

A Copy Fail response should not end at "package updated". The validation step is where temporary mitigations, pending reboots, and partial rollouts usually hide.

The key operational mistake would be to treat the workaround as identical to a fully validated fix. The vendor guidance does not support that. The workaround buys time; the fixed kernel and post-change validation close the loop. For logging and escalation visibility around adjacent identity systems, pair this with Active Directory Monitoring: Security Event IDs That Matter when the affected Linux host sits on an administrative path or feeds a broader incident review.

Why This CVE Still Matters to Identity and Infrastructure Teams

Copy Fail does not belong to EtcSec's AD/Azure vulnerability catalogue, and this article should not pretend otherwise. But it still matters to identity and infrastructure teams because local root on the wrong Linux system changes more than one host.

Examples include:

• bastions used to administer Windows or cloud infrastructure
• Linux nodes that hold automation credentials or configuration secrets
• OpenShift or container nodes adjacent to internal trust boundaries
• jump systems in segmented or air-gapped environments

That is the right reason to cover the CVE here. Not because it maps neatly to the existing catalogue, but because infrastructure trust, administrative paths, and remediation evidence still matter when the affected system sits close to the identity plane.

Primary References

• NVD: CVE-2026-31431
• Ubuntu: Fixes available for CVE-2026-31431 (Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability
• SUSE: SUSE responds to the copy.fail vulnerability
• SUSE CVE page: CVE-2026-31431
• Red Hat Security Bulletin RHSB-2026-002: Cryptographic Subsystem Privilege Escalation - Linux Kernel (CVE-2026-31431) - Copy Fail
• Red Hat CVE database: CVE-2026-31431
• Red Hat: Is my RHEL system vulnerable to the Copy Fail (CVE-2026-31431) flaw? (subscription required)
• Red Hat: How to mitigate the Copy Fail CVE-2026-31431 in OpenShift 4 (subscription required)
• Red Hat: Mitigation and Remediation for CVE-2026-31431 ("Copy Fail") in ROSA Classic and OpenShift Dedicated (subscription required)
• kernel.org patch references listed in NVD
• CISA Known Exploited Vulnerabilities Catalog entry for CVE-2026-31431

All references above were re-fetched and confirmed on August 19, 2026.