Executive summary
The researchers behind Copy Fail disclosed CVE-2026-31431 on 29 April 2026, describing a Linux kernel flaw that allows an unprivileged local user to obtain root access. CERT-EU recommends urgent attention to Kubernetes nodes and continuous integration and continuous delivery (CI/CD) workers running untrusted workloads. We assess it is likely (B2) that systems deliberately accepting other users’ code deserve priority over otherwise comparable single-user systems, because the reported flaw weakens the boundary that those services depend on. It does not itself provide remote entry into a machine.
Contextual background
The researchers’ disclosure timeline records notification to the Linux kernel security team on 23 March 2026, a mainline patch on 1 April 2026 and public disclosure on 29 April 2026. An upstream fix and an installed distribution fix are separate milestones. Administrators need to establish whether their running kernel contains the correction, rather than infer that a host is protected because the underlying change has already been published.
The researchers released a demonstration exploit and reported successful testing on four distributions. That establishes a reproducible technical problem within the stated test set. It does not establish a count of compromised organisations or an observed campaign against every affected system. This article treats public exploit availability as a reason to prioritise exposure assessment, without converting it into an unsupported claim of exploitation in the wild.
For organisations operating Linux infrastructure, our recommended starting point is the trust boundary. A build service can deliberately run unfamiliar code without granting that code administrative authority. A shared development host can give users accounts while expecting to keep their privileges separate. Copy Fail matters because local execution and root authority are supposed to remain different permissions in those environments.
Technical analysis
CERT-EU describes a flaw in algif_aead, part of the kernel’s userspace cryptographic interface, AF_ALG. An optimisation introduced in 2017 can place page-cache data into a destination that an unprivileged process can modify. The resulting controlled modification can be used to elevate privileges. The upstream correction reverses the problematic optimisation rather than relying on a change to an individual application.
The researchers describe a logic flaw rather than a race condition requiring repeated timing attempts. They also identify the shared page cache as relevant to container and tenant boundaries. The important operational distinction is that a container image’s package list does not, on its own, describe the host kernel that runs the workload. Our recommendation is to map each affected workload to its node and kernel before deciding that rebuilding an image resolves the exposure.
This is a local privilege-escalation issue. The researchers explicitly distinguish it from a vulnerability that grants remote access by itself. An attacker would still need a way to execute local code, whether through an authorised low-privilege account, an untrusted workload or a separate compromise. Do not invent an initial-access vector when investigating a suspicious elevation event; establish how the process arrived on that system.
Affected systems and version checks
The following combinations were directly tested in the researchers’ report and repeated by CERT-EU. They are examples of confirmed vulnerable configurations, not a complete distribution inventory.
| Distribution | Tested kernel |
|---|---|
| Ubuntu 24.04 LTS | 6.17.0-1007-aws |
| Amazon Linux 2023 | 6.18.8-9.213.amzn2023 |
| Red Hat Enterprise Linux 10.1 | 6.12.0-124.45.1.el10_1 |
| SUSE 16 | 6.12.0-160000.9-default |
Avoid turning the researchers’ broad description of kernels built since 2017 into an assertion that every current installation is vulnerable. CERT-EU explicitly identifies Ubuntu 26.04 as unaffected. Canonical’s tracker, updated on 30 April 2026, distinguishes kernel packages and release combinations, including vulnerable, unaffected and unavailable combinations. Distribution name alone is insufficient for a reliable decision.
Patch information was also changing quickly. CERT-EU’s 30 April 2026 table described pending fixes for several distributions, while the researcher page captured later on 30 April 2026 said major distributions were beginning to ship corrections. These statements should not be combined into a single universal patch-status claim. Use the vendor’s entry for the exact kernel package and retain the advisory revision supporting the decision.
Our recommended inventory records the distribution release, kernel flavour, running version, vendor support status and whether the relevant correction is active. Distinguish a package downloaded for the next maintenance window from a kernel already running with the fix. Where a vendor supports a different activation mechanism, follow that procedure and verify its state rather than applying a blanket assumption about reboot requirements.
Impact assessment
The researchers’ prioritisation places shared Linux hosts, container clusters, build farms and services executing tenant-supplied code among the most urgent environments. These systems intentionally accept workloads from users who should not control the host. The reported local privilege escalation therefore threatens a central security boundary even when the service is behaving as designed.
Our recommended triage considers both opportunity and consequence. Identify who can submit code, which credentials and data the host can reach, and whether other tenants share its kernel. A development runner with package-publishing rights may create a different downstream risk from an isolated worker with no persistent credentials. Record those rights from the actual deployment rather than treating every runner as equivalent.
Single-tenant systems still merit assessment. The researchers describe the vulnerability as a possible escalation step after another compromise or stolen access. Lower exposure to untrusted users changes prioritisation; it does not prove that the flaw cannot matter. Maintain a separate remediation queue for those systems instead of silently excluding them from the affected population.
Indicators and detection limitations
The available sources describe a vulnerability and demonstration exploit, not a named intrusion campaign with a stable set of attacker domains or network addresses. Our recommendation is to avoid presenting a demonstration file’s hash as a complete detection strategy. A different implementation of the same flaw would not need to preserve that file’s name or digest.
The researchers explain that the demonstrated page-cache modification does not survive a reboot, while the resulting root access is real. That distinction limits what a clean later file comparison can prove. It also means that rebooting a host cannot, by itself, establish that any activity performed with elevated privileges has been undone.
Our recommended hunt begins with unusual local execution and changes of privilege during the exposure interval, then follows the consequences: unexpected services, altered credentials, administrative changes or access to sensitive material. These are investigation questions derived from the impact, not specific artefacts reported from a Copy Fail campaign. Compare them with approved maintenance and workload activity before declaring compromise.
Preserve the limits of the telemetry. If process history or privileged-action logs are unavailable, say which questions remain unanswered. An absence of alerts from a control that does not observe the relevant behaviour is weaker evidence than a verified patch state or a tested restriction on the required interface.
Incident response guidance
Our recommended response separates vulnerable from compromised. For a vulnerable host without evidence of hostile execution, the immediate tasks are exposure control, vendor-directed remediation and verification. Where there is evidence of suspicious elevation, preserve relevant logs and volatile evidence under the organisation’s incident procedure before disruptive recovery actions erase useful context.
Investigate the entry path and the authority obtained. A kernel update closes the vulnerability but does not explain how an untrusted process reached the host. Review the accounts, submitted jobs, application access and administrative changes associated with the event. If the elevated process could reach service credentials, assess those credentials and their downstream activity as a separate recovery task.
For shared infrastructure, determine which workloads ran on the same node during the relevant period. Our recommendation is to use scheduling and build records to make that assessment rather than assume every workload across the entire cluster was exposed. Where those records are incomplete, retain a wider provisional scope and document why it cannot yet be narrowed.
Mitigation recommendations
CERT-EU recommends applying the appropriate vendor kernel update and using a temporary restriction on algif_aead where necessary. Its advisory describes preventing the module from loading and removing it from the running kernel where possible. Implement that mitigation through the organisation’s approved configuration process, then verify the effective state on the running host.
The advisory warns that applications explicitly using the AF_ALG interface may be affected. Our recommendation is to test those workloads and record any exception rather than assume a generic cryptography dependency makes the restriction impossible. Equally, a configuration file intended to prevent future loading is not sufficient evidence that the interface is unavailable now.
CERT-EU also recommends restricting AF_ALG socket creation through seccomp for containerised workloads and pipelines. Treat this as a workload policy that must actually be applied to the relevant processes. Review inherited and overridden security profiles, test legitimate jobs and verify that new workers receive the same control. A policy stored in a repository but omitted from the deployment does not reduce exposure.
For recovery verification, our recommendation is to retain the vendor advisory, the affected package identity, the effective patch or mitigation state and the test outcome. This makes the decision reviewable when a machine is reprovisioned or a temporary exception expires. It also helps prevent an older base image or node template from reintroducing the same exposure.
Our recommended exception process should identify the workload that prevents immediate mitigation, the compensating restriction on who may submit code, and the person responsible for retesting after the vendor update. Set a review point tied to patch availability. An exception described only as a production dependency gives the response team no way to tell whether the risk has reduced or whether the original constraint still applies.
Threat intelligence context and outlook
Our ATT&CK mapping is T1068: Exploitation for Privilege Escalation, based on the reported transition from unprivileged execution to root authority. This is a behavioural classification, not evidence of a particular actor, a remote intrusion technique or an observed campaign.
The immediate priority is a verified relationship between workloads and the kernels running them. Follow vendor revisions for the exact supported package, and reassess temporary restrictions as fixes become available. Keep vulnerability remediation and investigation of possible compromise distinct: both may be necessary, but they answer different questions and require different evidence.
