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

Ein Proof-of-Concept, das demonstriert, wie ein vollständig unprivilegierter Container eine Codeausführung auf Knotenebene in Kubernetes erreichen kann, indem es den Linux-Kernel-Page-Cache-Bug CVE-2026-31431 durch gemeinsam genutzte Container-Image-Layer ausnutzt.

Die grundlegende Angriffsprimitive ist: Jedes privilegierte DaemonSet, das Image-Layer mit einem angreiferkontrollierten Container teilt, kann für einen Container-Ausbruch genutzt werden. Dieses PoC verwendet kube-proxy als konkretes Beispiel, aber die Technik verallgemeinert sich auf jede privilegierte Arbeitslast im Cluster.

Validieren auf Alibaba Cloud ACK, Amazon EKS und Google GKE – ein unprivilegierter Pod schreibt [*] success in das Host-Dateisystem über das privilegierte kube-proxy DaemonSet:

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

Haftungsausschluss: Dieses Repository wird ausschließlich zu Bildungs- und Verteidigungszwecken veröffentlicht. Verwenden Sie es ausschließlich auf Systemen, die Ihnen gehören oder für die Sie ausdrückliche Berechtigung zum Testen haben.

Hintergrund

CVE-2026-31431 ("Copy Fail") ist eine Linux-Kernel-Sicherheitslücke im Page-Cache-Copy-on-Write (CoW)-Pfad. Ein AF_ALG-Splice-Race erlaubt es einem unprivilegierten Prozess, die Page-Cache-Seiten einer schreibgeschützten Datei zu beschädigen. Die Beschädigung bleibt im Kernel-Page-Cache bestehen und ist für jeden Prozess sichtbar, der die Datei anschließend liest oder ausführt – einschließlich Prozessen in anderen Containern oder auf dem Host.

Weitere Einzelheiten zur ursprünglichen Sicherheitslücke finden Sie unter copy.fail.

Angriffsprinzip

Der Angriff nutzt drei Eigenschaften aus, die in Kubernetes-Clustern häufig gemeinsam auftreten:

1. Kernel-Page-Cache-Beschädigung (CVE-2026-31431) – ein unprivilegierter Prozess kann die im Arbeitsspeicher zwischengespeicherten Seiten jeder Datei überschreiben, die er schreibgeschützt öffnen kann.
2. Gemeinsame Nutzung von Image-Layern – Container-Laufzeiten (containerd, CRI-O) verwenden Overlay-Dateisysteme, bei denen identische Image-Layer auf dieselben Page-Cache-Seiten über mehrere Container hinweg abgebildet werden.
3. Privilegierte DaemonSets – viele Cluster betreiben DaemonSets mit erhöhten Privilegien (privileged: true, hostNetwork: true, breite Capabilities usw.), die regelmäßig Binärdateien aus ihrem Image ausführen.

Wenn diese Bedingungen zusammentreffen, kann ein unprivilegierter Pod eine Binärdatei in einem gemeinsamen Image-Layer beschädigen, und ein privilegiertes DaemonSet auf demselben Knoten wird die beschädigte Binärdatei unwissentlich mit seinen erhöhten Privilegien ausführen – was eine vollständige Codeausführung auf Knotenebene erreicht.

Das Angriffsziel ist NICHT auf kube-proxy beschränkt. Jedes privilegierte DaemonSet (Überwachungsagenten, CNI-Plugins, Log-Sammler, Sicherheitsagenten usw.), dessen Container-Image Layer mit einem angreiferkontrollierten Image teilt, ist ein mögliches Ziel.

Funktionsweise

Die Angriffskette besteht aus drei Phasen: Page-Cache-Beschädigung, containerübergreifende Verbreitung und privilegierte Ausführung.

1. Page-Cache-Beschädigung via AF_ALG Splice Race

Das AF_ALG (Krypto)-Subsystem des Kernels stellt eine socketbasierte Schnittstelle für kryptografische Operationen im userspace bereit. Der Exploit missbraucht eine Race-Condition in der Art und Weise, wie der Kernel splice() von einer Datei in einen AF_ALG-Socket behandelt:

1. Öffnen Sie die Zielbinärdatei im schreibgeschützten Modus.
2. Erstellen Sie einen AF_ALG AEAD-Socket, der an authencesn(hmac(sha256),cbc(aes)) gebunden ist.
3. Senden Sie einen kleinen Payload-Chunk über den AF_ALG-Socket mit MSG_MORE, um dem Kernel mitzuteilen, dass weitere Daten erwartet werden.
4. splice() Sie den Inhalt der Zieldatei von einem fd → Pipe → AF_ALG-Socket.
5. Aufgrund des CoW-Bugs schreibt der Kernel die Payload-Bytes des Angreifers in die Page-Cache-Seiten der Zieldatei, anstatt sie ordnungsgemäß zu isolieren.

Der Exploit wiederholt dies für jedes 4-Byte-Fenster, bis alle zwischengespeicherten Seiten der Zielbinärdatei mit einem benutzerdefinierten Payload überschrieben sind.

Es ist keine Schreibberechtigung für die Datei erforderlich. Die Datei auf der Festplatte bleibt unverändert – nur der im Arbeitsspeicher befindliche Page-Cache wird beschädigt.

2. Containerübergreifende Verbreitung durch gemeinsame Image-Layer

Container-Laufzeiten verwenden Overlay-Dateisysteme. Wenn zwei Container denselben Image-Layer teilen, bedient der Kernel ihre Dateilesevorgänge von denselben Page-Cache-Seiten.

Der Angreifer baut sein PoC-Image FROM demselben Basis-Image wie das privilegierte Ziel-DaemonSet. Da beide Container dasselbe Overlay-Lower-Verzeichnis teilen, werden Binärdateien im gemeinsamen Layer auf identische Page-Cache-Seiten abgebildet.

Wenn der unprivilegierte PoC-Container den Page-Cache einer Binärdatei beschädigt, ist die Beschädigung sofort für den privilegierten Container auf demselben Knoten sichtbar – ohne jegliche containerübergreifende Kommunikation.

3. Privilegierte Ausführung durch das Ziel-DaemonSet

Wenn das privilegierte DaemonSet als nächstes eine beschädigte Binärdatei ausführt (durch seinen normalen Betriebszyklus), lädt der Kernel die beschädigten Page-Cache-Seiten. Der Payload des Angreifers läuft mit den vollen Privilegien des DaemonSets – möglicherweise einschließlich:

• Vollständiger Root-Zugriff auf dem Knoten
• Alle Capabilities
• Zugriff auf Host-Namespaces (Netzwerk, PID, Mount)

Der Payload in diesem PoC (payload/payload.c) mountet einfach das Host-Root-Dateisystem und schreibt eine Markierungsdatei nach /root/res als Beweis für die Codeausführung auf Knotenebene.

Angriffsablaufdiagramm

┌──────────────────────────┐     ┌──────────────────────────┐
│   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

Validierte Cloud-Umgebungen

Das PoC wurde erfolgreich auf den folgenden verwalteten Kubernetes-Plattformen validiert:

Alibaba Cloud ACK

Amazon EKS

Google GKE

In allen drei Fällen schrieb ein unprivilegierter PoC-Pod erfolgreich die Markierungsdatei [*] success in das Host-Dateisystem – was die Codeausführung auf Knotenebene durch das privilegierte kube-proxy DaemonSet beweist.

Für die vollständigen Anleitungen (Image-Layer-Analyse, Build-Schritte, Bereitstellung):

• EKS: docs/eks-poc.md
• GKE: docs/gke-poc.md

kube-proxy als konkretes Beispiel

Dieses PoC verwendet kube-proxy als Ziel, da es eines der häufigsten privilegierten DaemonSets in Kubernetes-Clustern ist. Es werden drei Varianten bereitgestellt:

• Standard (ACK / Upstream): erstellt FROM registry.k8s.io/kube-proxy:v1.35.2 (siehe Dockerfile)
• EKS: erstellt FROM public.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base-iptables:2026-03-11-1773190710.2023 (siehe Dockerfile.eks)
• GKE: erstellt FROM us-central1-artifactregistry.gcr.io/gke-release/gke-release/kube-proxy:v1.35.3-gke.1234000 (siehe Dockerfile.gke)

Alle Varianten beschädigen Binärdateien wie /usr/sbin/ipset, /usr/sbin/nft, /usr/sbin/xtables-legacy-multi und /usr/sbin/xtables-nft-multi.

Wichtige Einschränkungen:

• kube-proxy ruft ipset nur auf, wenn es im ipvs-Modus konfiguriert ist. Der Standardmodus (iptables) verwendet ipset nicht. Siehe kubernetes/enhancements#5495 für den ipvs-Deprecation-Plan.
• Einige verwaltete Kubernetes-Distributionen (z.B. bestimmte Cloud-Anbieter) betreiben kube-proxy als nicht privilegierten Container, was die Auswirkungen des Ausbruchs begrenzt.
• Das PoC zielt auf mehrere Binärdateien (ipset, nft, xtables-legacy-multi, xtables-nft-multi) ab, um verschiedene Proxy-Modi abzudecken, aber ob sie aufgerufen werden, hängt von der Clusterkonfiguration ab.

Wenn kube-proxy in Ihrem Cluster nicht privilegiert ist, gilt das Angriffsprinzip dennoch – Sie müssen lediglich ein anderes privilegiertes DaemonSet identifizieren, das Image-Layer mit einem Basis-Image teilt, von dem aus Sie bauen können.

Verallgemeinerung auf andere Ziele

Um dieses PoC an ein anderes privilegiertes DaemonSet anzupassen:

1. Identifizieren Sie ein privilegiertes DaemonSet, das auf dem Cluster läuft (Überwachungsagenten, CNI-Plugins, Log-Sammler usw.).
2. Bauen Sie Ihr PoC-Image FROM demselben Basis-Image, das von diesem DaemonSet verwendet wird.
3. Identifizieren Sie Binärdateien im gemeinsamen Layer, die das DaemonSet während seines normalen Betriebs ausführt.
4. Beschädigen Sie den Page-Cache dieser Binärdateien mithilfe des Exploits.

Repository-Struktur

.
├── cmd/copyfail/main.go          # Entry point; embeds compiled payload
├── internal/
│   ├── exploit/
│   │   ├── exploit.go            # Core exploit: AF_ALG splice race loop
│   │   └── patch.go              # Splits payload into 4-byte patch windows
│   └── alg/
│       └── alg.go                # AF_ALG AEAD socket abstraction
├── payload/
│   ├── payload.c                 # ACK/upstream payload (mount /dev/vda3 ext4)
│   ├── payload-eks.c             # EKS payload (NVMe/Xen device auto-detection)
│   ├── payload-gke.c             # GKE payload (COS/Ubuntu device auto-detection)
│   └── nolibc/                   # Kernel's tiny libc for static, no-dependency payloads
├── deploy/
│   ├── poc.yaml                  # Kubernetes Deployment manifest (ACK/upstream)
│   ├── poc-eks.yaml              # EKS Deployment manifest
│   └── poc-gke.yaml              # GKE Deployment manifest
├── Dockerfile                    # ACK/upstream: FROM registry.k8s.io/kube-proxy
├── Dockerfile.eks                # EKS: FROM eks-distro-minimal-base-iptables
├── Dockerfile.gke                # GKE: FROM gke-release/kube-proxy
├── Makefile                      # Build orchestration (includes *-eks and *-gke targets)
└── docs/
    ├── eks-poc.md                # EKS PoC full walkthrough
    ├── gke-poc.md                # GKE PoC full walkthrough
    ├── ack-poc-res.png           # ACK validation screenshot
    ├── eks-poc-res.png           # EKS validation screenshot
    └── gke-poc-res.png           # GKE validation screenshot

Voraussetzungen

• Go 1.25+
• Ein Cross-Compiler für den nolibc-Payload (Standard: x86_64-linux-gnu-gcc)
• Docker / Buildx
• Ein Kubernetes-Cluster mit einem privilegierten DaemonSet, das Image-Layer mit dem PoC-Image teilt (das Standardbeispiel zielt auf kube-proxy)
• imagePullPolicy: IfNotPresent auf dem Ziel-DaemonSet (der Kubernetes-Standard)
• Linux-Kernel vor dem CVE-2026-31431-Fix

Erstellung

ACK / Upstream Kubernetes

# Build payload + Go binary
make build

# Build Docker image
make docker-build

# Build and push to GHCR
make docker-push IMAGE=ghcr.io/<you>/copy-fail-poc TAG=latest

Amazon EKS

# Build EKS payload + Go binary + Docker image
make docker-build-eks

# Build and push to GHCR
make docker-push-eks IMAGE=ghcr.io/<you>/copy-fail-poc

Für arm64-Ziele (Graviton):

make build-eks CC=aarch64-linux-gnu-gcc GOARCH=arm64

Google GKE

# Build GKE payload + Go binary + Docker image
make docker-build-gke

# Build and push to GHCR
make docker-push-gke IMAGE=ghcr.io/<you>/copy-fail-poc

Für arm64-Knoten:

make docker-build-gke CC=aarch64-linux-gnu-gcc GOARCH=arm64 PLATFORM=linux/arm64

Verwendung

Bereitstellen des PoC

# ACK / upstream Kubernetes
kubectl apply -f deploy/poc.yaml

# Amazon EKS
kubectl apply -f deploy/poc-eks.yaml

# Google GKE
kubectl apply -f deploy/poc-gke.yaml

Das Deployment erstellt einen einzelnen unprivilegierten Pod. Dieser:

1. Führt /bin/copyfail aus, um den Page-Cache von Zielbinärdateien im gemeinsamen Image-Layer zu beschädigen.
2. Hält unbegrenzt an, sodass der Pod für Beobachtungen weiterläuft.

Überprüfen des Ausbruchs

Nachdem das privilegierte Ziel-DaemonSet als nächstes eine beschädigte Binärdatei ausführt (bei kube-proxy geschieht dies normalerweise innerhalb von Sekunden aufgrund der Reconciliation-Schleife), überprüfen Sie den Knoten:

# SSH into the node, or use a privileged debug pod

# ACK / EKS (writable root filesystem)
cat /root/res
# Expected output: [*] success

# GKE COS nodes (read-only root, writable stateful partition)
cat /mnt/stateful_partition/copyfail-res
# Expected output: [*] success

Das Vorhandensein der Markierungsdatei auf dem Host-Dateisystem beweist, dass vom Angreifer bereitgestellter Code mit privilegierten Rechten auf Knotenebene ausgeführt wurde – aus dem Container-Kontext des privilegierten DaemonSets heraus.

Bereinigen

kubectl delete -f deploy/poc.yaml      # or poc-eks.yaml / poc-gke.yaml

# On the affected node(s), remove the marker and restart the target DaemonSet:
rm -f /root/res                                     # ACK / EKS
rm -f /copyfail-res /mnt/stateful_partition/copyfail-res  # GKE COS nodes
# For kube-proxy: delete the pod to force image layer re-read
kubectl delete pod -n kube-system -l k8s-app=kube-proxy --field-selector spec.nodeName=<node>

Anpassen des Payloads

Der Standard-Payload (payload/payload.c) ist ein reines Validierungsprogramm, das eine Markierungsdatei schreibt. Um einen benutzerdefinierten Payload zu erstellen:

1. Bearbeiten Sie payload/payload.c. Das Programm wird gegen nolibc (die minimale C-Bibliothek des Kernels) erstellt, um eine statische, abhängigkeitsfreie Binärdatei zu erhalten.
2. Führen Sie make payload aus, um zu cross-kompilieren.
3. Der kompilierte Payload wird über //go:embed in die Go-Binärdatei eingebettet.

Betroffene Versionen

• Linux-Kernel: Alle Versionen vor dem CVE-2026-31431-Patch.
• Kubernetes: Jede Version, die einen ungepatchten Knoten-Kernel verwendet. Die Sicherheitslücke liegt im Kernel, nicht in Kubernetes selbst. Kubernetes bietet lediglich den Ausführungskontext (gemeinsam genutzte Image-Layer + privilegierte DaemonSets), der die Auswirkungen von einer lokalen Page-Cache-Beschädigung zu einem vollständigen Container-Ausbruch erhöht.

Milderung

• Patchen Sie den Kernel. Dies ist der endgültige Fix.
• Aktivieren Sie die Image-Layer-Isolation. Einige Laufzeiten unterstützen pro Container Dateisystem-Snapshots, die das Teilen des Page-Cache verhindern.
• Minimieren Sie privilegierte DaemonSets. Reduzieren Sie die Anzahl der Arbeitslasten, die mit erhöhten Privilegien laufen; verwenden Sie das Prinzip der geringsten Privilegien.
• Entfernen Sie unnötige Capabilities von DaemonSets, die nicht zwingend privileged: true benötigen.
• Schränken Sie die Pod-Planung ein, um zu verhindern, dass nicht vertrauenswürdige Arbeitslasten auf Knoten landen, die privilegierte DaemonSets mit gemeinsamen Basis-Images ausführen.
• Verwenden Sie unterschiedliche Basis-Images für privilegierte Arbeitslasten, um die Wahrscheinlichkeit einer Layer-Freigabe mit nicht vertrauenswürdigen Containern zu verringern.

Milderungsbeispiele

• vArmor built-in mitigation rule: copy-fail-mitigation blockiert den Exploit-Vektor, indem verhindert wird, dass Container AF_ALG-Sockets erstellen. Die Regel ist über die AppArmor- und BPF-Enforcer verfügbar.
• Kubernetes eBPF mitigation: iwanhae/copyfail-ebpf-k8s bietet ein eBPF-basiertes Kubernetes-Milderungsbeispiel für CVE-2026-31431.

Danksagungen

• CVE-2026-31431 Entdeckung und Offenlegung: Theori / Xint
• Plattformübergreifender C-Payload: Tony Gies (LGPL-2.1-or-later OR MIT)
• nolibc: Linux-Kernel-Selbsttests (tools/include/nolibc/)

Lizenz

Der Go-Exploit-Code in diesem Repository wird wie besehen für Forschungszwecke bereitgestellt.

Der Payload (payload/payload.c) stammt von copy-fail-c und ist dual lizenziert unter LGPL-2.1-or-later ODER MIT. Siehe LICENSE-LGPL und LICENSE-MIT.