CopyFail 취약점: 파드에서 호스트로 권한 상승

Vulnerability Research AI for Security Open Source Projects Copy Fail: From Pod to Host. A walkthrough of Copy Fail (CVE-2026-31431) as a container escape primitive: from a 4-byte page cache write to host root on Kubernetes. Juno Im May 19, 2026 Contents Why the Page Cache Crosses Container Boundaries Scenario 1: Cross-Container Poisoning 1-1: Compromised pod sharing a base layer 1-2: Pod creation rights Scenario 2: Container Escape Detection and Mitigation Community PoCs Two weeks ago, we disclosed Copy Fail , a new and exceptionally dangerous Linux local-privilege escalation vulnerability. Copy Fail exploits a kernel memory corruption flaw without injecting code into a running kernel, which makes it small and unusually portable. Copy Fail gives attackers a repeatable, controlled 4-byte write into the Linux page cache backing any readable file; in other words, it allows attackers to rewrite the cached contents of files on a Linux filesystem. To help operators determine their susceptibility to Copy Fail, we published a proof-of-concept exploit and a model attack path. Our model attack targets the su binary present on most Linux systems. Because su is setuid root, an attacker who can rewrite it and then execute it can escalate to root. Instead of having it ask for and check a root password, the rewritten su skips the paperwork and drops the caller straight into a root shell. Our proof-of-concept led some to believe that rewriting setuid binaries like su was the extent of the attack. Not so! The capability that Copy Fail and related page cache writing exploits extend to attackers is powerful and versatile. As an example, let’s walk through how to use it to break out of a namespaced container. To understand this new exploit pattern, you have to understand a little bit about what’s happening under the hood in Copy Fail. Copy Fail works by confusing the kernel code that handles IPSec ESP Extended Sequence Numbers ( authencesn ). This code is exposed to unprivileged users via AF_ALG sockets, which are userland’s interface to Linux’s kernel cryptography subsystem. Specifically, Copy Fail sets the authencesn code up to think it’s looking at disposable scratch memory when it’s really handling a mutable reference to the page cache. It tells the kernel’s cryptography code to decrypt a ciphertext blob, using bytes supplied by a zero-length copy from a pipe using splice(2) . Because the wire format for IPSec ESNs isn’t the implicit format the crypto code operates on, the authencesn code shuffles sequence numbers around. But the code isn’t handling a disposable buffer from a packet; Copy Fail has tricked it into operating on a reference to a cached file. Cross-container kernel attacks usually corrupt kernel memory: race windows, UAFs, version-bound payloads. These primitives are powerful, as they can allow code execution at the kernel level. But they’re fragile. Copy Fail is deterministic. It’s a more reliable primitive for cross-pod compromise or runtime poisoning, without relying on kernel code execution. There are two primary attack scenarios: Scenario 1: cross-container poisoning. From a compromised pod, or from a freshly-launched attacker pod (only create pods rights required), potentially backdoor co-located pods that access the same vulnerable lower-layer file through the same underlying address_space. Image references can differ; only a layer hash needs to match. The compromise lives only in the kernel page cache so on-disk bytes are unchanged and it is invisible to agent-less disk scanners. Scenario 2: container escape. From inside an unprivileged container, or from a compromised DaemonSet with host-filesystem mounts, get a root shell on the host. Why the Page Cache Crosses Container Boundaries The page cache is shared across containers. No matter what namespace you’re in, every struct file the kernel handles carries an f_mapping pointer, which usually comes from the underlying inode’s i_mapping . That means that any two file descriptors sharing an f_mapping share the same cache data. The kernel’s representation of contiguous pages of memory is called a “folio”. For ordinary buffered I/O on regular files, a write through one fd updates the cached folios. Subsequent reads, on every related fd, see the updated data (subject to normal concurrency and ordering rules). Copy Fail mutates the same folios via the AF_ALG/splice() path described in Part 1, bypassing the regular write accounting. The visibility property is unchanged: any fd whose f_mapping points at the affected address_space reads the modified bytes on its next page cache hit. All of this is independent of containers. Container isolation lives in mount, network, PID, user, and IPC namespaces. None of them creates a per-container address_space or page cache. Containers share cached folios when their file accesses reach the same underlying address_space . A Kubernetes container's root filesystem is commonly an overlayfs mount stitched together from a writable upper layer (usually per-container scratch) and one or more read-only lower layers (image layers). Container runtimes (containerd, CRI-O, others) deduplicate layers by content hash : if two containers on the same node use the same unpacked layer/snapshot, the corresponding lower-layer files can be backed by the same host inode/address_space, regardless of what the images are named. This reuse allows lowering the storage requirements for images by sharing common layers. python:3.12-slim and xint-flask-app:v1 (built FROM python:3.12-slim ) share the Python layer. Both share debian:bookworm-slim underneath. A redis:7-bookworm pod on the same node shares the Debian layer with both. In normal operation on an overlayfs mount, opening a lower-layer file for write access or truncation triggers overlayfs copy-up before writes proceed, allocating a new inode in the pod's upper layer so the change is private. By storing only this small set of differences, containers can reuse their lower layers efficiently while still allowing a writable copy to be presented to applications. However Copy Fail skips the standard write path entirely. The folios it mutates belong to the lower-layer address_space itself, shared host-wide, rather than the upper layers that were meant to store write deltas. The pods' overlayfs mounts each present what looks like a private /usr/local/lib/python3.12/site-packages/foo.py (or /lib/x86_64-linux-gnu/libc.so.6 ), but overlayfs delegates file I/O to the real lower backing file. If those backing files are the same lower inode/address_space, the cached folios are shared: Copy Fail's 4-byte write goes into that one underlying entry. Anything that subsequently reads the same lower-layer file through the same underlying address_space can read the poisoned bytes, until the page is evicted or the layer is dropped. The on-disk inode is unchanged so of course image-registry scanners, file-integrity monitors examining the disk hash, and offline, snapshot, or block-level scanners that bypass the affected running kernel's page cache see the original content. Scenario 1: Cross-Container Poisoning Threat model. Unprivileged attacker, no privileged capabilities, no node access, no admission rights to mutate other workloads. Two ways to start: code execution in a pod the attacker already controls (1-1), or just create pods rights (1-2). Target. Pick a file in a layer widely shared on the node: a Python site-packages/ module if the node hosts Python-derived workloads, a shared object such as glibc for broader reach, subject to executable mapping, patch alignment, and crash-safety constraints anything inside a Debian/Ubuntu/Alpine base layer. We will use a Python source file for this demo. Pick a module imported during interpreter startup or during a common framework's init, so target pods load it early. The write. Python files are a good target for a demo because they are easier to read and are more portable than shellcode. Any changes to Python files