Notwendigkeit der Überwachung: Copy Fail räumt jeden Zweifel aus

732 Bytes. Ein Python-Skript. Root-Zugriff auf jeder Linux-Distribution seit 2017. Keine Race Condition, keine kernelspezifischen Offsets, keine besonderen Voraussetzungen — ein unprivilegierter Benutzer mit einem Terminalzugang reicht. Und eine KI hat den Bug in einer Stunde gefunden.

CVE-2026-31431, genannt Copy Fail, wurde am 29. April 2026 vom südkoreanischen Sicherheitsunternehmen Theori veröffentlicht. Es ist eine der schwerwiegendsten Linux-Schwachstellen der letzten Jahre — nicht nur wegen des Schadenspotenzials, sondern wegen der Art, wie sie gefunden wurde.

Was Copy Fail ist

Copy Fail ist ein Fehler in der Krypto-Schnittstelle des Linux-Kernels, genauer im Modul algif_aead. Dieses Modul stellt Verschlüsselungsfunktionen über sogenannte AF_ALG-Sockets bereit — eine Schnittstelle, über die Programme auf die kryptografischen Fähigkeiten des Kernels zugreifen können.

2017 wurde in diesem Modul eine Optimierung eingeführt, die Daten direkt an Ort und Stelle verarbeitet, anstatt sie zuerst zu kopieren. Diese Optimierung enthält einen Logikfehler: Unter bestimmten Bedingungen kann eine Seite aus dem Page Cache (dem zentralen Dateizwischenspeicher des Kernels) in eine beschreibbare Liste gelangen, in die sie nicht gehört. Ein Angreifer kann über die Systemfunktion splice() gezielt wenige Bytes in diese Seite schreiben — und damit den Inhalt einer Datei verändern, die er eigentlich nur lesen darf.

In der Praxis bedeutet das: Der Angreifer manipuliert eine Setuid-Binärdatei (ein Programm, das mit Root-Rechten läuft, zum Beispiel /usr/bin/su) über den Page Cache und erhält damit vollständige Administratorrechte auf dem System.

Warum Copy Fail so gefährlich ist

Vier Eigenschaften machen diese Schwachstelle außergewöhnlich:

Kein Timing-Problem, keine Kernel-Abhängigkeit. Viele Linux-Schwachstellen erfordern präzises Timing (Race Conditions) oder funktionieren nur mit bestimmten Kernel-Versionen. Copy Fail ist ein reiner Logikfehler — das identische 732-Byte-Skript funktioniert auf Ubuntu, Amazon Linux, Red Hat Enterprise Linux (RHEL) und SUSE. Zuverlässig. Jedes Mal.

Der Page Cache ist systemweit. In Container-Umgebungen (etwa Kubernetes-Clustern) teilen sich alle Container den Page Cache des Host-Systems. Ein Angreifer in einem Container kann über den Page Cache den Host kompromittieren — und damit jeden anderen Container auf derselben Maschine. Das ist ein vollständiger Container-Ausbruch.

Betroffen ist jede Distribution seit 2017. Die fehlerhafte Optimierung wurde 2017 eingeführt und blieb fast neun Jahre unentdeckt — in einem Codebereich, der intensiv überprüft wird, allerdings typischerweise aus kryptografischer Perspektive. Ob die Speicherherkunft einer bestimmten Seite korrekt ist, wurde dabei offenbar nicht hinterfragt.

Keine besonderen Voraussetzungen. Ein unprivilegierter Benutzer-Account reicht. Kein Netzwerkzugang erforderlich, keine Kernel-Debug-Funktionen, keine vorinstallierten Hilfsmittel. Das AF_ALG-Modul ist in praktisch jeder Standard-Konfiguration aktiviert.

Wer konkret betroffen ist

Kubernetes-Cluster und Container-Plattformen mit geteiltem Kernel sind die offensichtlichsten Ziele. Namespace-Isolation — das Standardmodell für Container-Sicherheit — schützt nicht gegen diese Klasse von Schwachstellen. Die Isolation findet auf Prozessebene statt, der Page Cache ist aber eine gemeinsam genutzte Kernel-Ressource.

CI/CD-Build-Systeme, die Code aus Pull Requests ausführen — selbst gehostete GitHub-Actions-Runner, GitLab-Shared-Runner, Jenkins-Agents — sind besonders exponiert. Ein Angreifer könnte einen Pull Request einreichen, der beim Build-Prozess den Runner-Host kompromittiert.

KI-Sandboxen und Code-Ausführungsumgebungen, in denen Modelle Shell-Befehle oder beliebigen Code in Containern ausführen, sind eine wachsende Kategorie. Einige Plattformen nutzen bereits Micro-VMs (virtuelle Maschinen mit eigenem Kernel, zum Beispiel AWS Firecracker) oder gVisor (eine Technologie, die den Host-Kernel durch einen eigenen Kernel in der Benutzerebene ersetzt). Viele andere verlassen sich auf gewöhnliche Container — und sind damit verwundbar.

Klassische Linux-Server mit mehreren Benutzerkonten sind ebenfalls betroffen, allerdings ist das Risiko geringer, wenn nur vertrauenswürdiges Personal Zugang hat. In Kombination mit einer vorgelagerten Schwachstelle (etwa Remote Code Execution über eine Webanwendung) wird Copy Fail zum Eskalationsvektor: Der Angreifer kommt als normaler Benutzer rein und wird Root.

Nicht betroffen sind Umgebungen, die keinen Linux-Kernel teilen: AWS Lambda und Fargate (Firecracker-Micro-VMs), Cloudflare Workers (V8-Isolates) und Systeme mit gVisor. Das Muster ist konsistent: Was hält, sind Grenzen, die keinen Kernel teilen.

Die eigentliche Nachricht: Eine KI fand den Bug in einer Stunde

Copy Fail wurde von Xint Code gefunden, einem KI-System des Unternehmens Theori. Laut Theoris Bericht brauchte das System etwa eine Stunde Scan-Zeit gegen das Krypto-Subsystem des Linux-Kernels. Ein Operator-Prompt, keine manuelle Vorbereitung.

Um das einzuordnen: Theori ist kein unbekanntes Start-up. Das Team, bestehend aus Mitgliedern von CMU PPP und UBC Maple Bacon, hat neun Mal die DEF CON CTF gewonnen (die inoffizielle Weltmeisterschaft im Hacking) und belegte den dritten Platz beim Finale des DARPA AI Cyber Challenge.

David Brumley, Chief AI and Science Officer bei Bugcrowd und ehemaliger Professor an der Carnegie Mellon University, ordnet die Bedeutung ein: Was sich geändert hat, ist nicht, dass Werkzeuge Schwachstellen finden — das tun statische Analyse und Fuzzing seit Jahren. Was sich geändert hat, ist wer diese Werkzeuge bedienen kann und wie schnell Ergebnisse kommen. Die Einstiegshürde für die Nutzung ernsthafter Werkzeuge zur Schwachstellensuche sinkt rapide.

Brumley verweist auf die Graumarkt-Preislisten für Linux-Zero-Days: Zerodium zahlte bis zu 500.000 US-Dollar für einen hochwertigen Linux-Zero-Day. Crowdfense listet Programme im Bereich von 10.000 bis 7 Millionen US-Dollar, wobei die Spitze genau für diese Art von universeller, zuverlässiger Schwachstelle reserviert ist. Was bisher den Preis eines Hauses hatte, kostet jetzt eine Stunde Rechenzeit.

Dirty Pipe 2.0 — aber schlimmer

Die nächste Referenz ist Dirty Pipe (CVE-2022-0847), die schwere Linux-Schwachstelle von 2022, die ebenfalls den Page Cache missbrauchte. Copy Fail nutzt dasselbe Grundprinzip — eine Schreibmöglichkeit in den Page Cache, die nicht vorgesehen ist —, aber in einem anderen Subsystem und mit gefährlicheren Eigenschaften: kein Timing-Problem, breitere Kernel-Abdeckung, und ein direkter Container-Ausbruch-Vektor.

Sofortmaßnahmen

Kernel aktualisieren. Der Mainline-Patch (Commit a664bf3d603d) macht die fehlerhafte 2017-Optimierung in algif_aead rückgängig. Die meisten großen Distributionen liefern den Fix bereits aus. Prüfen Sie, ob Ihr Kernel gepatcht ist.

Vor dem Patch: algif_aead-Modul deaktivieren.

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

Diese Maßnahme hat für die meisten Systeme keine spürbaren Auswirkungen: LUKS-Verschlüsselung, IPsec, kTLS, SSH, OpenSSL und GnuTLS nutzen die Kernel-Krypto-Schnittstelle direkt, nicht über AF_ALG. Betroffen sind nur Anwendungen, die AF_ALG explizit konfiguriert haben (prüfbar mit lsof | grep AF_ALG).

Für Container-Umgebungen: AF_ALG über Seccomp blockieren. Unabhängig vom Patch-Status sollten Container-Workloads, die nicht vertrauenswürdigen Code ausführen, keine AF_ALG-Sockets öffnen dürfen. Das lässt sich über Seccomp-Profile (ein Mechanismus des Kernels, der Systemaufrufe für einzelne Prozesse einschränkt) erzwingen.

Container-Isolationsmodell überprüfen. Wenn Ihre Isolationsstrategie das Wort „Container“ enthält, ohne dass „Micro-VM“, „gVisor“ oder „dedizierter Host“ direkt dahinter steht: Copy Fail ist in Ihrem Bedrohungsmodell.

Was sich ändert

Copy Fail ist nicht nur ein einzelner Bug. Es ist ein Datenpunkt, der zeigt, dass die Kosten für das Auffinden tiefer Logikfehler in Systemsoftware möglicherweise um eine Größenordnung gesunken sind.

Drei Implikationen fallen daraus:

Container auf geteiltem Kernel sind ein riskanterer Standard als bisher angenommen. Container waren nie als Sicherheitsgrenze konzipiert. Sie sind eine Isolation auf Prozessebene — Kernel-Ressourcen wie der Page Cache werden geteilt. Für nicht vertrauenswürdige Workloads brauchen Sie eine Hardware- oder VM-Grenze.

Automatisierte Schwachstellensuche gehört in die Pipeline. Wenn KI-Systeme Bugs dieser Klasse in einer Stunde finden, müssen Sie ähnliche Fähigkeiten auf Ihren eigenen Code richten — vor dem Release, nicht nach der Veröffentlichung.

Wenn Ihr Bedrohungsmodell Kernel-Schwachstellen als selten einpreist, haben Sie Wochen, das zu korrigieren — nicht Jahre. Die Annahme, dass das Finden einer Kernel-Schwachstelle teuer ist und das Angebot daher begrenzt bleibt, ist nicht mehr haltbar. Die Versorgung mit neuen Kernel-Schwachstellen wird steigen — weil die Werkzeuge, sie zu finden, billiger und zugänglicher werden.

Einordnung

Copy Fail verbindet zwei Entwicklungen, die wir in den letzten Wochen in diesem Blog beschrieben haben: Die KI-gestützte Schwachstellensuche (zuletzt bei Anthropics Mythos Preview) und das Ende des reaktiven Schwachstellenmanagements (Qualys: „Broken Physics of Remediation“). Eine Stunde Scan-Zeit für eine Schwachstelle, die fast neun Jahre überlebt hat, Millionen automatisierter Tests überstanden hat und auf dem Graumarkt den Preis eines Hauses hätte — das ist nicht mehr die Welt, in der monatliche Patch-Zyklen ausreichen.

Patchen Sie Ihre Kernel. Deaktivieren Sie algif_aead, bis Sie gepatcht haben. Und überprüfen Sie, ob „Container“ in Ihrem Sicherheitskonzept tatsächlich das leistet, was Sie glauben.