Copy Fail (CVE-2026-31431): Wie 732 Bytes Python jeden Linux-Server seit 2017 zu Root machen

Es klingt wie ein schlechter Witz, ist aber bittere Realität. Ein 732 Byte kurzes Python-Skript reicht aus, um auf praktisch jedem Linux-Server der letzten neun Jahre Root-Rechte zu erlangen. Die Lücke trägt den Namen Copy Fail, ist offiziell als CVE-2026-31431 katalogisiert und wurde am 29. April 2026 öffentlich gemacht. Sie betrifft Ubuntu, Debian, Red Hat Enterprise Linux, SUSE, Amazon Linux, AlmaLinux, Rocky Linux, Fedora und so ziemlich alles, was einen Mainline-Linux-Kernel ab Version 4.14 nutzt. Das sind Millionen produktiver Server, Container-Hosts, CI-Runner und Kubernetes-Nodes weltweit.

Die gute Nachricht ist nicht zu unterschätzen. Die Linux-Community hat in einer beeindruckenden Geschwindigkeit reagiert, koordiniert gepatcht und gezeigt, warum Open Source bei Sicherheitsvorfällen oft vorne liegt. Dieser Artikel erklärt, was Copy Fail ist, wie der Bug entstand, wie ihn ein KI-Werkzeug fand und wie verschiedene Distributionen innerhalb von Stunden Patches ausgerollt haben.

Copy Fail auf einen Blick

Name: Copy Fail (CVE-2026-31431)
Schweregrad: CVSS 7.8 (High)
Art der Lücke: Local Privilege Escalation (LPE), zusätzlich Container-Escape-Primitive
Betroffene Kernel: 4.14 bis 6.18.21, 6.19 bis 6.19.11, sowie 7.0-rc1 bis 7.0-rc6
Fix in Mainline: 1. April 2026, Commit a664bf3d603d
Veröffentlichung: 29. April 2026 durch Theori und Xint
Exploit-Größe: 732 Bytes Python, deterministisch und ohne Race Condition
Pflicht-Patchdatum US-Behörden: 15. Mai 2026 (CISA KEV-Eintrag)

Was ist Copy Fail genau?

Im Kern ist Copy Fail ein Logikfehler in der Linux-Kernel-Krypto-Schnittstelle. Genauer gesagt sitzt das Problem im Modul algif_aead, also in der AEAD-Implementierung, die über AF_ALG-Sockets der Userspace zugänglich gemacht wird. Wenn das jetzt nach Fachchinesisch klingt: keine Sorge, es geht einfacher.

AF_ALG ist eine Schnittstelle, mit der unprivilegierte Programme die Krypto-Funktionen des Kernels nutzen können, ohne eigene Krypto-Bibliotheken zu laden. Eigentlich eine sinnvolle Sache. Allerdings hat sich darin ein gefährlicher Logikfehler versteckt, der über den Systemaufruf splice() ausgenutzt werden kann. Dieser Aufruf erlaubt es, Daten zwischen Dateideskriptoren zu bewegen, ohne sie zu kopieren. Stattdessen werden Referenzen auf den Page Cache des Kernels weitergereicht.

Genau diese Kombination wird zum Verhängnis. Im Detail beschreibt Xint die Lücke so: Ein unprivilegierter lokaler Nutzer kann vier kontrollierte Bytes in den Page Cache jeder lesbaren Datei eines Linux-Systems schreiben und damit Root erlangen.

Vier Bytes klingen wenig. Sie sind aber genug, um eine setuid-Binary wie /usr/bin/su so zu manipulieren, dass beim nächsten Aufruf eine Root-Shell startet. Der Trick dabei: Die Datei auf der Festplatte bleibt unverändert, denn nur die Kopie im Speicher, also der Page Cache, wird modifiziert. Klassische Integritäts-Tools wie Tripwire, AIDE oder OSSEC, die Datei-Hashes auf Festplatte prüfen, sehen also nichts.

Vier Eigenschaften, die Copy Fail besonders gefährlich machen

Die Forschungsteams von Theori und Xint heben vier Punkte hervor, die diesen Bug von älteren Linux-Lücken wie Dirty Cow oder Dirty Pipe abheben. Erstens ist er portabel. Dasselbe Skript funktioniert auf Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 und SUSE 16, weil es keine distributionsspezifischen Offsets benötigt. Zweitens ist er winzig, denn das Skript verwendet nur die Standardbibliothek von Python und keine externen Abhängigkeiten.

Drittens ist er heimtückisch unauffällig, weil keine Schreibvorgänge auf der Platte stattfinden. Die normalen Sicherheits-Tools, die auf Datei-Modifikationen reagieren, schlagen also nicht an. Viertens ist er besonders gemein in Container-Umgebungen. Da der Page Cache im Linux-Kernel zwischen Containern und Host geteilt wird, kann ein Angreifer aus einem unprivilegierten Container ausbrechen und das gesamte Host-System kompromittieren.

Dirty Cow von 2016 war auf eine Race Condition angewiesen, brauchte mehrere Anläufe und konnte das System zum Absturz bringen. Dirty Pipe von 2022 war dagegen versionsspezifisch. Copy Fail funktioniert demgegenüber beim ersten Versuch, deterministisch, auf praktisch jedem Kernel der letzten Jahre. Dieser Unterschied ist wichtig, weil viele Detection-Mechanismen genau auf die Unzuverlässigkeit der Vorgänger ausgelegt waren.

Wie der Bug entstanden ist: Eine Geschichte in drei Akten

Die Schwachstelle hat eine fast schon literarische Entstehungsgeschichte. Sie ist nicht aus einem einzigen schlampigen Commit entstanden, sondern aus drei für sich genommen harmlosen Änderungen, die erst zusammen zur Sicherheitslücke wurden. Genau deshalb hat sie auch so lange unentdeckt überlebt.

Der erste Akt spielt 2011. Damals wurde dem Linux-Kernel das Krypto-Template authencesn hinzugefügt, also eine spezielle Variante für IPsec mit Extended Sequence Numbers. Diese Implementierung nutzte den Zielpuffer des Aufrufers als Scratch-Space, also als temporären Arbeitsbereich. Solange das nur intern vom xfrm-Layer genutzt wurde, war es absolut unkritisch.

Der zweite Akt fand 2015 statt. AF_ALG bekam AEAD-Unterstützung, und damit wurde es theoretisch möglich, dass auch Userspace-Programme authencesn aufrufen. Allerdings nutzte AF_ALG damals noch eine Out-of-Place-Operation, also getrennte Quell- und Ziel-Scatterlists. Page-Cache-Seiten landeten nur in der schreibgeschützten Quelle, weil die Scratch-Schreibvorgänge in den eigenen Puffer des Nutzers gingen. Auch das war noch nicht ausnutzbar.

Der dritte und entscheidende Akt kam 2017. Eine Performance-Optimierung, eingebracht im Commit 72548b093ee3, schaltete algif_aead auf In-Place-Operationen um. Plötzlich landeten Page-Cache-Seiten aus splice() in der schreibbaren Ziel-Scatterlist. Die Scratch-Schreibvorgänge von authencesn schrieben damit direkt in den Kernel-Cache anderer Dateien. Niemand hat die drei Änderungen zusammengedacht, weil keine davon für sich genommen verdächtig aussah.

Genau das ist das Lehrbuchbeispiel einer Logiklücke an der Schnittstelle mehrerer Systeme. Jeder einzelne Code-Review hatte recht, niemandem ist etwas aufgefallen, und die Lücke schlummerte fast neun Jahre.

Wie der Exploit funktioniert: Vier Schritte zur Root-Shell

Der Exploit ist verblüffend einfach. Ein unprivilegierter Nutzer öffnet einen AF_ALG-Socket und bindet ihn an authencesn(hmac(sha256),cbc(aes)). Anschließend werden vier Bytes Shellcode pro Iteration in den Page Cache von /usr/bin/su geschrieben, jeweils an einer kontrollierten Position innerhalb des .text-Segments. Sind alle Bytes platziert, ruft das Skript einfach su auf. Weil die Datei setuid-Root ist und der manipulierte Bytecode aus dem Cache geladen wird, läuft der Shellcode mit Root-Rechten.

Das ist alles. Keine Heap-Sprays, keine ROP-Chains, keine Race Conditions. Eine Logik-Fehlerkette, vier Bytes pro Operation, am Ende eine Root-Shell. Das veröffentlichte Proof-of-Concept verwendet ausschließlich Standardmodule wie os, socket und zlib. Sogar eine portable C-Implementierung wurde schon kurz nach Veröffentlichung publiziert, was die Reproduzierbarkeit weiter erhöht.

Wie der Bug entdeckt wurde: KI im Sicherheitslabor

Eine der spannendsten Geschichten an Copy Fail ist nicht die Lücke selbst, sondern wie sie gefunden wurde. Der Theori-Forscher Taeyang Lee hatte zuvor bei kernelCTF die AF_ALG-Angriffsfläche untersucht und vermutet, dass die Kombination aus AF_ALG und splice() ein lohnendes Ziel sei. Anschließend nutzte er das hauseigene Werkzeug Xint Code, um diese Hypothese systematisch zu prüfen.

Xint Code ist ein KI-gestütztes Code-Analyse-Tool, das mit einem einfachen Operator-Prompt gefüttert wird. Im konkreten Fall lautete der Prompt sinngemäß: Untersuche alle Codepfade in crypto/, die von Userspace-Syscalls erreichbar sind, mit besonderem Augenmerk darauf, dass splice() Page-Cache-Referenzen in Crypto-Scatterlists liefern kann.

Nach etwa einer Stunde Scanzeit war Copy Fail die Top-Schwere im Output. Theori betont, dass es sich um KI-unterstützte Forschung gehandelt habe, nicht um automatisches Bug-Hunting ohne menschlichen Input. Die Domänenexpertise des Forschers war notwendig, um die richtige Frage zu stellen. Allerdings hätte ein menschliches Team wohl Wochen gebraucht, um diese Code-Pfade vollständig zu analysieren.

Theori ist übrigens kein Startup auf der Suche nach Aufmerksamkeit. Das Team hat als MMM (zusammen mit CMUs PPP und Maple Bacon) die DEF CON CTF neunmal gewonnen und steht im Finale der DARPA AI Cyber Challenge. Wenn diese Leute sagen, ein Operator-Prompt und eine Stunde reichen, dann ist das ernstzunehmen. Der Bug ist wichtig, aber die Art, wie er gefunden wurde, ist es noch mehr.

Diese Entwicklung passt zu einem Trend, der sich seit Anfang 2025 abzeichnet. Microsoft meldete kürzlich die zweitgrößte Anzahl an Patches überhaupt, weshalb das Internet Bug Bounty Programm zwischenzeitlich seine Auszahlungen pausierte. Der Hauptgrund: KI-Tools finden mittlerweile mehr Bugs, als die klassischen Triage-Strukturen verarbeiten können.

Coordinated Disclosure: So lief der Prozess ab

Die zeitliche Abfolge des Disclosure-Prozesses ist ein Vorzeigebeispiel für funktionierende Open-Source-Sicherheit. Die Forscher meldeten den Bug am 23. März 2026 an das Linux-Kernel-Security-Team. Schon am Folgetag kam eine Bestätigung. Bis zum 25. März lagen Patches zur Review vor. Am 1. April 2026 wurde der Fix in den Mainline-Kernel gemerged. Drei Wochen später, am 22. April, vergab MITRE die CVE-Nummer, und die öffentliche Bekanntgabe erfolgte schließlich am 29. April.

Insgesamt vergingen also gut fünf Wochen zwischen der ersten Meldung und der Veröffentlichung. Diese Zeit nutzten die großen Distributionen für interne Vorbereitung. Sie waren eingeweiht, hatten den Mainline-Commit verfügbar und konnten Backports vorbereiten. Trotzdem schafften nicht alle, am Tag der Veröffentlichung fertig zu sein. Das ist allerdings auch realistisch, denn Backports auf alte LTS-Kernel sind aufwändig.

Die Community-Reaktion: AlmaLinux geht voran

Besonders bemerkenswert ist die Geschichte von AlmaLinux. Während Red Hat zunächst signalisierte, den Fix zu verzögern, baute das AlmaLinux-Core-Team innerhalb weniger Stunden gepatchte Kernel auf Basis des Mainline-Commits. Andrew Lukoshko vom AlmaLinux-Core-Team baute die Patches für jede unterstützte Release am Disclosure-Tag selbst, und ALESCo, das AlmaLinux Engineering Steering Committee, gab schnell die Freigabe für den Versand vor Upstream.

Was dann folgte, war ein Lehrstück für Community-Zusammenarbeit. AlmaLinux rief zum Community-Testing auf, und die Antwort übertraf alle bisherigen Aufrufe. Das AlmaLinux-Team beschrieb es als die beste Beteiligung, die sie je hatten. Innerhalb weniger Stunden wurden die Test-Kernel von der Community verifiziert. Bereits am 1. Mai um 21:07 UTC waren die produktiven Patches in den offiziellen Repositories.

Das ist ein wichtiges Signal. Eine Community-getriebene Distribution hat schneller und besser reagiert als ein milliardenschwerer Konzern. Red Hat selbst änderte später seine Haltung und schloss sich dem schnellen Patch-Kurs an, weil der öffentliche Druck erheblich war. Die Linux-Community hat hier gezeigt, dass die Stärke von Open Source genau in dieser dezentralen Geschwindigkeit liegt.

Patch-Status der wichtigsten Distributionen

Die Lage hat sich seit der Veröffentlichung schnell verbessert. Hier ein Stand vom Anfang Mai 2026 mit den wichtigsten Distributionen.

Bei Debian ist die Lage komfortabel. Sid läuft mit Kernel 7.0.3-1 oder 6.19.12-1, Forky mit 6.19.14-1, Trixie (Debian 13) bekam 6.12.85-1 über das Security-Repository, Bookworm (Debian 12) erhielt 6.1.170-1, und sogar Bullseye (Debian 11) wurde mit 5.10.251-3 versorgt. Damit sind alle aktuell unterstützten Debian-Versionen abgedeckt.

Bei Ubuntu ging es in zwei Stufen los. Zunächst veröffentlichte das Ubuntu Security Team unter USN-8226-1 ein kmod-Update, das das Laden von algif_aead blockiert. Dieser Quick-Fix war noch am Disclosure-Tag verfügbar. Anschließend folgten die richtigen Kernel-Patches. Wichtig zu wissen: Ubuntu 26.04 Resolute war von Anfang an nicht betroffen, weil dort bereits ein neuerer Kernel ausgeliefert wurde.

Bei AlmaLinux und Rocky Linux sind die Patches in den Produktiv-Repositories. Rocky folgt traditionell dem AlmaLinux-Tempo, weil beide auf RHEL aufbauen. CloudLinux rollt seine eigenen Kernel-Builds aus, basierend auf den AlmaLinux-Fixes, und bietet zusätzlich KernelCare-Livepatches ohne Reboot an.

Bei RHEL zog Red Hat anfangs eine Verzögerungsstrategie in Betracht, änderte den Kurs aber unter dem Eindruck der Community-Reaktion. Die Backports laufen aktuell aus.

Bei Arch Linux waren die Patches innerhalb von Stunden nach Mainline-Merge verfügbar, was an der Rolling-Release-Strategie liegt. Fedora, SUSE/SLES und Amazon Linux befinden sich ebenfalls im aktiven Patching, wobei je nach Service-Pack die Geschwindigkeit variiert.

Sofortmaßnahmen für Admins

Wer Linux-Server betreibt, sollte jetzt drei Dinge tun. Erstens: Kernel-Version prüfen mit uname -r und mit den Advisories der eigenen Distribution abgleichen. Zweitens: Kernel-Update einspielen, sofern verfügbar. Drittens: Falls ein Update noch nicht bereitsteht, die Mitigation aktivieren.

Die einfachste Sofortmaßnahme besteht darin, das Kernel-Modul algif_aead zu deaktivieren. Zuerst legst du eine modprobe-Regel an, die das Laden des Moduls blockiert:

bash

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

Anschließend entlädst du das Modul, falls es bereits geladen ist:

bash

rmmod algif_aead 2>/dev/null || true

Diese Maßnahme verhindert, dass das Modul geladen werden kann, weshalb der Exploit-Pfad blockiert ist. Sie betrifft weder LUKS-Verschlüsselung, noch kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS oder SSH. Lediglich Anwendungen, die explizit den AF_ALG-Engine nutzen, könnten beeinträchtigt werden.

Wichtige Warnung für RHEL-Nutzer: Auf RHEL und allen RHEL-Derivaten wie AlmaLinux, Rocky Linux und CloudLinux funktioniert dieser Workaround nicht zuverlässig, weil das Modul fest in den Kernel kompiliert ist (CONFIG_CRYPTO_USER_API_AEAD=y). Die modprobe.d-Regel schlägt nicht an, und rmmod kann das Modul nicht entfernen. Die Kommandos laufen ohne Fehler durch und vermitteln eine falsche Sicherheit. Auf diesen Systemen muss der Initcall über grubby blockiert werden, oder man wartet auf den Kernel-Patch.

Hochrelevant ist die Mitigation außerdem auf Kubernetes-Nodes, CI/CD-Runnern und Multi-Tenant-Hosts. Auf diesen Systemen sind die Auswirkungen wegen der Container-Escape-Eigenschaft am gravierendsten.

Was Copy Fail über die Linux-Sicherheitsarchitektur lehrt

Diese Lücke gibt mehrere Lehren mit. Zum einen zeigt sie, dass die Annahme, Container seien eine Sicherheitsgrenze, falsch ist. Container sind eine Isolationsgrenze, aber keine Vertrauensgrenze. Wenn das Bedrohungsmodell echte Mehrmandantenfähigkeit umfasst, braucht es eine Hardware- oder VM-Grenze, etwa über microVMs oder gVisor.

Zum anderen zeigt der Fall, wie wichtig schnelle und transparente Disclosure-Prozesse sind. Die fünf Wochen zwischen Meldung und Veröffentlichung waren genau richtig dimensioniert. Distributionen konnten sich vorbereiten, ohne dass die Lücke währenddessen aktiv ausgenutzt werden konnte. Der Mainline-Commit war zum Zeitpunkt der Veröffentlichung bereits 28 Tage alt, weshalb wachsame Anwender eigene Backports hätten bauen können.

Zum dritten lehrt der Fall, dass Performance-Optimierungen im Kernel-Code besondere Vorsicht erfordern. Eine 2017 eingeführte In-Place-Operation, gedacht zur Beschleunigung, wurde zur Sicherheitslücke, sobald sie auf den 2011 entstandenen Scratch-Space-Trick traf. Genau solche Wechselwirkungen werden durch Code-Reviews allein nur selten gefunden.

Schließlich zeigt der Fund, dass KI-gestützte Sicherheitsforschung gerade einen Sprung macht. Wenn Theori in einer Stunde Scan-Zeit eine neunjährige Lücke findet, sollte das jeder ernsthafte Software-Hersteller als Warnung verstehen. Was Theori heute bei Linux machen kann, können andere mit ähnlichen Tools genauso gut bei jeder anderen Codebase machen.

Wieso Open Source bei Sicherheit oft die Nase vorn hat

Trotz der Schwere der Lücke ist Copy Fail letztlich auch ein Erfolgsbericht. Eine fast zehn Jahre alte Schwachstelle wurde gefunden, gemeldet, gepatcht und über praktisch alle wichtigen Distributionen ausgerollt. Das alles innerhalb weniger Wochen, mit einer beispielhaften Community-Beteiligung.

Bei einem proprietären System wäre die Lage anders. Es gäbe keinen offenen Mainline-Commit, den jeder Distributor selbst backporten könnte. Die Forscher hätten den Bug nicht so detailliert öffentlich machen können, ohne damit alle Nutzer zu gefährden, weil keine Patches in der Pipeline wären. Andrew Lukoshko hätte keine fertigen Mainline-Patches zum Backporten gehabt. Stattdessen wären Millionen Anwender auf den Gnaden eines einzelnen Anbieters gewesen.

Genau das macht den Unterschied. Open Source bietet keine perfekte Sicherheit, aber funktionierende Pfade zur schnellen Reaktion. Distributoren können unabhängig agieren. Die Community kann mittesten. Forscher können detaillierte Writeups veröffentlichen, weil die Patches jedem zugänglich sind. Das Vertrauen in das System wächst nicht trotz der Transparenz, sondern wegen ihr.

Fazit: Patchen, prüfen, weitermachen

Copy Fail ist eine ernste Lücke, aber kein Grund zur Panik. Wer regelmäßige Sicherheits-Updates einspielt, ist binnen weniger Tage durchgepatcht. Wer Container-Hosts oder CI-Infrastruktur betreibt, sollte jetzt aktiv werden, weil dort die Auswirkungen am größten sind. Die Mitigation über das Modul-Blacklisting ist ein guter Übergangsschritt, sofern man kein RHEL-Derivat fährt.

Die größere Geschichte hinter Copy Fail handelt aber nicht vom einzelnen Bug. Sie handelt von einer Linux-Community, die in Krisensituationen funktioniert. Sie handelt von KI-Tools, die das Spielfeld der Sicherheitsforschung gerade umkrempeln. Und sie handelt davon, dass Wartung von Software nie abgeschlossen ist, weil selbst harmlose Optimierungen Jahre später zur Sicherheitslücke werden können.

Wer mehr über die technischen Details lesen will, dem sei der ausführliche Writeup von Xint ans Herz gelegt. Wer einfach nur seinen Server checken will, prüft die Kernel-Version, spielt die Updates ein und macht weiter. Genau so, wie es seit Jahrzehnten in der Linux-Welt funktioniert.