By NHI Mgmt Group Editorial TeamPublished 2026-05-04Domain: Breaches & IncidentsSource: Oligo Security

TL;DR: CVE-2026-31431 lets an unprivileged local user escalate to root on most major Linux distributions since 2017, and the attack can corrupt in-memory binaries while leaving disk checks clean, according to Oligo Security. Runtime verification, not file integrity alone, becomes the relevant control when local privilege escalation crosses container and host boundaries.


At a glance

What this is: Copy Fail is a Linux kernel local privilege escalation issue that can alter in-memory execution and evade disk-based integrity checks.

Why it matters: It matters because NHI and workload teams must treat shared hosts, containers, and CI runners as runtime-exposed attack surfaces, not just patch targets.

By the numbers:

👉 Read Oligo Security's analysis of Copy Fail and Linux runtime exposure


Context

Copy Fail is a local privilege escalation flaw in Linux that turns a low-signal starting point into root-level control. For IAM and NHI practitioners, the key issue is not only patching the kernel but understanding how runtime compromise can bypass file-based trust assumptions in shared environments.

In containerised infrastructure, an issue that starts on one workload can affect a shared node, especially when privileged containers and untrusted workloads coexist. That makes the problem broader than host hardening alone, because the same trust boundary often governs service accounts, workloads, and other non-human identities operating on the node.


Key questions

Q: How should teams respond to a local Linux privilege escalation flaw in shared environments?

A: Prioritise patching on shared nodes first, then reduce the number of workloads that can share privileged execution paths. In containerised environments, a local flaw can become node-level compromise if trust boundaries are too loose. Add runtime detections and treat the issue as both a kernel patching task and a workload governance problem.

Q: Why do file integrity tools miss attacks like Copy Fail?

A: Because the attack changes what runs in memory rather than what is stored on disk. Hash checks, file integrity monitoring, and disk scans all assume the file system is the source of truth. When execution is poisoned in cache or memory, those tools can report a clean file while the running code is already compromised.

Q: What is the difference between patching a host and governing the blast radius of a kernel flaw?

A: Patching removes the vulnerability, while blast-radius governance limits how far an exploited flaw can spread before remediation lands. In shared Linux environments, that means separating privileged and untrusted workloads, shrinking standing privilege, and instrumenting runtime detections. Both controls matter because a fast patch schedule alone does not control lateral impact.

Q: When should organisations treat runtime telemetry as a primary control?

A: When an exploit can evade artifact-based detection and alter execution without changing the underlying file. That is exactly the pattern with memory-based tampering, container pivoting, and other attacks that leave little disk evidence. Runtime telemetry becomes primary when the system of record for compromise is the process, not the file.


Technical breakdown

How AF_ALG and splice() enable in-memory binary tampering

The flaw sits in the Linux kernel's authencesn cryptographic template within AF_ALG. By chaining AF_ALG sockets with splice() system calls, an attacker can corrupt the page cache backing a setuid binary without altering the file on disk. That means the kernel may execute poisoned in-memory content while the on-disk binary still hashes cleanly. This breaks a common defender assumption: that disk integrity is a reliable proxy for execution integrity. The practical challenge is that traditional controls are built to inspect artifacts after execution, not the runtime path that determines what actually ran.

Practical implication: Treat runtime observation as mandatory when binaries can be modified in memory without changing the file on disk.

Why container sharing turns a local flaw into node-level risk

Copy Fail becomes more dangerous when containers share a base image or host resources with privileged containers on the same node. An unprivileged container can use the vulnerable kernel path to corrupt shared binaries and then pivot through a privileged container or directly into host execution. In Kubernetes, that means the boundary between one pod and the node can collapse if shared execution paths are trusted too broadly. The issue is not container isolation in theory, but whether the node's runtime and privilege model can tolerate a compromised workload without exposing adjacent systems.

Practical implication: Review whether shared nodes and privileged containers create an unnecessary escalation path for untrusted workloads.

Why file integrity monitoring misses this class of attack

File integrity monitoring and hash validation both depend on the disk being the source of truth. Copy Fail invalidates that model because the file on disk remains untouched while the in-memory version is altered at execution time. That leaves almost no forensic residue for scanners that rely on file changes, especially after the process exits. Defenders need telemetry that correlates kernel activity, unusual socket use, suspicious splice() behaviour, and privilege changes. This is a runtime integrity problem, not a storage integrity problem.

Practical implication: Add runtime detections that look for suspicious kernel and process behaviour instead of waiting for disk artefacts.


Threat narrative

Attacker objective: The attacker wants reliable root access on the affected system and, in shared environments, a path from one workload to broader node compromise.

  1. entry: An unprivileged local user or compromised container reaches the vulnerable AF_ALG path through normal Linux execution.
  2. escalation: The attacker chains AF_ALG sockets with splice() calls to poison the page cache of a setuid binary without changing the file on disk.
  3. impact: The poisoned binary executes attacker-controlled code, enabling root access and possible pivot from a container to the host.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Local privilege escalation is now a workload governance problem, not just a host patching problem. When a flaw can convert unprivileged execution into root and then cross a container boundary, the relevant control plane is broader than the kernel alone. IAM and NHI teams should treat shared nodes, service workloads, and privileged containers as part of one trust domain. The practical conclusion is that runtime privilege boundaries need governance, not just vulnerability scanning.

Runtime integrity is becoming the decisive control for NHI and workload security. Copy Fail shows why on-disk validation is no longer enough when trusted execution can be altered in memory. That weakens the value of file integrity checks as a sole control and strengthens the case for behavioural telemetry tied to execution paths. The practitioner takeaway is to instrument the runtime layer where compromise actually manifests.

Identity blast radius is the right concept for shared Linux infrastructure. A compromise that begins with one local user can affect multiple workloads when privileged containers, shared images, and host-level trust overlap. That is the same governance problem NHI teams face with over-privileged service accounts and persistent credentials: a single foothold can spread farther than intended. The practical conclusion is to reduce standing privilege and narrow trust adjacency wherever workloads share infrastructure.

Kernel-exploitable paths should be assessed alongside access governance, not separately from it. Security programmes often split exploit management from identity governance, but the operational reality is interconnected. If a workload can reach privileged execution through a local flaw, then identity scope, container placement, and host hardening all influence the final blast radius. The practical conclusion is to align patching, least privilege, and runtime detection into one control model.

From our research:

  • Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
  • Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
  • For a broader view of how attackers turn identity weaknesses into compromise, see 52 NHI Breaches Analysis, which maps recurring failure patterns across real incidents.

What this signals

Copy Fail reinforces the runtime integrity gap: defenders can no longer assume that a clean file equals a clean execution path. That is especially relevant for shared clusters where local compromise can escalate into node-level access, so programme owners should pair kernel patching with behavioural detections and workload isolation.

The operating model should shift from artifact inspection to execution verification. Teams that already track identity blast radius across service accounts and workloads should extend that discipline to the Linux runtime, because a single local foothold can still produce disproportionate identity and infrastructure impact.

As shared environments converge, runtime controls and identity controls need to be planned together rather than as separate workstreams. The security team that can connect host hardening, container privilege, and workload identity will be better positioned to absorb this class of flaw without widening exposure.


For practitioners

  • Prioritise patching on shared Linux nodes Move affected kernel versions on Kubernetes nodes, CI runners, and multi-tenant hosts ahead of lower-blast-radius systems. Treat any node running untrusted code or mixed-trust workloads as urgent remediation scope.
  • Reduce privilege adjacency in container platforms Review whether privileged containers share nodes with untrusted workloads, then separate those workloads or remove unnecessary privileged execution paths. The goal is to make a local compromise less able to pivot into host control.
  • Add runtime detections for kernel exploitation patterns Monitor for AF_ALG socket activity, suspicious splice() calls, and unexpected root shells, then correlate those signals with execution of trusted binaries. This catches attack behaviour that file integrity tools will miss.
  • Disable or restrict vulnerable kernel paths where patching lags If patch deployment is delayed, reduce exposure by disabling the vulnerable module or blocking AF_ALG socket creation through seccomp policies on systems that can tolerate the restriction.

Key takeaways

  • Copy Fail shows that a local Linux flaw can still become a root-level and node-level security event.
  • Disk-based integrity checks are insufficient when the attack changes in-memory execution instead of on-disk files.
  • Security teams should combine patching, privilege reduction, and runtime telemetry to shrink the blast radius of shared infrastructure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Credential and privilege reduction are central to limiting post-exploitation impact.
NIST CSF 2.0PR.AC-4Shared nodes need least-privilege enforcement across workloads and containers.
NIST Zero Trust (SP 800-207)Runtime verification aligns with continuous trust evaluation in zero trust environments.

Review standing privilege on service and workload identities, then remove persistent access where possible.


Key terms

  • Local Privilege Escalation: A local privilege escalation is a flaw that lets an attacker with existing access gain higher permissions on the same system. In Linux environments, that often means moving from a low-privilege account or container process to root, which can turn one compromised workload into a broader infrastructure problem.
  • Runtime Integrity: Runtime integrity is the assurance that what a system executes matches what defenders expect at the moment of execution. It matters because malware or exploit code can change memory, cache, or process behaviour without changing the on-disk file, which makes artifact-based checks incomplete on their own.
  • Blast Radius: Blast radius is the amount of damage or spread a compromise can cause before it is contained. In NHI and workload security, it describes how far one compromised account, container, or host can move across shared infrastructure, which is why privilege boundaries and segmentation matter.

Deepen your knowledge

Runtime-integrity monitoring and shared-cluster privilege reduction are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment blends container workloads, privileged execution, and NHI governance, it is worth exploring.

This post draws on content published by Oligo Security: Copy Fail (CVE-2026-31431) and Linux local privilege escalation. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-05-04.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org