Copy Fail (CVE-2026-31431) — Kubernetes Container Escape PoC

A proof-of-concept demonstrating how a fully unprivileged container can achieve node-level code execution on Kubernetes by exploiting the CVE-2026-31431 Linux kernel page-cache corruption bug through shared container image layers.

The core attack primitive is: any privileged DaemonSet sharing image layers with an attacker-controlled container can be weaponized for container escape. This PoC uses kube-proxy as one concrete example, but the technique generalizes to any privileged workload on the cluster.

Validated on Alibaba Cloud ACK, Amazon EKS, and Google GKE — an unprivileged pod writes [*] success to the host filesystem via the privileged kube-proxy DaemonSet:

Alibaba Cloud ACK (kernel 6.6.88)	Amazon EKS (kernel 6.12.79)	Google GKE (kernel 6.12.68)

Disclaimer: This repository is published for educational and defensive purposes only. Use it exclusively on systems you own or have explicit authorization to test.

Background

CVE-2026-31431 ("Copy Fail") is a Linux kernel vulnerability in the page-cache Copy-on-Write (CoW) path. An AF_ALG splice race allows an unprivileged process to corrupt the page-cache pages of a read-only file. The corruption persists in the kernel page cache and is visible to every process that subsequently reads or executes the file — including processes in other containers or on the host.

For full details on the original vulnerability, see copy.fail.

Attack Principle

The attack exploits three properties that commonly coexist in Kubernetes clusters:

1. Kernel page-cache corruption (CVE-2026-31431) — an unprivileged process can overwrite the in-memory cached pages of any file it can open read-only.
2. Image layer sharing — container runtimes (containerd, CRI-O) use overlay filesystems where identical image layers map to the same page-cache pages across containers.
3. Privileged DaemonSets — many clusters run DaemonSets with elevated privileges (privileged: true, hostNetwork: true, broad capabilities, etc.) that periodically execute binaries from their image.

When these conditions align, an unprivileged pod can corrupt a binary in a shared image layer, and a privileged DaemonSet on the same node will unknowingly execute the corrupted binary with its elevated privileges — achieving full node-level code execution.

The vulnerability target is NOT limited to kube-proxy. Any privileged DaemonSet (monitoring agents, CNI plugins, log collectors, security agents, etc.) whose container image shares layers with an attacker-controlled image is a viable target.

How It Works

The attack chain has three stages: page-cache corruption, cross-container propagation, and privileged execution.

1. Page-Cache Corruption via AF_ALG Splice Race

The kernel's AF_ALG (crypto) subsystem exposes a socket-based interface for userspace cryptographic operations. The exploit abuses a race condition in how the kernel handles splice() from a file into an AF_ALG socket:

1. Open the target binary read-only.
2. Create an AF_ALG AEAD socket bound to authencesn(hmac(sha256),cbc(aes)).
3. Send a small payload chunk through the AF_ALG socket with MSG_MORE, telling the kernel to expect more data.
4. splice() the target file's contents from an fd → pipe → AF_ALG socket.
5. Due to the CoW bug, the kernel writes the attacker's payload bytes into the target file's page-cache pages instead of properly isolating them.

The exploit repeats this for each 4-byte window until the entire target binary's cached pages are overwritten with a custom payload.

No write permission to the file is needed. The file on disk is unchanged — only the in-memory page cache is corrupted.

2. Cross-Container Propagation via Image Layer Sharing

Container runtimes use overlay filesystems. When two containers share the same image layer, the kernel serves their file reads from the same page-cache pages.

The attacker builds their PoC image FROM the same base image as the target privileged DaemonSet. Because both containers share the same overlay lower-dir, binaries in the shared layer map to identical page-cache pages.

When the unprivileged PoC container corrupts a binary's page cache, the corruption is immediately visible to the privileged container on the same node — with zero cross-container communication.

3. Privileged Execution by the Target DaemonSet

When the privileged DaemonSet next executes any corrupted binary (through its normal operation cycle), the kernel loads the corrupted page-cache pages. The attacker's payload runs with the DaemonSet's full privileges — potentially including:

• Full root on the node
• All capabilities
• Access to host namespaces (network, PID, mount)

The payload in this PoC (payload/payload.c) simply mounts the host root filesystem and writes a marker file to /root/res as proof of node-level code execution.

Attack Flow Diagram

┌──────────────────────────┐     ┌──────────────────────────┐
│   PoC Container          │     │   Privileged DaemonSet   │
│   (unprivileged)         │     │   (e.g. kube-proxy,      │
│                          │     │    monitoring agent, etc.)│
│  1. Open target binary   │     │                          │
│     (read-only)          │     │                          │
│                          │     │                          │
│  2. AF_ALG splice race   │     │                          │
│     corrupts page cache  │     │                          │
│          │               │     │                          │
└──────────┼───────────────┘     └──────────────────────────┘
           │                                  │
           ▼                                  │
  ┌─────────────────────┐                     │
  │  Kernel Page Cache   │                     │
  │                      │◄────────────────────┘
  │  Shared-layer binary │     3. DaemonSet executes the
  │  (CORRUPTED)         │        corrupted binary
  │  contains attacker's │        → loads corrupted pages
  │  payload bytes       │        → payload runs with
  └─────────────────────┘           DaemonSet's privileges

Validated Cloud Environments

The PoC has been successfully validated on the following managed Kubernetes platforms:

Alibaba Cloud ACK

Property	Value
Platform	Alibaba Cloud Container Service for Kubernetes (ACK)
Kubernetes	v1.35.2
Node Kernel	6.6.88-4.2.alnx4.x86_64
kube-proxy	registry-cn-*.ack.aliyuncs.com/acs/kube-proxy:v1.35.2-aliyun.1
Base Image	registry.k8s.io/kube-proxy:v1.35.2 (upstream)
Root Device	/dev/vda3 (ext4)

Amazon EKS

Property	Value
Platform	Amazon Elastic Kubernetes Service (EKS)
Kubernetes	v1.35.4
Node Kernel	6.12.79-101.147.amzn2023.x86_64
kube-proxy	***.dkr.ecr.***.amazonaws.com.cn/eks/kube-proxy:v1.35.3-eksbuild.2
Base Image	public.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base-iptables:2026-03-11-1773190710.2023
Root Device	/dev/nvme0n1p1 (xfs)

Google GKE