September 2, 2026
Updated: September 2, 2026
A defender's guide to Copy Fail exposure, affected Linux kernels, KEV status, cloud and container risk, patch verification, detection, and response.
Mohammed Khalil
CVE-2026-31431, nicknamed Copy Fail, is a Linux kernel vulnerability that can turn low-privileged local code execution into root access. That first condition matters: the flaw is not a stand-alone remote exploit. The urgency comes from how often attackers already obtain a limited shell, run code in a CI job, or compromise a container before looking for a reliable privilege-escalation path.
The operational question is therefore not simply, “Does this server run Linux?” It is, “Does an affected running kernel expose the vulnerable path to untrusted code, and what could root on this host reach?” Answering that requires package evidence, workload context, kernel verification, and response planning not a version string copied from a generic scanner.
CVE-2026-31431, or Copy Fail, is a high-severity Linux kernel flaw in the algif_aead path of the AF_ALG userspace crypto interface. A low-privileged local attacker can abuse incorrect in-place handling to corrupt page-cache data and escalate to root. It is not remotely exploitable by itself, but it can amplify a shell, CI job, or container foothold. CISA added it to the Known Exploited Vulnerabilities catalog. Defenders should apply vendor kernel updates, confirm the patched kernel is running, prioritize shared compute, and investigate credible root-compromise signals.
CVE-2026-31431 is a vulnerability in Linux's cryptographic userspace interface, specifically the algif_aead path associated with authenticated encryption. It became known publicly as Copy Fail. The issue traces to an optimization that attempted to perform cryptographic work in place even though the source and destination came from different mappings.
The official Linux CNA record describes the resolution as mostly reverting that in-place behavior while retaining direct copying of associated data. The record identifies relevant files in the kernel crypto subsystem and maps fixes across supported stable branches.
| Field | Current authoritative value |
|---|---|
| CVE | CVE-2026-31431 |
| Nickname | Copy Fail |
| Product | Linux kernel |
| Component | AF_ALG userspace crypto API, algif_aead path |
| Vulnerability class | Local privilege escalation caused by incorrect in-place handling and resource transfer |
| CVSS v3.1 | 7.8 High |
| Vector | AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| Required foothold | Local code execution as a low-privileged user or process |
| Potential result | Root privileges and full host confidentiality, integrity, and availability impact |
| CISA KEV | Added May 1, 2026 |
| Public exploit | Publicly available; not reproduced or linked here |
The CVSS vector is useful, but it is not a deployment priority by itself. A mature vulnerability-management program joins technical severity with exploitation evidence, asset criticality, reachability, compensating controls, and business impact.
No not in isolation. The vulnerable operation requires an attacker-controlled process to execute locally with low privileges. A remote scanner cannot simply send a packet to an exposed port and receive root access through this CVE.
That distinction should prevent inaccurate “remote root” headlines, but it should not create false comfort. A web application flaw, stolen SSH credential, malicious build step, compromised developer tool, or containerized service can provide the local execution that Copy Fail requires. In that chain, the remote foothold is the first step and the kernel flaw is the privilege-escalation step.
Microsoft's technical assessment describes the prerequisite as code execution from an unprivileged user and explicitly states that the flaw is not remotely exploitable by itself. It also highlights cloud, CI/CD, and Kubernetes contexts where untrusted code and shared kernels make the escalation path important.
This is why teams should model the whole attack path. A good zero-day and exploit guide separates initial access, execution, privilege escalation, persistence, and impact instead of labeling every stage with the most dramatic outcome.
Linux exposes cryptographic operations to userspace through AF_ALG sockets. In the vulnerable path, algif_aead attempted to reuse input memory as output during an authenticated-encryption operation. That decision was unsafe because the source and destination could represent different mappings.
Public research showed that the interaction could be abused to create a small, controlled change in the page cache of a readable file. The important defensive concept is not the payload or the target file. It is the boundary failure: data that should have remained read-only from an unprivileged process became writable in memory through a kernel-mediated crypto path.
The page cache holds in-memory representations of file data. Corrupting that cached representation can affect what another process executes or reads without producing the ordinary on-disk modification defenders expect. That makes simple file-hash checks incomplete as an investigation method. It does not make exploitation invisible: process, kernel, identity, container, and follow-on behavior can still provide evidence.
The original Xint Code disclosure documents the research history, affected mechanism, and coordinated disclosure. This article intentionally excludes the proof-of-concept code, target selection, triggering sequence, and exploitation instructions.
Public reporting describes the exploit path as deterministic rather than dependent on a narrow race condition. That can improve reliability for an attacker after local execution is obtained. It does not remove environmental prerequisites: the kernel and vendor package must be affected, the relevant functionality must be available, and the process must reach the host kernel path.
Root can read secrets, alter services, tamper with logs, access workload credentials, change startup behavior, and pivot into connected systems according to the host's permissions. Once credible evidence points to successful root escalation, the problem is no longer “one missing kernel patch.” It is a potential host compromise requiring the broader logic in an incident response plan.
CISA added CVE-2026-31431 to the Known Exploited Vulnerabilities catalog on May 1, 2026, with a federal remediation due date of May 15, 2026. The catalog entry identifies ransomware-campaign use as unknown. The deadline applied to U.S. federal civilian agencies under the relevant directive; private organizations can use KEV status as a strong prioritization signal.
KEV inclusion means CISA's evidence threshold for known exploitation was met. It does not, by itself, identify the actor, victim count, geography, industry, exploit chain, or scale of activity. Microsoft said on May 1 that its observed activity was limited and largely preliminary testing. Those statements can coexist: exploitation was known, while the publicly documented scope remained limited.
Defenders should keep three facts separate:
This distinction improves both urgency and credibility. The correct decision is to patch and verify quickly especially on reachable shared compute without inventing a global campaign that the evidence does not support.
The Linux CNA maps the vulnerable lineage from the introducing change and lists fixed points for maintained upstream branches. The following table is an upstream reference, not a distribution package decision table.
| Upstream branch | First fixed version listed by the Linux CNA |
|---|---|
| 5.10 | 5.10.254 |
| 5.15 | 5.15.204 |
| 6.1 | 6.1.170 |
| 6.6 | 6.6.137 |
| 6.12 | 6.12.85 |
| 6.18 | 6.18.22 |
| 6.19 | 6.19.12 |
| Mainline | 7.0 listed as unaffected through the original fix |
Do not compare `uname` output to that table and stop. Enterprise distributions routinely backport a security fix into a package whose visible base version looks older than the upstream fixed version. Kernel flavors for cloud, low-latency, OEM, hardware-enablement, and specialized images can also carry different status.
Ubuntu's current CVE status page lists the generic `linux` package as not affected on Ubuntu 26.04 LTS and fixed at 6.17.0-29.29 on 25.10, 6.8.0-117.117 on 24.04 LTS, and 5.15.0-179.189 on 22.04 LTS. Other kernel flavors have their own rows, so administrators must check the exact installed flavor.
| Ubuntu generic package example | Status shown September 2, 2026 |
|---|---|
| Ubuntu 26.04 LTS | Not affected |
| Ubuntu 25.10 | Fixed in 6.17.0-29.29 |
| Ubuntu 24.04 LTS | Fixed in 6.8.0-117.117 |
| Ubuntu 22.04 LTS | Fixed in 5.15.0-179.189 |
| Ubuntu 20.04 LTS | Fixed in 5.4.0-230.250 through Ubuntu Pro |
| Ubuntu 18.04 LTS | Fixed in 4.15.0-250.262 through Ubuntu Pro |
Red Hat marks its Copy Fail security bulletin resolved and says all fixes are available, while directing customers to the CVE page for the complete affected-product list. Red Hat also explains why a package-only scanner can produce false positives when it ignores backported fixes.
SUSE's CVE tracker reports the overall issue as resolved and rates it Important with CVSS 7.8. SUSE has many product and package combinations, so the exact product, service pack, kernel flavor, and advisory remain the authoritative unit of comparison.
AWS maintains an ongoing Copy.fail bulletin covering Amazon Linux, Bottlerocket, ECS, EKS, EMR, Fargate, machine images, and other services. It also separates the original algif_aead issue from later Copy.fail-family variants. Customers should use the latest service-specific state rather than an early May snapshot.
For each Linux asset or node pool, record:
This turns patch work into auditable evidence. The general process belongs inside a mature patch-management program, but the running-kernel and shared-node fields are especially important for Copy Fail.
Containers normally share the host's Linux kernel. A container image may contain an unaffected userspace package set while still executing system calls against a vulnerable node kernel. Conversely, an image scanner may flag a userspace package even when the actual host kernel has a vendor backport. The object that matters for CVE-2026-31431 is the running host kernel and its reachable crypto path.
A container foothold does not automatically equal a working escape. Kernel configuration, interface availability, security profiles, runtime policy, capabilities, namespace behavior, and provider controls can change reachability. The correct language is “possible container-to-host escalation under affected and reachable conditions,” not “every container can escape.”
Teams operating Kubernetes should map node images, kernel packages, pools, autoscaling groups, and workload trust levels. An authorized Kubernetes penetration-testing methodology can validate isolation and detection assumptions without deploying public kernel exploits into production.
Cloud responsibility also varies. A customer generally owns guest kernels on self-managed virtual machines. A provider may patch the host layer for a managed service, while the customer still must replace node images, restart workloads, or update a managed node group. Documenting that boundary is part of effective cloud security compliance, not a reason to assume the provider handled everything.
Use the following seven-stage chain to prioritize actual exposure. Stop only when evidence closes a stage; do not treat an unknown as a pass.
Start with the distribution or cloud vendor's current advisory for the exact release and flavor. Compare the installed package and the booted kernel. Record a vendor “not affected” or fixed state as evidence, not as a verbal assurance.
Determine whether AF_ALG, algif_aead, and the affected algorithm path are present and usable in the relevant build and runtime. Vendor configuration, built-in features, modules, or approved mitigations can change the answer. Avoid generic module checks that do not reflect built-in kernel code.
List every source: shell users, service accounts, CI jobs, plugins, notebook workloads, uploaded code, build scripts, developer tools, compromised applications, and containers. “No interactive login” is not equivalent to “no local execution.”
Map namespaces, runtime policy, seccomp, capabilities, managed-service boundaries, and node isolation. Confirm which host or node pool executes the workload. This is where image-only inventories frequently lose the relationship between a workload and its kernel.
Confirm the booted fixed kernel, the vendor-supported live-patch state, or the precise approved mitigation. Record exceptions, compatibility tests, and expiration. A closed change ticket without runtime proof is not sufficient.
Correlate crypto-interface activity, relevant data movement, privileged executable use, unexpected UID transitions, unusual process ancestry, container-to-host effects, security-control changes, and follow-on credential or service access. Test legitimate crypto and administration explanations before escalating.
If the host is only exposed, patch and verify. If an attempt is plausible but success is unproven, isolate high-value systems and deepen the investigation. If root compromise is credible, rebuild or replace the host from trusted artifacts, rotate exposed credentials, review connected systems, and validate recovery.
| Environment | Why reachability may be high | Initial priority | Primary action |
|---|---|---|---|
| Shared CI runner executing contributor or third-party jobs | Untrusted code already executes locally and may share a persistent host kernel | Urgent | Patch or replace runner hosts; separate trust tiers; review recent jobs and credentials |
| Kubernetes worker hosting internet-facing or untrusted workloads | A service foothold may reach the shared node kernel and affect other workloads | Urgent | Update or recycle nodes; verify pools and runtime controls; investigate suspicious workloads |
| Multi-user Linux server or research platform | Low-privileged users can execute code directly | Urgent | Patch and reboot; review local accounts, privileged transitions, and sensitive services |
| Internet-facing Linux server with no intended untrusted execution | Not directly remote, but application compromise can supply the prerequisite | High | Patch promptly; review application foothold paths and host telemetry |
| Developer workstation | Downloads, builds, plugins, and local tools create varied code-execution paths | High | Patch, reboot, and review high-risk development workflows |
| Single-purpose appliance with no shell and vendor-not-affected status | Exposure depends on vendor build and product access model | Vendor-directed | Preserve advisory evidence and follow the vendor lifecycle |
| Managed serverless or provider-operated compute | Provider may own the host kernel, but customer restart or image action can still apply | Service-specific | Verify the provider bulletin and customer action, then record evidence |
The matrix is a starting point, not an automatic score. Asset criticality, secrets, network position, tenant sharing, recovery time, and evidence of compromise can move a system up or down. Teams can use an authenticated VAPT process to validate reachability safely when inventory and configuration evidence remain ambiguous.
Use the distribution, cloud image, appliance, or managed-service advisory for the exact product. Do not install an arbitrary upstream kernel into a supported enterprise system merely to cross a version threshold. Preserve normal signing, testing, rollback, and availability controls while shortening the timeline for high-risk nodes.
For conventional hosts, install the update and reboot into the fixed kernel unless the vendor documents an effective live patch. For immutable or autoscaled infrastructure, replace instances or nodes from a patched image and prevent old images from launching. Confirm that orchestrators do not reschedule workloads back onto unremediated capacity.
Check the running kernel, package provenance, node image, and vendor advisory after the maintenance event. Re-scan with a vendor-aware tool that understands backports. Close the finding only when runtime evidence proves the vulnerable path is removed or vendor-approved mitigation is active.
Patch CI runners, Kubernetes workers, multi-user hosts, build systems, research platforms, and developer environments before isolated systems with no realistic local-execution path. A cloud penetration-testing service can validate control boundaries when performed with explicit authorization, provider alignment, and a safe test plan.
Vendor guidance may describe blocking AF_ALG initialization, the affected function, or the affected algorithm; restricting local access; enforcing mandatory access control; or limiting risky workload execution. These controls can affect legitimate cryptographic functions, may require boot changes, and differ by distribution. Follow the relevant vendor procedure, test compatibility, document residual risk, and attach an expiration date.
Network segmentation and access control help reduce initial footholds and lateral movement, but they do not patch a local kernel flaw. Running workloads as non-root is still valuable, yet the whole concern is that low privilege may be escalated. Treat these measures as layers, not substitutes for a fixed kernel.
The research and vendor response expanded into related kernel issues with different CVE identifiers and modules. Applying the CVE-2026-31431 fix does not automatically prove that every later Copy.fail-family issue is closed. Use each vendor's current consolidated bulletin and track every identifier as its own remediation object.
There is no single log line that proves Copy Fail exploitation. Detection is a correlation problem: identify a process that could reach the vulnerable kernel path, then join that event to an unexpected privilege transition and meaningful follow-on behavior.
| Signal | What it may indicate | Common legitimate explanation | Escalation evidence |
|---|---|---|---|
| Unusual AF_ALG activity from a web, CI, notebook, or container process | Access to the vulnerable crypto interface from an unexpected workload | Legitimate userspace crypto framework or benchmark | Related data-transfer behavior, suspicious ancestry, affected kernel, and later privilege change |
| Unexpected use of splice near crypto-socket activity | Part of a suspicious data path | High-performance file or network I/O | Same process tree, unusual readable-file access, and privileged execution shortly afterward |
| UID or effective-UID transition to root | Successful privilege escalation or legitimate setuid behavior | Normal authentication or administration | Untrusted parent, abnormal binary state, new service, credential access, or container-to-host effect |
| Privileged binary behavior inconsistent with on-disk hash | Possible page-cache manipulation | Update, package transaction, instrumentation, or memory fault | Affected kernel plus anomalous process history and root follow-on activity |
| Container workload influencing host processes or files | Isolation failure or kernel-level escalation | Authorized runtime, node agent, or privileged maintenance pod | Unprivileged workload origin, unexpected host namespace access, and new root activity |
| Security control, log, or service modification | Post-exploitation persistence or defense evasion | Approved administration or configuration management | Change outside maintenance, suspicious principal, credential use, or lateral movement |
Do not depend on file-on-disk hashes alone. The reported primitive affects the page cache, while successful root access can create separate persistence that survives after the transient cache state disappears. Rebooting may remove the cached modification, but it does not prove the attacker performed no follow-on action.
Continuous, authorized validation can test whether monitoring and node-replacement controls still work after changes. A continuous penetration-testing program should use safe emulation and control verification rather than deploying the public Copy Fail exploit against production systems.
Identify when the host first ran an affected kernel, when it received a fixed package, and when it actually booted or live-patched into a protected state. Join that window to users, workloads, containers, CI jobs, and application compromises that could execute local code.
Capture relevant runtime, process, kernel, container, CI, and cloud-control evidence before a reboot or node replacement when risk and operational policy permit. Coordinate with legal, privacy, and platform owners. Do not run untrusted public exploit code to “confirm” exposure on a potentially compromised production host.
Isolate affected high-value systems, stop untrusted workloads, drain or cordon relevant nodes, restrict runner assignments, and protect evidence. Review workload identity, instance metadata, service-account tokens, SSH material, package-signing keys, registry credentials, and secrets accessible from root.
If evidence shows exposure only, patching and runtime verification may be sufficient. If successful root escalation is credible, replace the node or rebuild the host from trusted artifacts. Patching the original system closes the flaw but cannot prove that persistence, users, services, keys, or logs remain trustworthy.
Review adjacent workloads, shared storage, registries, secrets managers, orchestration control planes, cloud APIs, and internal services reached from the host. Separate “root on one node” from “cluster compromise” and from “enterprise compromise”; confirm each with evidence.
Rotate credentials based on demonstrated or plausible access, prioritizing short-lived workload credentials, cloud instance roles, CI secrets, deployment keys, and administrative tokens. Revocation should accompany rotation where sessions or cached credentials may remain valid.
Return only patched, verified images or hosts to service. Confirm the booted kernel, monitoring coverage, runtime policies, workload isolation, and secret boundaries. Review why the initial foothold or untrusted execution was possible and test the corrected path.
DeepStrike's article on CVE-2025-61882 response illustrates the same general discipline: separate affected-version evidence, remediation, detection, and compromise response instead of treating a vendor patch as the entire incident decision.
The names sound related because each story involves Linux privilege boundaries and file-backed memory, but they are not interchangeable.
| Name | Identifier | High-level distinction |
|---|---|---|
| Copy Fail | CVE-2026-31431 | AF_ALG and algif_aead in-place handling can enable page-cache corruption and local root escalation |
| DirtyFrag / Copy.fail 2 | Includes later 2026 identifiers such as CVE-2026-43284 | Related research class involving other kernel modules and conditions; track separately through vendor bulletins |
| Dirty Pipe | CVE-2022-0847 | A pipe-related Linux kernel flaw enabled overwriting data in the page cache |
| Dirty COW | CVE-2016-5195 | A copy-on-write race condition enabled local privilege escalation |
The safest operational rule is identifier-first tracking. Nicknames help humans remember an issue, but CVE, product, package, kernel flavor, and vendor advisory determine remediation.
Copy Fail needs local low-privileged execution. If a remote application flaw supplies that access, record a chain of two or more weaknesses rather than changing the CVE's attack vector.
Local access is common in CI, development, research, multi-user, and container environments. A limited application foothold can also become local execution. Prioritize by reachability and blast radius.
Vendor backports can make an older-looking package safe, while a specialized kernel flavor can remain exposed after the generic package is fixed. Use the vendor's exact product table.
The container uses the node kernel. Join every workload to its actual host or managed-service responsibility boundary.
The old kernel can continue running until reboot. Immutable environments can also recreate nodes from an old image. Verify runtime state and launch controls.
KEV is a powerful known-exploitation signal. It does not disclose scale, campaign, actor, or victim count unless CISA or another source says so.
Kernel crypto functionality can be built in and support legitimate workloads. An incomplete block can fail silently; an overly broad block can create outages.
Root access can create persistence and expose credentials. Rebuild and rotate based on evidence and access, then validate the recovered environment.
CVE-2026-31431, called Copy Fail, is a Linux kernel local privilege-escalation vulnerability in the algif_aead path of the AF_ALG userspace crypto interface. Incorrect in-place handling can allow an unprivileged process to corrupt page-cache data and potentially gain root.
Not by itself. The attacker needs low-privileged local code execution. A remote application compromise, stolen shell, malicious CI job, or container foothold can supply that prerequisite, making the CVE valuable as the second stage of a larger attack chain.
The Linux CNA lists upstream fixes across multiple stable branches, but enterprise status depends on the distribution, release, kernel flavor, and vendor backport. Check the exact vendor advisory and compare both the installed package and the kernel currently running.
It may enable container-to-host escalation when an affected host kernel exposes the vulnerable path to the workload. Containers share the host kernel, but configuration, security policy, provider controls, and interface availability affect reachability. It is not a guaranteed escape from every container.
CISA added it to the Known Exploited Vulnerabilities catalog on May 1, 2026, and public exploit code exists. That supports urgent remediation. Public authoritative sources cited here do not establish indiscriminate mass exploitation or identify a single universal campaign.
Apply the current kernel update or patched image from the exact Linux distribution, cloud, appliance, or managed-service vendor. Reboot or replace the node when required, verify the fixed kernel is running, and prevent old images from returning. Use interim mitigations only under vendor guidance.
Correlate unusual access to the affected crypto path with relevant data movement, suspicious process ancestry, unexpected privileged execution or UID changes, container-to-host effects, and root follow-on behavior. Preserve kernel, process, container, CI, identity, package, boot, and cloud evidence. A file hash alone is not sufficient.
CVE-2026-31431 is a reminder that “local” describes an exploit prerequisite, not the business impact of the resulting root access. The right response joins vendor package truth, the kernel actually running, the ability of untrusted code to reach it, the host's blast radius, and credible evidence of compromise.
Patch quickly, but close the loop. Verify the running fix, prioritize shared compute, preserve evidence when exploitation is plausible, and rebuild when root trust can no longer be established. That is how a high-severity kernel CVE becomes a controlled engineering task instead of an open-ended incident.
Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us
