Es gibt Schwachstellen, die wirken wie schlechte Nachrichten – und es gibt solche, die fühlen sich an wie ein Stromausfall mitten im Maschinenpark. CVE-2026-31431, von ihren Entdeckern auf den Namen Copy Fail getauft, gehört in die zweite Kategorie. Ein Fehler, der seit 2017 ungestört im Linux-Kernel schlummert. Ein Exploit-Skript von 732 Bytes. Ein Sprung vom unprivilegierten Account direkt zu Root – auf Ubuntu, Debian, Red Hat, SUSE, Amazon Linux und allen Cloud-Distributionen, die darauf aufsetzen. Keine Race Condition, keine wackelige Heap-Manipulation, kein Glück: Die Lücke ist deterministisch. Wer das Skript ausführt, wird Root.

Seit dem 1. Mai 2026 steht CVE-2026-31431 auf dem Known Exploited Vulnerabilities-Katalog der US-Behörde CISA. Die Patch-Frist für US-Bundesbehörden läuft am 15. Mai 2026 ab. Für deutsche Unternehmen gibt es keine vergleichbare gesetzliche Frist – sehr wohl aber eine technische: Die ersten realen Angriffe gegen europäische Industrieunternehmen sind bereits dokumentiert.

Was Copy Fail technisch tut

Die Schwachstelle sitzt tief im Kernel-Subsystem für Kryptografie, genauer: im algif_aead-Modul, der Userspace-Schnittstelle der Crypto-API über AF_ALG-Sockets. Die Kette aus drei vermeintlich harmlosen Zutaten – AF_ALG, splice() und der Algorithmus authencesn(hmac(sha256),cbc(aes)) – ergibt zusammen einen kontrollierten 4-Byte-Schreibzugriff in den Page Cache jeder vom Angreifer lesbaren Datei.

Verursacher ist eine Optimierung aus dem Jahr 2017 (Commit 72548b093ee3): Damals wurde für AEAD-Operationen ein In-Place-Verfahren eingeführt. Quell- und Ziel-Scatterlist zeigen seitdem auf denselben Speicher, die Tag-Pages werden über sg_chain() verkettet. Liefert ein Userspace-Programm seine Daten via splice() in den Socket, referenzieren diese Tag-Pages plötzlich Seiten des Page Cache der gespliceten Datei. Der Extended Sequence Number-Reorder-Schritt der authencesn-Implementierung schreibt vier Bytes als Scratch-Space – und landet damit nicht im erwarteten Pufferspeicher, sondern in einer Datei, auf die der angreifende Prozess sonst nie schreibend zugreifen dürfte. Klassisches Privilege-Escalation-Pattern: Erst das eigene Sudoers-File patchen, dann su -.

Die saubere Demo der Sicherheitsforscher von Theori und Xint passt in 732 Bytes Python. Sie funktioniert ohne Anpassung auf jeder getesteten Distribution – kein Suchen nach Symbolen, keine Kernel-Versionsabfragen, keine Architektur-Offsets. Inzwischen kursieren auf Untergrundforen Implementierungen in Go und Rust, die in Build-Pipelines einfacher zu integrieren sind.

Wer ist betroffen?

Praktisch jede produktive Linux-Installation der letzten acht Jahre. Konkret bestätigt:

  • Ubuntu 18.04 LTS, 20.04 LTS, 22.04 LTS, 24.04 LTS sowie 25.10
  • Debian 11 (Bullseye), 12 (Bookworm), 13 (Trixie)
  • Red Hat Enterprise Linux 8, 9 sowie alle Rebuilds (AlmaLinux, Rocky Linux, Oracle Linux)
  • SUSE Linux Enterprise Server 15 SP4 bis SP6 sowie openSUSE Leap 15.5/15.6
  • Amazon Linux 2 und 2023 – inkl. nahezu aller AWS-AMIs
  • CloudLinux, Azure Linux, Google COS
  • Container-Basisimages, sofern der Host-Kernel ungepatcht bleibt – denn der angreifbare Code lebt im Kernel, nicht im Userspace des Containers

Kein Fix ist nötig für Systeme, die algif_aead deaktiviert haben oder auf Distributionen mit grsecurity-Patchset und striktem /proc/sys/kernel/modules_disabled laufen. Die Realität deutscher Mittelständler und Cloud-Workloads sieht freilich anders aus: Standard-Kernel, Standard-Module, Standard-Risiko.

Wie real ist die Bedrohung gerade?

Die Privatoffenlegung erfolgte am 22. April 2026. Bereits eine Woche später kursierte funktionierender Exploit-Code auf den einschlägigen Foren. Bis zum 1. Mai bestätigten mehrere Threat-Intelligence-Anbieter Angriffe gegen drei Zielgruppen:

  1. US-amerikanische Think-Tanks (klassische Spionage-Profile)
  2. Cloud-Service-Provider (Multi-Tenant-Container-Hosts, in denen ein einziger Mietkunde via Copy Fail die Mandanten-Trennung aushebeln kann)
  3. Europäische Fertigungsunternehmen – darunter mindestens zwei deutsche Industrieziele, deren Namen noch nicht öffentlich sind. Die Angreifer kombinieren Copy Fail mit klassischen Phishing-Webshells: Erst landet eine PHP-Shell auf einem schlecht gepatchten Webserver, dann hebt Copy Fail diese Shell vom www-data-Konto auf Root und damit auf den Hypervisor-Zugang.

Diese Eskalationskette ist es, die Copy Fail für den Mittelstand so gefährlich macht. Eine LPE alleine ist im Bedrohungsmodell vieler Unternehmen unterbewertet – schließlich braucht der Angreifer ja erstmal lokalen Zugriff. Kombiniert mit jeder beliebigen Webanwendungsschwachstelle, jedem kompromittierten Wartungszugang und jedem ungepatchten Container wird daraus ein einstufiger Pfad zur vollständigen Server-Übernahme.

Patch-Status der Distributionen

Stand 4. Mai 2026 stehen die folgenden Kernel-Updates bereit:

  • Ubuntu: USN-7421-1 (linux 5.15.0-145, 6.8.0-58, 6.11.0-29) – seit 30. April
  • Debian: DSA-5928-1 (linux 6.1.135-1, 6.12.27-1) – seit 1. Mai
  • Red Hat: RHSA-2026:2811 für RHEL 9.4/9.5, RHSA-2026:2812 für RHEL 8.10 – seit 1. Mai
  • SUSE: SUSE-SU-2026:1490-1 für SLES 15 SP6 – seit 2. Mai
  • Amazon Linux: ALAS2-2026-2664 (AL2) und ALAS2023-2026-1118 (AL2023) – seit 1. Mai
  • AlmaLinux: ALSA-2026:2811 – seit 1. Mai
  • CloudLinux: kmod-Live-Patch über KernelCare seit 30. April, regulärer Kernel-Update seit 2. Mai

Wer Live-Patching einsetzt (kpatch, kGraft, KernelCare, Ksplice), bekommt in der Regel Hot-Fixes ohne Reboot. Ohne Live-Patching führt der Weg über einen Kernel-Update mit anschließendem Neustart – im 24/7-Produktionsumfeld ein Posten, der echte Wartungsfenster braucht.

Workarounds für Systeme, die nicht sofort gepatcht werden können

Nicht jede Maschine kann am selben Tag rebootet werden. Für die Übergangszeit gibt es zwei brauchbare Härtungen, die das angreifbare Modul ausschalten oder unzugänglich machen:

1. Modul auf eine Blacklist setzen:

echo "blacklist algif_aead" > /etc/modprobe.d/blacklist-copyfail.conf
echo "install algif_aead /bin/false" >> /etc/modprobe.d/blacklist-copyfail.conf
update-initramfs -u   # Debian/Ubuntu
dracut -f             # RHEL/SUSE

2. AF_ALG-Sockets per seccomp blockieren – sinnvoll in Container-Hosts und Sandbox-Profilen. Für Docker/Podman:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [{ "index": 0, "value": 38, "op": "SCMP_CMP_EQ" }]
    }
  ]
}

Beide Maßnahmen sind kein Ersatz für den Patch, kaufen aber Zeit, falls ein Reboot wirklich erst zum nächsten Wartungsfenster möglich ist. Wichtig: Anwendungen, die AF_ALG aktiv nutzen (manche WireGuard-Userspace-Tools, einige IPSec-Helfer, ein paar HSM-Wrapper) brechen unter dieser Härtung – vorher prüfen.

Detection: Wie erkennen Sie einen Angriff?

Copy Fail hinterlässt Spuren, die in einem normal konfigurierten Audit-Daemon sichtbar werden. Drei Signale, auf die SOC-Teams achten sollten:

auditd-Regel für Aufrufe von socket(AF_ALG, ...) durch ungewöhnliche Prozesse:

-a always,exit -F arch=b64 -S socket -F a0=38 -k afalg_socket
-a always,exit -F arch=b32 -S socket -F a0=38 -k afalg_socket

Falco-Regel für AF_ALG aus untypischen Containern:

- rule: Suspicious AF_ALG socket
  desc: AF_ALG socket created from non-system process
  condition: evt.type=socket and evt.arg.domain=AF_ALG
             and not proc.name in (cryptsetup, wpa_supplicant)
  output: AF_ALG socket from %proc.name (uid=%user.uid container=%container.id)
  priority: WARNING

EDR-Telemetrie: Suchen Sie nach Schreibzugriffen auf /etc/sudoers, /etc/shadow, /root/.ssh/authorized_keys oder /etc/cron.d/* durch Prozesse, die nicht als Root laufen, aber kurz darauf einen UID-0-Prozess starten. Genau das ist die Standard-Eskalationskette der bisher beobachteten Exploits.

Was sollten Sie heute konkret tun?

Fünf Schritte, in dieser Reihenfolge:

Schritt 1 – Inventarisieren. Welche Linux-Systeme laufen produktiv – inklusive Container-Hosts, Edge-Appliances, Build-Server, Entwickler-Workstations? Eine schnelle Inventur über Ihr Configuration-Management-Tool (Ansible, Puppet, Salt) reicht für den ersten Überblick.

Schritt 2 – Priorisieren. Multi-Tenant-Hosts, jede Maschine mit Web-Erreichbarkeit, jeder CI/CD-Runner, jeder Bastion-Host gehören in die erste Patch-Welle. Interne Datenbankserver und Backup-Knoten in die zweite.

Schritt 3 – Patchen oder härten. Wo möglich, sofort der Distributions-Update einspielen und neu starten. Wo nicht, die oben beschriebenen Workarounds anwenden – mit dokumentiertem Wartungsfenster für den späteren Neustart.

Schritt 4 – Detektieren. Die auditd- und Falco-Regeln in das eigene SIEM/EDR übernehmen. Drei Tage nach Patch-Stichtag rückwärts in den Logs nach Auffälligkeiten suchen – die Schwachstelle wurde bereits seit dem 22. April aktiv ausgenutzt.

Schritt 5 – Dokumentieren. Für NIS2-pflichtige Unternehmen: Patch-Status, Detektionsergebnisse und gegebenenfalls Incident-Tickets sind Bestandteile der Nachweise, die das BSI bei einer Prüfung sehen will. Auch ohne NIS2-Pflicht ist eine saubere Dokumentation Gold wert, wenn drei Monate später ein Auditor fragt: "Wann haben Sie Copy Fail geschlossen?"

Die strukturelle Lehre

Copy Fail ist mehr als nur eine weitere CVE. Sie ist ein Lehrstück darüber, wie unentdeckter Code im Kernel jahrelang reifen kann, bis ein Forscher die richtige Kombination aus drei Subsystemen testet. Sie ist ein Signal, dass Patch-Reife – also die Zeit zwischen Verfügbarkeit eines Patches und produktivem Rollout – im Mittelstand häufig zu lange dauert. Und sie ist eine Erinnerung, dass Privilege Escalation nicht weniger gefährlich ist als Remote Code Execution: Ein Angreifer mit einer Webshell und Copy Fail ist genauso tief im System wie einer mit einer pre-auth-RCE, nur einen Schritt später.

Wer seine Informationssicherheit 2026 ernst nimmt, baut Patch-Management nicht mehr als Quartalsritual, sondern als kontinuierlichen Prozess mit klaren Service-Levels. Wer das nicht selbst leisten kann oder will, holt sich Unterstützung – etwa über unsere Leistungen rund um Vulnerability- und Schwachstellenmanagement oder direkt im persönlichen Gespräch.

Fazit

Copy Fail ist deterministisch, weit verbreitet, aktiv ausgenutzt – und gepatcht. Die Frage ist nicht, ob Ihre Linux-Flotte verwundbar ist. Sondern wann sie es nicht mehr ist. Wer bis Mitte Mai 2026 nicht alle relevanten Systeme aktualisiert hat, sollte spätestens jetzt das nächste Wartungsfenster eintakten – und in der Zwischenzeit zumindest die Detektion scharfschalten. Eine 732-Byte-Skriptdatei kann eine Menge Schaden anrichten. Drei Befehle und ein Reboot reichen, sie wirkungslos zu machen.