TL;DR: Eine fast ein Jahrzehnt alte Optimierung im Linux-Kernel macht es jedem lokalen Nutzer möglich, mit einem 732-Byte-Python-Skript Root-Rechte zu erlangen – auf nahezu jeder Linux-Distribution seit 2017. Kein Race Condition, kein spezielles Wissen, keine Vorkenntnisse erforderlich.
Was ist Copy Fail?
Am 29. April 2026 veröffentlichte das Sicherheitsforschungsteam Xint Code (Theori) eine der ungewöhnlichsten Linux-Schwachstellen der letzten Jahre: CVE-2026-31431, intern „Copy Fail“ genannt.
Die Lücke steckt im algif_aead-Modul des Linux-Kernels – dem Teil, der Verschlüsselungsoperationen aus dem Userspace heraus ermöglicht. Mit einem winzigen Python-Skript kann ein unprivilegierter lokaler Nutzer in Sekunden eine Root-Shell erhalten. Betroffen sind alle Linux-Systeme mit einem Kernel, der zwischen 2017 und dem Patch im April 2026 gebaut wurde.
| Eigenschaft | Details |
|---|---|
| CVE-ID | CVE-2026-31431 |
| CVSS Score | 7.8 (High) |
| Art | Local Privilege Escalation (LPE) |
| Betroffen seit | 2017 (Kernel 4.14+) |
| Exploit-Größe | 732 Bytes Python |
| Veröffentlicht | 29. April 2026 |
| Patch verfügbar | Ja (seit 1. April 2026 im Mainline-Kernel) |
Wie wurde Copy Fail entdeckt?
Das ist der Teil der Geschichte, der die Security-Community mindestens genauso beschäftigt wie die Lücke selbst – denn Copy Fail wurde nicht durch mühsame manuelle Code-Analyse gefunden, sondern durch einen KI-gestützten Scan.
Theori-Forscher Taeyang Lee hatte durch frühere Kernel-CTF-Arbeit die AF_ALG-Angriffsfläche bereits kartiert. Er vermutete, dass der Weg AF_ALG + splice() – also das direkte Einschleusen von Page-Cache-Seiten in das Crypto-Subsystem – ein noch unerforschter Angriffsvektor sein könnte. Anstatt den gesamten Kernel-Crypto-Code manuell zu durchforsten, gab er dem KI-Tool Xint Code einen einzigen Operator-Prompt:
„This is the linux crypto/ subsystem. Please examine all codepaths reachable from userspace syscalls. Note one key observation: splice() can deliver page-cache references of read-only files (including setuid binaries) to crypto TX scatterlists.“
Nach etwa einer Stunde Scan-Zeit war Copy Fail der kritischste Fund – ein Ergebnis, für das ein menschliches Team wahrscheinlich Wochen gebraucht hätte. Laut Theori fand derselbe Scan noch weitere hochkritische Schwachstellen, die sich noch im coordinated disclosure-Prozess befinden.
Das ist ein Wendepunkt: Wenn KI-Tools solche tief vergrabenen Logikfehler in einer Stunde finden können, verändert das die Annahmen hinter jedem Threat Model.
Wie funktioniert die Lücke? (Vereinfacht)
Der Fehler ist kein klassischer Buffer-Overflow, kein Race Condition – er ist ein Logikfehler an der Schnittstelle von drei Kernel-Komponenten, die alle für sich genommen harmlos waren:
Die drei Zutaten
- AF_ALG + splice() (2015): Linux erlaubt es, über AF_ALG-Sockets Verschlüsselungsoperationen aus dem Userspace durchzuführen. Mit
splice()können dabei Page-Cache-Seiten (also der RAM-Cache einer Datei) direkt an das Crypto-Subsystem übergeben werden – ohne Kopie. - authencesn Scratch-Write (2015): Der Crypto-Algorithmus
authencesn– verwendet für IPsec mit 64-Bit Extended Sequence Numbers – schreibt während der Entschlüsselung 4 Bytes hinter das eigentlich erlaubte Ausgabe-Gebiet. Das war nie als Bug gedacht; er nutzt den Puffer als temporären Zwischenspeicher. Kein anderer Standard-AEAD-Algorithmus im Kernel tut das. - In-Place-Optimierung (2017): Commit
72548b093ee3optimiertealgif_aeadso, dass Eingabe und Ausgabe im selben Scatterlist-Bereich landen. Das bedeutet: Die Page-Cache-Seiten aus Schritt 1 landeten nun in einem beschreibbaren Scatterlist. Und der Scratch-Write aus Schritt 2 landet damit direkt in den Page-Cache-Seiten einer beliebigen Datei.
Niemand hat die drei Punkte miteinander verbunden – und so blieb die Lücke fast 9 Jahre unentdeckt.
Was passiert beim Angriff?
Der Angreifer leitet eine Datei (z. B. /usr/bin/su) per splice() durch eine Pipe in einen AF_ALG-Socket. Dort werden mithilfe von authencesn kontrollierte 4 Bytes an einer selbst gewählten Stelle in den RAM-Cache der Datei geschrieben – an der Stelle im Arbeitsspeicher, von der der Kernel beim nächsten Aufruf liest.
Der entscheidende Punkt: Die Datei auf der Festplatte bleibt unverändert. Nur der im RAM gecachte Inhalt wird manipuliert. Dateisystem-Integritätstools wie AIDE oder Tripwire, die Prüfsummen der Dateien auf der Festplatte vergleichen, merken nichts. Beim nächsten Aufruf von su lädt der Kernel jedoch die manipulierte Version aus dem RAM – und der injizierte Code läuft mit Root-Rechten.
Was macht Copy Fail so gefährlich?
Copy Fail ist nicht nur eine weitere Kernel-LPE. Es gibt mehrere Eigenschaften, die es von früheren Lücken wie Dirty Cow oder Dirty Pipe abheben:
- Kein Race Condition: Dirty Cow erforderte ein Timing-Fenster und scheiterte manchmal oder crashte das System. Copy Fail ist ein deterministischer Logikfehler – er funktioniert beim ersten Versuch, jedes Mal.
- Kein Distro-spezifisches Tuning: Dasselbe 732-Byte-Python-Skript funktioniert unverändert auf Ubuntu, Amazon Linux, RHEL und SUSE – ohne Anpassungen, ohne Neucompilierung.
- Extrem klein: Der Exploit benötigt nur Python 3.10+ und ausschließlich Standard-Bibliotheken (
os,socket,zlib). Keine kompilierten Payloads, keine externe Abhängigkeiten. - Unsichtbar für On-Disk-Tools: Da nur der RAM-Cache verändert wird, schlägt keine Signatur-/Hash-basierte Dateiintegritätsprüfung an.
- Container Escape: Der Page-Cache wird über Containergrenzen hinweg geteilt. Copy Fail ist damit nicht nur eine lokale Rechteeskalation, sondern auch ein Container-Escape-Primitiv – relevant für Kubernetes-Nodes, CI/CD-Runner und Cloud-Umgebungen. Theori kündigt dazu einen zweiten Teil des Write-ups an.
Wer ist betroffen?
Kurze Antwort: Nahezu jedes Linux-System, das seit 2017 gebaut wurde.
Direkt getestet und bestätigt wurden:
- Ubuntu 24.04 LTS (Kernel 6.17.0-1007-aws)
- Amazon Linux 2023 (Kernel 6.18.8-9.213.amzn2023)
- RHEL 10.1 (Kernel 6.12.0-124.45.1.el10_1)
- SUSE 16 (Kernel 6.12.0-160000.9-default)
Betroffen sind außerdem Debian, Arch Linux, Fedora, Rocky Linux, AlmaLinux, Oracle Linux sowie nahezu alle Embedded-Linux-Systeme mit entsprechendem Kernel.
Nicht betroffen: Ubuntu 26.04 (Resolute) und spätere Versionen – diese liefern einen Kernel aus, der den Fix bereits enthält.
Besonders kritisch ist die Lücke für:
- Multi-Tenant-Server (Shared Dev-Boxen, Jump-Hosts, Build-Server)
- Kubernetes-Cluster & Container-Farms
- CI/CD-Runner (GitHub Actions self-hosted, GitLab Runner, Jenkins Agents) – hier reicht ein manipulierter Pull Request, um Root auf dem Runner zu erlangen
- Cloud-SaaS mit User-Code-Ausführung (Notebooks, Serverless Functions, Agent-Sandboxes)
Der Exploit – Wie nutzen Angreifer die Lücke aus?
Hinweis: Die folgenden Informationen dienen ausschließlich defensiven Zwecken – dem Verständnis der Lücke, dem Testen eigener Systeme und der Validierung von Patches.
Das Forschungsteam von Theori hat den Proof-of-Concept-Exploit unter verantwortlichen Bedingungen veröffentlicht:
Das Skript ist 732 Bytes groß, benötigt Python 3.10+ und läuft ohne Root-Rechte. Standardmäßig zielt es auf /usr/bin/su. Es schreibt Shellcode in den RAM-Cache des Binaries und führt es anschließend aus – der Angreifer erhält eine Root-Shell.
Wichtig: Der Page-Cache-Write ist nicht persistent – nach einem Neustart ist der manipulierte Cache weg. Die Root-Shell, die man in der Zwischenzeit erlangt hat, ist es jedoch nicht.
Wie schließt man die Lücke?
✅ Schritt 1: Kernel-Update (dauerhafter Fix)
Der einzige echte Fix ist das Einspielen eines gepatchten Kernels, der Upstream-Commit a664bf3d603d enthält. Dieser Commit macht die 2017er In-Place-Optimierung rückgängig.
Ubuntu / Debian:
sudo apt update && sudo apt upgrade linux-image-$(uname -r)
sudo rebootRHEL / AlmaLinux / Rocky Linux:
sudo dnf clean metadata && sudo dnf upgrade kernel
sudo rebootSUSE / openSUSE:
sudo zypper update kernel-default
sudo rebootAmazon Linux 2023:
sudo dnf update kernel
sudo rebootNach dem Reboot prüfen:
uname -r⚠️ Schritt 2: Sofortmaßnahme (solange kein Patch verfügbar)
Je nach Distribution gibt es unterschiedliche Vorgehensweisen:
Debian/Ubuntu (algif_aead ist ein ladbares Modul):
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || true⚠️ RHEL-Familie (AlmaLinux, Rocky, CloudLinux) – modprobe funktioniert NICHT!
Auf RHEL-basierten Systemen ist algif_aead fest in den Kernel eingebaut (CONFIG_CRYPTO_USER_API_AEAD=y). Die modprobe.d-Methode läuft ohne Fehlermeldung, hat aber keinerlei Wirkung und erzeugt ein falsches Sicherheitsgefühl. Stattdessen muss der Kernel-Bootparameter gesetzt werden:
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo systemctl reboot --forceNach dem Neustart prüfen:
cat /proc/cmdline | grep initcall_blacklistWenn initcall_blacklist=algif_aead_init in der Ausgabe erscheint, ist die Mitigation aktiv.
🔒 Schritt 3: Zusätzliche Absicherung
AF_ALG per Seccomp blockieren (für Container und untrusted Workloads):
# In der Seccomp-Policy socket(AF_ALG, ...) blockieren
# Für Docker: --security-opt seccomp=profile.jsonPrüfen ob AF_ALG aktiv genutzt wird:
lsof | grep AF_ALGKeine Ausgabe = kein Prozess nutzt aktuell AF_ALG direkt.
Was ist NICHT betroffen: dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, SSH – diese greifen alle direkt auf die interne Kernel-Crypto-API zu und gehen nicht über AF_ALG.
Disclosure-Timeline
| Datum | Ereignis |
|---|---|
| 23. März 2026 | Meldung an das Linux Kernel Security Team |
| 24. März 2026 | Initiale Bestätigung erhalten |
| 25. März 2026 | Patches vorgeschlagen und gereviewed |
| 1. April 2026 | Patch in Mainline-Kernel commited (a664bf3d603d) |
| 22. April 2026 | CVE-2026-31431 vergeben |
| 29. April 2026 | Öffentliche Disclosure auf copy.fail |
| 30. April 2026 | Ubuntu kmod-Paket mit Mitigation veröffentlicht |
| 1. Mai 2026 | AlmaLinux gepatchte Kernel in Production-Repos verfügbar |
Was Copy Fail über die Zukunft der Schwachstellenforschung sagt
Abseits der technischen Details ist Copy Fail ein Signal. Der Fehler versteckte sich fast 9 Jahre in einem der am besten überprüften Teile des Linux-Kernels – weil niemand diese spezifische Kombination aus drei separaten Änderungen betrachtet hatte. Sicherheitsreviews der Crypto-Implementierungen fokussierten sich auf kryptographische Korrektheit, Side-Channels und Parametervalidierung. Die Frage „Woher kommt dieser Speicher und sollte der Kernel überhaupt hineinschreiben?“ wurde schlicht nicht gestellt.
Eine KI hat die Antwort in einer Stunde gefunden.
Die Konsequenz für jeden Sysadmin und Security-Verantwortlichen: Wenn Tools solche Fehler in dieser Geschwindigkeit finden können, sind sie auch in eurem Code – bevor ihr sie findet. Wer seinen Threat Model noch auf der Annahme aufbaut, dass Kernel-LPEs selten und schwer zu finden sind, sollte dieses Modell jetzt aktualisieren.
Fazit
Copy Fail ist ein Paradebeispiel für wie aus drei harmlosen, separat vernünftigen Entscheidungen über neun Jahre hinweg eine kritische Schwachstelle entsteht. Mit einem einzigen, winzigen Python-Skript können unprivilegierte Nutzer auf nahezu jedem Linux-System seit 2017 Root-Rechte erlangen – zuverlässig, schnell und weitgehend unsichtbar für traditionelle Sicherheitstools.
Die wichtigsten Maßnahmen in Kurzform:
- Jetzt patchen – Kernel-Update auf allen betroffenen Systemen einspielen
- Sofortmaßnahme –
algif_aeaddeaktivieren (je nach Distro unterschiedlich!) - Monitoring – Unerwartete AF_ALG-Nutzung und Setuid-Binary-Manipulationen überwachen
- Container-Isolation überdenken – Namespaces allein sind kein ausreichender Schutz