CVE-2026-31431 'copyfail': Was DACH-Cloud-Betreiber jetzt patchen müssen - aktive Exploitation bestätigt

5 Mai 2026

6 Min. Lesezeit

CISA hat CVE-2026-31431 am 04.05.2026 in den Known-Exploited-Vulnerabilities-Katalog aufgenommen. CrowdStrike bestätigt aktive Ausnutzung in freier Wildbahn. Betroffen: jede Linux-Instanz mit Kernel ab 2017 und geladenem AF_ALG-Modul. Für DACH-Cloud-Betreiber heißt das in der Praxis: nahezu jede produktive EC2-, Compute-Engine- und Azure-VM-Flotte braucht innerhalb der nächsten 72 Stunden einen Patch oder einen sauberen Workaround.

Das Wichtigste in Kürze

SSH-Foothold ist die reale Eintrittstür: CVE-2026-31431 ist nicht remote ausnutzbar, sondern braucht eine lokale Sitzung. In Cloud-Umgebungen mit geleakten Keys, schwachen Bastion-Konfigurationen oder kompromittierten CI-Runnern reicht genau das. Die Lücke verwandelt einen normalen Shell-Zugang in Root.
Workload-Reichweite ist breit, nicht tief: Betroffen sind AWS EC2, Azure VMs, GCP Compute Engine, Hetzner-Server, Container-Hosts, Kubernetes-Worker-Nodes, CI-Runner und SSH-Bastions. Managed Container-Services (Fargate, Cloud Run) sind nur indirekt betroffen, sofern der zugrundeliegende Host ungepatcht ist.
Workaround vor Patch ist legitim: Wer nicht in 72 Stunden patchen kann, deaktiviert AF_ALG via modprobe-Blacklist. Das verhindert den Exploit, kostet aber Performance bei Crypto-Operationen, die das Kernel-Interface nutzen. Vor Produktion testen.

Verwandt:Container-Image-Diet 2026: Distroless, Wolfi, Chainguard / State of FinOps 2026

Was am 04.05.2026 passiert ist

Was ist CVE-2026-31431? CVE-2026-31431, intern als „copyfail“ benannt, ist eine lokale Privilege-Escalation-Schwachstelle im Linux-Kernel. Sie liegt in der AF_ALG-Schnittstelle des Kernel-Crypto-API und kombiniert einen Fehler in der ONC-ESN-Komponente mit einem Page-Cache-Write-Primitiv. Ein Angreifer mit normaler Shell auf dem System eskaliert damit auf Root-Rechte. Betroffen sind alle Linux-Distributionen, deren Kernel die AF_ALG-Implementierung aus 2017 oder neuer enthält.

Der Proof-of-Concept von Theori ist ein 732-Zeilen-Python-Exploit. Auffällig ist nicht die Größe, sondern die Art der Entdeckung: Theoris autonomer KI-Agent hat die Lücke gescannt, das Exploit-Primitiv konstruiert und den PoC in rund einer Stunde fertiggestellt. CISA hat die Lücke noch am selben Tag in den KEV-Katalog aufgenommen, CrowdStrike Threat Intelligence bestätigt aktive Ausnutzung.

Für US-Bundesbehörden gilt mit der KEV-Aufnahme eine harte Patch-Frist. Für DACH-Organisationen ist das nicht bindend, aber das Signal ist eindeutig: ein öffentlicher Exploit plus aktive Ausnutzung plus breite Distro-Abdeckung erzeugt Patch-Druck unabhängig von der Aufsichtsbehörde.

Wo Cloud-Workloads konkret betroffen sind

Die Reichweite über die Hyperscaler hinweg ist hoch. AWS Linux 2 und Amazon Linux 2023 laden AF_ALG per Default. Azure Ubuntu, Azure RHEL und Azure SUSE genauso. Google Compute Engine mit Debian-, Ubuntu- oder Container-Optimized-OS ebenfalls. Wer EC2-Auto-Scaling-Groups, AKS-Worker-Nodes, GKE-Knoten oder selbst gehostete Kubernetes-Cluster betreibt, sollte den Patch-Stand pro Image und pro Node-Pool prüfen.

CI- und Build-Infrastruktur ist die zweite stille Risikozone. GitHub-Actions-Self-Hosted-Runner, GitLab-Runner auf eigenen Hosts, Jenkins-Agents und Buildkite-Worker laufen typischerweise auf Standard-Linux. Ein kompromittierter Pull-Request-Job mit Shell-Stage hat damit potenziell Root auf dem Build-Host. Die Standard-Empfehlung „Runner regelmäßig austauschen“ wird in dieser Lage zur Pflicht.

~60 min

Scan-zu-PoC-Zeit des Theori-KI-Agenten – von Quellcode-Analyse bis funktionsfähigem Exploit.

Quelle: Theori, 04.05.2026

Managed-Container-Services entlasten teilweise. AWS Fargate, Google Cloud Run und Azure Container Apps abstrahieren den Host vom Workload. Die Plattform-Betreiber patchen die Hosts, Kunden müssen ihre Container-Images nur dann anpassen, wenn der Container selbst privilegierte Operationen ausführt. Wer aber Container mit hostPID, hostNetwork oder Privileged-Mode laufen lässt, oder Kubernetes-Worker selbst betreibt, sitzt wieder im Patch-Pflicht-Modus.

„Active exploitation in the wild confirmed. All unpatched Linux systems with AF_ALG enabled are at risk.“
CrowdStrike Threat Intelligence, 04.05.2026

Patch-Pfad in 72 Stunden

Der schnelle Pfad sieht in produktiven Cloud-Flotten meistens gleich aus. Erstens: Inventory. Welche Linux-Versionen laufen, mit welchem Kernel, in welchen Auto-Scaling-Gruppen oder Node-Pools? AWS-Customers bekommen das aus Systems Manager Inventory, Azure aus dem Update Management, GCP aus OS Config. Wer das nicht hat, baut für eine Stunde ein Ad-hoc-Inventory mit SSM-Run-Command oder Ansible-Ad-hoc.

Zweitens: Patch-Rollout in Wellen. Stage zuerst, danach 10 Prozent der Produktion, dann der Rest. Bei Auto-Scaling-Groups bedeutet das ein neues AMI mit dem gepatchten Kernel und ein rollierendes Replace. Bei Kubernetes ein Node-Pool-Upgrade, idealerweise mit PDB-Schutz auf Kern-Workloads. Drittens: Verifikation. Pro gepatchter Maschine ein einziger Befehl genügt: uname -r gegen den distro-spezifischen Fix-Kernel prüfen.

Wer den 72-Stunden-Pfad nicht halten kann, hat den Workaround. Die Datei /etc/modprobe.d/blacklist-af_alg.conf mit der Zeile install af_alg /bin/false verhindert, dass das Modul beim Boot geladen wird. Bestehende Sitzungen brauchen einen Reboot, bis die Änderung greift. Vorsicht: TLS-Offloading, Disk-Encryption-Stacks und HSM-Anbindungen, die AF_ALG nutzen, fallen in User-Space-Fallbacks zurück. Performance-Impact vor Produktion messen.

Häufige Fragen

Sind Container in Managed-Services wie Fargate oder Cloud Run direkt betroffen?

Direkt nicht. Der Hyperscaler patcht den Host, der Container darunter sieht das Kernel-Interface gar nicht. Indirekt schon: wenn ein Container mit Privileged-Mode oder hostPID läuft oder die App selbst AF_ALG-Operationen anstößt, kann der Exploit auch in solchen Umgebungen relevant werden. Standard-Web-Workloads ohne Kernel-Crypto-Operationen sind nicht das Hauptziel.

Welche Linux-Distributionen haben am 05.05.2026 bereits Patches?

Red Hat Enterprise Linux 8 und 9 haben Updates über den regulären Errata-Kanal. Ubuntu LTS 20.04, 22.04 und 24.04 haben Patches im Security-Pocket. Debian Stable hat das Update im Stable-Security-Repo. Amazon Linux 2 und Amazon Linux 2023 sind über yum/dnf verfügbar. SUSE Linux Enterprise 15 ist im Maintenance-Channel. Arch und openSUSE Tumbleweed rollen mit dem Mainline-Kernel. Alpine Linux folgt typischerweise innerhalb von 48 Stunden.

Wie groß ist der Performance-Impact des AF_ALG-Workarounds?

Stark abhängig vom Workload. Ein Standard-Web-Server mit OpenSSL nutzt AF_ALG nicht und hat null Impact. Disk-Encryption mit dm-crypt fällt auf User-Space-AES zurück, was auf modernen CPUs mit AES-NI eine geringe Differenz macht. HSM- und PKCS11-Anbindungen, die AF_ALG für Hardware-Abstraction nutzen, können deutlich langsamer werden. Vor dem produktiven Workaround eine kurze Last-Spitze auf einem Staging-Knoten messen.

Reicht ein Reboot nach dem Patch oder braucht es mehr?

Ein Patch in der Kernel-Image-Datei wirkt erst nach Reboot. Bei Auto-Scaling-Groups praktisch über ein neues AMI mit gepatchtem Kernel. Bei Kubernetes über einen Node-Pool-Upgrade. Live-Patching via kpatch oder kgraft ist auf einigen Distros möglich, aber nicht auf allen. Wer Live-Patching nicht im Stack hat, plant einen rolling Reboot innerhalb der 72-Stunden-Frist ein.

Was ist mit ARM-basierten Cloud-Instanzen wie AWS Graviton?

Auch betroffen. AF_ALG ist eine Kernel-Schnittstelle, unabhängig von der CPU-Architektur. AWS Graviton, Azure Cobalt und Google Tau-T2A laufen alle mit denselben Linux-Distros wie x86-Instanzen. Der Patch-Pfad ist identisch: distro-spezifisches Update, Reboot, Verifikation.

Mehr aus dem MBF Media Netzwerk

Quelle Titelbild: Pexels / Brett Sayles