Ein Logikfehler, der seit fast einem Jahrzehnt im kryptografischen Subsystem des Linux-Kernels schlummert, kann von jedem nicht privilegierten lokalen Benutzer ausgenutzt werden, um vollständigen Root-Zugriff zu erlangen – und der Proof-of-Concept-Exploit passt in ein 732 Byte großes Python-Skript.

Das Sicherheitsunternehmen Theori und sein KI-gestütztes Audit-Tool Xint Code haben die Schwachstelle, die den Namen „Copy Fail“ (CVE-2026-31431) trägt, am Mittwoch, den 29. April, öffentlich bekannt gegeben. Die Lücke weist einen CVSS-Score von 7,8 auf und betrifft nahezu alle wichtigen Linux-Distributionen, die seit 2017 ausgeliefert wurden, darunter Ubuntu, Amazon Linux, RHEL und SUSE.

Patches wurden von den großen Distributionen veröffentlicht, und der Fix für den Mainline-Linux-Kernel wurde am 1. April eingereicht.

Hinter dem Bug

Die Ursache liegt in einer Optimierung aus dem Jahr 2017 in algif_aead.c, die dafür sorgte, dass AEAD-Kryptografieoperationen direkt im Speicher (in-place) ablaufen. In Kombination mit dem splice()-Systemaufruf führt diese Optimierung dazu, dass Page-Cache-Seiten – die vom Kernel zwischengespeicherten Kopien von Dateien auf der Festplatte – in einer beschreibbaren Scatterliste landen. Der AEAD-Algorithmus authencesn schreibt dann im Rahmen seines normalen Entschlüsselungspfads vier Bytes an Scratch-Daten in diese Seiten.

Ein Angreifer kann bestimmen, welche Datei betroffen ist, den genauen Offset innerhalb dieser Datei sowie den Wert der vier geschriebenen Bytes. Der Standard-Exploit zielt auf /usr/bin/su ab, ein Setuid-Root-Binary, das auf jeder getesteten Distribution vorhanden ist. Nachdem der Page-Cache manipuliert wurde, öffnet der Aufruf von su dem Angreifer eine Root-Shell. Die Datei auf der Festplatte bleibt dabei unverändert, sodass Integritätsüberwachungswerkzeuge wie AIDE oder dm-verity nichts bemerken.

Im Gegensatz zu Dirty Pipe (CVE-2022-0847) – der Page-Cache-Schwachstelle aus dem Jahr 2022, mit der Copy Fail verglichen wird – erfordert dieser Exploit keine Race Condition und benötigt keine kernelspezifischen Offsets. Wie SUSE in seinem Advisory feststellte, „erfordert er keine komplexen Race Conditions und funktioniert mit 100-prozentiger Zuverlässigkeit über ein winziges Skript“.

KI-gestützte Entdeckung

Mindestens ebenso bemerkenswert wie die Schwachstelle selbst ist die Art, wie sie gefunden wurde. Laut der Offenlegung von Theori hat Xint Code – das KI-gestützte Schwachstellen-Scan-System des Unternehmens – den Fehler nach etwa einer Stunde automatisierter Analyse des Linux-crypto/-Subsystems aufgespürt, mit „einem einzigen Operator-Prompt, ohne Harness“. Theori, neunfacher DEF-CON-CTF-Champion und DARPA-AI-Cyber-Challenge-Finalist, veröffentlichte den vollständigen Proof-of-Concept zusammen mit der Offenlegung auf GitHub.

Bugcrowds Casey Ellis schrieb, die Entdeckung lege nahe, dass „die Kosten für das Aufspüren tiefer Logikfehler möglicherweise um etwa eine Größenordnung gesunken sind“, und warnte, dass Organisationen, deren Bedrohungsmodelle Kernel-Privilege-Escalation-Bugs als selten einstufen, „Wochen haben, um das zu aktualisieren – nicht Jahre“.

Patch und Schadensbegrenzung

Der Fix, der Mainline-Commit a664bf3d603d, macht die In-Place-Optimierung von 2017 rückgängig, sodass Page-Cache-Seiten nicht länger in die beschreibbare Scatter-Gather-Liste gelangen. Administratoren, die den Patch nicht sofort einspielen können, wird empfohlen, das Kernel-Modul algif_aead auf die Blacklist zu setzen – ein Schritt, der laut Theori auf den meisten Systemen keine messbaren Auswirkungen hat, da die überwiegende Mehrheit der kryptografischen Linux-Operationen die AF_ALG-Userspace-Schnittstelle nicht verwendet. Für containerisierte Umgebungen und CI-Umgebungen, die nicht vertrauenswürdigen Code ausführen, wird unabhängig vom Patch-Status empfohlen, die AF_ALG-Socket-Erstellung über seccomp zu blockieren.

Eine Stunde Scanzeit ist alles, was es brauchte

Wenn Sie diesen Fehler einem führenden Kernelforscher beschreiben würden —geben Sie mir ein universelles Linux-LPE, funktioniert über alle wichtigen Distributionen hinweg, kein Race Window, keine Offsets pro Kernel, sauberes Container-Escape-Primitiv—, würden sie Ihnen wahrscheinlich keine Zeitleiste geben. Sie würden Ihnen sagen, dass dies die Art von Dingen ist, die, wenn sie überhaupt existieren, dazu neigen, auf dem Maklermarkt zum Preis eines Hauses verkauft zu werden. 

Die öffentliche Preisliste von Zerodium bezahlt bis zu 500.000 US-Dollar für einen High-End-Linux-Zero-Day, bevor die Plattform Anfang 2025 eingestellt wurde. Heutige Graumarkt-Akquirierer wie Crowdfense führt Programme im Bereich von 10.000 $–7 Millionen $ durch, wobei die Oberseite dieses Bandes genau dieser Art von universellem, zuverlässigem Primitiv vorbehalten ist.

Dem Artikel zufolge tauchte innerhalb von etwa einer Stunde ein KI-System auf. Ich musste das zweimal lesen und dann tatsächlich ausführen, bevor ich es glaubte. Es ist echt.

Der Bug ist Kopierfehler (CVE-2026-31431), heute bekannt gegeben von Theori. Ein 732-Byte-Python-Skript führt Ubuntu, Amazon Linux, RHEL und SUSE — jeden Linux-Build seit 2017 — durch einen Logikfehler in der Krypto-API des Kernels. In Theoris Artikel heißt es, dass es von Xint Code etwa eine Stunde Scanzeit unter Linux “aufgetaucht sei Krypto/ Subsystem,” mit “einer Bedieneraufforderung, keine Nutzung.”

Theori ist kein Startup, das versucht, Aufmerksamkeit zu erregen. Sie sind eines der stärksten offensiven Sicherheitsteams der Welt. Als MMM (mit CMUs PPP und UBCs Maple Bacon) haben sie DEF CON CTF neun Mal gewonnen. Außerdem belegten sie im Finale der AI Cyber Challenge der DARPA den dritten Platz. Xint Code ist das System, das sie gebaut haben.

Wenn Theori sagt “eine Eingabeaufforderung, eine Stunde”, gehe ich standardmäßig davon aus, dass sie wahrscheinlich genau das getan haben.

Der Fehler ist wichtig. Wichtiger ist die Art und Weise, wie es gefunden wurde.

Copy Fail ist ein Dirty Pipe-Geschwister, das sich in der Krypto-API versteckt

Bevor wir auf die Auswirkungen eingehen, lohnt es sich, zu ergründen, was der Fehler eigentlich ist.

Der nächstgelegene Referenzpunkt ist Dirty Pipe (CVE-2022-0847), das Linux LPE 2022, mit dem ein nicht privilegierter Benutzer Daten in den Seitencache schreibgeschützter Dateien, einschließlich Setuid-Binärdateien, einfügen kann.

Copy Fail ist dieselbe Klasse von Primitiven in einem anderen Subsystem. Die In-Place-Optimierung 2017 in algif_aead Ermöglicht es einer Seitencache-Seite, in der beschreibbaren Ziel-Scatterlist des Kernels für eine AEAD-Operation zu landen, die über eine übermittelt wird AF_ALG Buchse. Ein nicht privilegierter Prozess kann dann spleißen() in diesen Socket und führen Sie einen kleinen, gezielten Schreibvorgang in den Seitencache einer Datei durch, die ihm nicht gehört.

Vier Eigenschaften machen dies in Containerumgebungen gefährlich:

1. Kein Race-Fenster, kein Kernel-Offset. Dies ist ein geradliniger Logikfehler. Zuverlässigkeit ist nicht probabilistisch und dasselbe Skript funktioniert über alle Verteilungen hinweg.
2. Der Seitencache wird freigegeben. Ein Schreibvorgang aus einem Container wirkt sich auf den Cache der Hostseite und damit auf alle anderen Mandanten auf diesem Host aus.
3. Das Primitiv ist klein. Ein paar Bytes reichen aus, wenn Sie in einer Setuid-Binärdatei auf die richtige Stelle abzielen.
4. Der Fehler ist in jeder größeren Distribution vorhanden. Der Fehler ist seit 2017 praktisch in jeder größeren Distribution vorhanden.

Warum wurde es fast ein Jahrzehnt lang verpasst? Wahrscheinlich, weil Krypto/ wird aus der Krypto-Perspektive eingehend geprüft, wobei nach Eigenschaften wie IND-CPA-Sicherheit, Nebenkanälen und Parametervalidierung gesucht wird. Bei Copy Fail geht es im Wesentlichen darum, woher der Speicher stammt und ob der Kernel jemals darüber schreiben sollte. Das ist eine andere Art von Frage und wahrscheinlich auch der Grund, warum sie übersehen wurde.

Die Überschrift ist nicht der Fehler, sondern die Suchbedingungen.

Jedes wichtige Sicherheitstool, von der statischen Analyse bis hin zu Fuzzern, hat erstaunlich weit verbreitete Fehler gefunden, die seit Jahren lauerten. Ich finde es immer komisch, wenn Leute darauf hinweisen “KI hat 500 neue Fehler gefunden”, da Projekte wie OSS-fuzz und Mayhem das schon seit Jahren tun.

Was sich geändert hat ist Wer können das Tool steuern und wie schnell sie Ergebnisse erzielen können.

Dieselbe Systemklasse, die dies für ein Team wie Theori produziert, kann plausibel nützliche Ergebnisse für jemanden mit weitaus weniger Erfahrung liefern. Die Fähigkeitskurve für die Verwendung eines Tools zur Erkennung schwerwiegender Schwachstellen ähnelt zunehmend der Fähigkeitskurve zum Lesen seiner Ausgabe.

Daraus ergeben sich einige Konsequenzen:

• Die Validierungsinfrastruktur wird kritisch. Es wird immer billiger, plausibel aussehende Exploits zu erstellen, daher wird es wichtig, schnell zu bestätigen, ob sie real sind. Ohne Validierung ist ein Bericht nur Lärm. Mit einem funktionierenden PoC für Ihren Build ist es umsetzbar. Bugcrowd sieht gerade viel davon (wir nennen es “sloptimismus”)
• VDPs und Offenlegungspipelines sind jetzt tragfähig. Jede Organisation, die Software ausliefert, benötigt eine koordinierte Offenlegungsaufnahme, die eine höhere Ankunftsrate glaubwürdiger Berichte von einer breiteren Gruppe von Reportern aufnehmen kann. “Wir haben keinen Kontakt zur öffentlichen Sicherheit” ist keine vertretbare Haltung mehr.

Es gibt einen offensichtlichen Kontrapunkt: Vielleicht ist das ein Einzelfall. Vielleicht hatte Xint Code Glück in Krypto/, und die nächsten zehn Subsysteme werden nicht so aussehen. Das ist möglich. Aber wir haben dieses Muster schon einmal bei symbolischer Ausführung, Fuzzing und hybriden Ansätzen gesehen. Allerdings hat sich jedes Mal gezeigt, dass die Technologie eine Reihe neuer kritischer Fehler freischaltet, die ernst genommen werden sollten. 

Wo das wichtig ist: Überall dort, wo ein Container die Vertrauensgrenze ist

Die Cloud-native Haltung des letzten Jahrzehnts bestand darin, den Linux-Container als eine Ebene der Tiefenverteidigung zu behandeln. “Führen Sie nicht vertrauenswürdigen Code in einem Container aus, sodass er den Host nicht erreichen kann, selbst wenn er bösartig ist.” Copy Fail übt einen echten Druck auf diese Haltung aus, da der Seitencache hostweit ist und das Primitiv zuverlässig ist. 

Lassen Sie sich nicht vom “hohen” (nicht kritischen) CVSS-Score täuschen. Wenn Ihr Stack nicht vertrauenswürdigen Code ausführt und die Isolationsgeschichte das Wort “Container” enthält, ohne dass direkt danach das Wort “MicroVM,” “gVisor,” oder “dedizierter Host” steht, liegt Copy Fail in Ihrem Bedrohungsmodell vor.

Drei Oberflächen werden heute durch genau diese Annahme freigelegt:

1. Containerplattformen mit mehreren Mandanten auf gemeinsam genutzten Kerneln. Kubernetes-Cluster, die mehrere Mieter auf einem gemeinsam genutzten Kernel ausführen, sind der offensichtliche Fall. “Namespace-Isolation” deckt diese Problemklasse nicht ab.
2. CI/CD-Runner führen nicht vertrauenswürdigen Code aus Pull-Anfragen aus. Selbst gehostete GitHub Actions-Runner, gemeinsam genutzte GitLab-Runner, Jenkins-Agenten— überall dort, wo die PR eines Forks einen Build innerhalb eines Containers auf einer mit dem Rest der Organisation gemeinsam genutzten Infrastruktur auslösen kann. Diese Oberfläche ist seit Jahren ein bekanntes weiches Ziel.
3. Sandboxen zur Codeausführung von KI-Agenten. Eine schnell wachsende Kategorie. Jedes System, das es einem Modell ermöglicht, Shell-Befehle auszuführen oder beliebigen Code innerhalb eines Containers auszuführen, vertraut implizit dieser Grenze. Einige Plattformen sind auf MicroVMs oder gVisor umgestiegen. Viele haben das nicht getan.

Was unter Copy Fail nicht kaputt geht, ist genau das, was überhaupt kein Linux-Container war. AWS Lambda und Fargate laufen auf Firecracker-Mikro-VMs—separate Kernel pro Mandant, kein gemeinsam genutzter Seitencache. Cloudflare Workers laufen auf V8-Isolaten, ohne Linux-Kernel im Bedrohungsmodell. gVisor fügt einen User-Space-Kernel ein, der den Host nicht gemeinsam nutzt algif_aead. Das Muster ist konsistent: Die Grenzen, die gelten, sind diejenigen, die keinen gemeinsamen Kernel haben.

Was sich für Verteidiger ändert

Patch-Zyklen, Schwachstellenbudgets und CVE-Priorisierung basieren alle auf einer versteckten Annahme: dass das Finden eines Fehlers in Kernel-Qualität teuer ist, sodass das Angebot an neuen Fehlern grob dadurch begrenzt wird, wie viele Leute suchen. Copy Fail zeigt, dass die Annahme in Zukunft falsch ist.

Ich sehe drei praktische Implikationen:

• Shared-Kernel-Multi-Tenancy ist ein riskanterer Standard als früher. Wenn Ihre Isolationsgeschichte “Container auf einem gemeinsam genutzten Hostkernel” ist, benötigt das Bedrohungsmodell eine Hardware- oder VM-Grenze und keine Namespace-Grenze. (Container waren ohnehin nie als Sicherheitsgrenze gedacht.)
• Sie benötigen eine Art automatisiertes kontradiktorisches Testen in Ihrer Pipeline. Wenn Tools solche Fehler schnell finden können, möchten Sie, dass ähnliche Funktionen vor der Veröffentlichung auf Ihren eigenen Code gerichtet werden, nicht nach der Offenlegung.
• Sie brauchen eine Möglichkeit, externe Erkenntnisse aufzunehmen. Das bedeutet einen funktionierenden VDP, eine überwachte Aufnahme und idealerweise eine Bug-Bounty oder Ähnliches. Nicht, weil es schön wäre, — zu haben, denn das Volumen und die Qualität eingehender Berichte werden wahrscheinlich zunehmen.

Eine Anmerkung zu den Forschern

Theori wurde von Leuten gegründet, die ich zunächst unterrichten und dann beobachten durfte, wie sie zu einigen der elitärsten Hacker der Welt wurden. Sie haben sich nicht auf die Entwicklung von KI-Exploits konzentriert, um einem Trend nachzujagen. Sie haben sich umgedreht, weil die Mathematik es jetzt begünstigt.

Theori ist hier nicht allein. Die meisten der besten Schwachstellenforscher, die ich kenne —Menschen, die routinemäßig Millionen an verantwortungsvoller Offenlegung verdienen—, nutzen KI alle, um produktiver zu sein. Das ist keine schlechte Sache. In gewisser Weise bedeutet dies, dass bestimmte Problemklassen schneller gelöst werden und Experten zu schwierigeren Problemen übergehen können.

Was sich geändert hat, ist die Basislinie

Copy Fail ist keine Geschichte über einen einzelnen Fehler oder über die Werkzeuge eines Teams. Es handelt sich um einen Datenpunkt, bei dem die Kosten für die Suche nach tiefen Logikfehlern möglicherweise um etwa eine Größenordnung gesunken sind.

Wenn Ihr Bedrohungsmodell Kernel-LPEs immer noch als selten budgetiert, haben Sie wahrscheinlich Wochen Zeit, dies zu aktualisieren—nicht Jahre.