Eine Linux-Sicherheitslücke aus dem Jahr 2017 — und warum jetzt gehandelt werden muss

Über neun Jahre lag der Fehler unbemerkt im Linux-Kernel. Ende April 2026 wurde er öffentlich bekannt — zusammen mit einem 732 Byte kleinen Exploit, der auf praktisch jeder größeren Linux-Distribution Root-Rechte verschafft. Was Systemadministratoren jetzt wissen sollten.

Was passiert ist?

Am 29. April 2026 haben Sicherheitsforscher von Theori und Xint Code eine Schwachstelle im Linux-Kernel öffentlich gemacht, die seit August 2017 in praktisch jedem Mainstream-Kernel schlummert. Die Lücke trägt die Kennung CVE-2026-31431 und den Spitznamen „Copy Fail“. Mit einem CVSS-Score von 7,8 ist sie als hochkritisch eingestuft — und steht seit wenigen Tagen nach der Veröffentlichung im Known Exploited Vulnerabilities Catalog der US-amerikanischen CISA.

Der Bug erlaubt es einem lokalen, unprivilegierten Nutzer, sich innerhalb von Sekunden Root-Rechte zu verschaffen. Konkret: Wer auf einem betroffenen System irgendeinen Account besitzt — sei es ein Webhosting-Kunde, ein CI/CD-Runner-Prozess oder ein Container-Workload — kann zum Administrator werden.

Warum diese Lücke besonders ist?

Linux hatte in der Vergangenheit prominente Privilege-Escalation-Bugs wie Dirty Cow (2016) und Dirty Pipe (2022). Copy Fail unterscheidet sich in drei wesentlichen Punkten:

Klein. Der Proof-of-Concept passt in 732 Byte Python-Code — etwa zehn Zeilen. Keine kompilierten Payloads, keine externen Abhängigkeiten, nur die Standardmodule os, socket und zlib.

Deterministisch. Anders als Dirty Cow, das auf eine Race Condition angewiesen war, läuft der Copy-Fail-Exploit ohne Wiederholungen, ohne Timing-Tricks, ohne Crashes. Ein Skript, eine Ausführung, Root.

Portabel. Derselbe Exploit funktioniert auf Ubuntu, Red Hat Enterprise Linux, SUSE, Amazon Linux und sämtlichen Derivaten — ohne distributionsspezifische Offsets oder Kernel-Versionsprüfungen.

Was technisch dahintersteckt

Der Fehler liegt im kryptografischen Subsystem des Kernels, genauer im Modul algif_aead. 2017 wurde dort eine Performance-Optimierung eingeführt, die sogenannte „In-Place“-Operationen für Authenticated Encryption with Associated Data (AEAD) ermöglichen sollte — also Verschlüsselungsoperationen, bei denen Quelle und Ziel im Speicher identisch sind.

In Kombination mit einem zweiten Kernel-Subsystem, dem splice()-Systemaufruf, entsteht der Angriff: Über das AF_ALG-Socket-Interface lässt sich ein präzise kontrollierter 4-Byte-Schreibzugriff in den Page Cache jeder lesbaren Datei auf dem System erzeugen. Damit kann ein Angreifer das im Speicher gehaltene Abbild einer setuid-Binärdatei wie /usr/bin/su modifizieren — ohne die Datei auf der Festplatte anzufassen — und beim nächsten Aufruf befindet er sich im Root-Kontext.

Besonders heikel: Da der Page Cache zwischen Host und Containern geteilt wird, ist Copy Fail auch ein Container-Escape-Vektor. Wer einen Container kompromittiert, kann von dort aus den Host-Kernel angreifen.

Wer ist betroffen?

Praktisch jede Linux-Installation, die seit August 2017 in Betrieb genommen wurde:

• Ubuntu (alle Versionen vor 26.04 „Resolute“)
• Debian (alle aktuellen Releases)
• Red Hat Enterprise Linux 8, 9, 10
• Rocky Linux, AlmaLinux
• SUSE und openSUSE
• Amazon Linux 2 und 2023
• Fedora, Arch Linux
• Linux Mint (sowohl 21.x- als auch 22.x-Linie)

Die einzige bekannte Ausnahme unter den Mainstream-Distributionen ist Ubuntu 26.04, dessen Kernel den Patch bereits enthält.

Wie kritisch ist das in der Praxis?

Das hängt vom Einsatzszenario ab. Reine Single-Admin-Server, auf denen kein nicht-administrativer Nutzer Code ausführen kann, sind weniger akut bedroht — der Exploit setzt lokalen Zugriff voraus. Brisant wird es überall dort, wo unprivilegierte Nutzer oder Workloads laufen:

• Webhosting mit Shell-Zugang oder PHP-Ausführung
• CI/CD-Runner (GitLab Runner, GitHub Self-Hosted Runners)
• Kubernetes-Worker-Nodes
• Multi-Tenant-Container-Hosts
• Shared-Development-Server
• Jump-Hosts mit mehreren Nutzern

Microsoft Defender hat erste Aufklärungsaktivitäten von Angreifern bereits beobachtet. Aktive Ausnutzung ist damit kein theoretisches Szenario mehr.

Wie wird die Lücke unter Ubuntu geschlossen?

Bei Ubuntu sieht der Stand Anfang Mai 2026 wie folgt aus:

Schritt 1: Offizielle Mitigation einspielen

Canonical hat über die Security Notices USN-8226-1 und USN-8226-2 vom 30. April 2026 ein Update für das kmod-Paket veröffentlicht, das das Laden des angreifbaren Moduls unterbindet. Das Update kommt über den normalen Update-Kanal:

sudo apt update
sudo apt upgrade
sudo reboot

Nach dem Neustart lässt sich verifizieren, dass das Modul tatsächlich nicht mehr geladen ist:

grep -qE '^algif_aead ' /proc/modules 
  && echo "Modul GELADEN — Problem!" 
  || echo "Modul nicht geladen — OK"

Schritt 2: Kernel-Patch nachziehen

Der eigentliche Patch im Kernel-Code wird als regulärer linux-image-Update nachgereicht. Bis dahin wirkt die kmod-Mitigation als wirksamer Riegel — sie macht den Angriffspfad unzugänglich, auch wenn der zugrundeliegende Bug noch im Kernel-Code vorhanden ist. Der Stand der Patch-Verfügbarkeit lässt sich unter ubuntu.com/security/CVE-2026-31431 verfolgen.

Wenn kein Reboot möglich ist

Auf Systemen, deren Wartungsfenster sich nicht spontan öffnen lassen, kann die Sperre auch manuell gesetzt werden:

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

Diese Sperre überlebt einen Reboot und betrifft im Regelbetrieb keine Standardanwendungen: Weder dm-crypt/LUKS, OpenSSL, GnuTLS, NSS, IPsec/XFRM noch SSH nutzen das Modul. Lediglich Anwendungen, die explizit die afalg-Engine adressieren oder direkt AF_ALG-Sockets binden, können beeinträchtigt sein. Eine schnelle Prüfung:

sudo lsof | grep AF_ALG

Empfehlung nach Priorität

Für IT-Verantwortliche mit größerer Server-Landschaft empfiehlt sich eine risikobasierte Priorisierung:

1. Sofort: Multi-Tenant-Container-Hosts, Kubernetes-Nodes, CI/CD-Runner mit nicht vertrauenswürdigen Workloads, Webhosting-Server mit Shell-Zugang oder kundeneigenem Code.
2. Diese Woche: Shared-Development-Server, Test-Umgebungen, alles mit nicht-administrativen Nutzerkonten.
3. Im normalen Patch-Cycle: Single-Admin-Server ohne weitere lokale Nutzer.

Auf Container-Hosts ist die Mitigation grundsätzlich auf dem Host-System anzuwenden — Container teilen sich den Kernel mit dem Host, und Kernel-Module gehören zum Host.

Fazit

Copy Fail ist in mehrfacher Hinsicht ein bemerkenswerter Fall: Eine Performance-Optimierung aus dem Jahr 2017 hat über neun Jahre eine triviale Privilege-Escalation-Lücke offengehalten, die mit moderner KI-gestützter Code-Analyse innerhalb einer Stunde gefunden wurde. Das ist gleichzeitig beunruhigend — wie viele vergleichbare Bugs warten noch in altem Code? — und ermutigend, weil die Werkzeuge zur Entdeckung solcher Lücken sichtbar besser werden.

Für die Praxis heißt das: Updates einspielen, Reboot einplanen, Verifikation durchführen. Bei kritischen Systemen mit Multi-Tenant-Workloads ist das eine Aufgabe, die nicht bis zur nächsten regulären Wartung warten sollte.