CVE-2026-31431 "Copy Fail" — warum der Kernel zählt

Die seit dieser Woche diskutierte Schwachstelle CVE-2026-31431, in der Community "Copy Fail" genannt, sitzt im Linux-Kernel selbst. Wir bekommen seit gestern entsprechend Fragen, und haben die wichtigen Antworten hier zusammengezogen, inklusive der Maßnahmen, die wir bei unseren Managed-Hosting-Kunden umgesetzt haben.

Kurzfassung für Entscheider

Es ist eine Kernel-Schwachstelle, keine Container-Schwachstelle. Welche Container-Distribution darunter läuft, ist egal: Debian, Alpine, Ubuntu, Wolfi sind gleichermaßen betroffen, weil keine davon einen eigenen Kernel mitbringt. Stand heute existieren keine breit verfügbaren Patches, sondern nur Workarounds. Wir haben die wirksamen Mitigationen auf Host-Ebene bei allen Managed-Hosting-Kunden ausgerollt.

Was Copy Fail technisch ist

CVE-2026-31431 erlaubt eine lokale Privileg-Eskalation bis Root. Der Public-Proof-of-Concept passt auf eine A4-Seite und braucht keine seltenen Voraussetzungen. Er nutzt Standard-Kernel-Funktionalität, die in praktisch jedem Linux-System aktiv ist, und wirkt distributionsübergreifend.

Technisch sitzt das Problem im Crypto-Subsystem, konkret in der AF_ALG-Schnittstelle und der Verarbeitung bestimmter Speicheroperationen. Die ausführliche Aufarbeitung unter copy.fail macht die Tragweite deutlich.

Warum Container hier nicht retten

Ein häufiger Denkfehler lautet: "Wenn der Container sicher ist, ist das System sicher." Das stimmt für viele Klassen von Schwachstellen. Für Kernel-Lücken stimmt es nicht.

Container, egal ob auf Debian-, Alpine- oder Wolfi-Basis, bringen keinen eigenen Kernel mit. Sie nutzen den Kernel des Host-Systems. Container-Isolation ist eine User-Space-Konstruktion, durchgesetzt vom Kernel selbst. Sobald ein Prozess innerhalb des Containers den Kernel adressiert und dort eskaliert, ist die Isolation umgangen.

Das ist konzeptionell vergleichbar mit den Lieferketten-Risiken, über die wir bereits geschrieben haben, etwa beim Image-Audit nach IDS-Alarm oder beim Bitwarden-CLI-Vorfall vom 22. April. Auch dort wirkt der Angriff unterhalb dessen, was Container-Hardening abdeckt.

Wolfi OS richtig eingeordnet

Wir setzen bei Moselwal auf Wolfi OS als Container-Basis. Wichtig ist die saubere Einordnung: Wolfi ist eine Undistro, also reines Userland ohne eigenen Kernel. Wolfi nutzt vollständig den Host-Kernel. Daraus folgen zwei Dinge: Wolfi ist nicht die Ursache der Schwachstelle, und Wolfi kann sie auch nicht beheben. Die Verantwortung liegt vollständig auf dem Host.

Aus dem gleichen Grund haben wir uns vor einigen Wochen grundsätzlich von compose.yaml verabschiedet und unsere Container-Topologien deklarativ aufgebaut. Mit klaren Schichten lässt sich die Verantwortung pro Vorfall eindeutig verorten, in diesem Fall beim Host-Kernel.

Was wir konkret gemacht haben

Da derzeit keine breit verfügbaren Kernel-Patches vorliegen, haben wir die empfohlenen Workarounds umgesetzt:

• Audit aller betroffenen Hosts in unserem Managed-Hosting-Park
• Deaktivierung von algif_aead via modprobe-Blacklist
• Restriktion des crypto_user-Zugangs
• Validierung durch Reproduktion des Public-PoC nach der Mitigation

Erst wenn der Exploit in der Validierung fehlschlägt, gilt der Host für uns als bereinigt. Dieses Vorgehen ist genau das, was wir für Kunden im Rahmen von DevSecOps as a Service und der Externen IT-Abteilung tagtäglich machen.

Was wir bewusst nicht gemacht haben

Container-Images haben wir nicht neu gebaut, weil die Ursache nicht dort liegt. Generische Hardening-Maßnahmen "bei der Gelegenheit" haben wir uns gespart, weil sie die Validierung der eigentlichen Mitigation nur verwässert hätten.

Wer am stärksten betroffen ist

Besonders kritisch ist die Schwachstelle dort, wo viele Workloads sich denselben Kernel teilen: Container-Hosts mit Multi-Tenant-Setup, selbst betriebene Kubernetes-Worker und CI/CD-Runner. Wir haben an anderer Stelle ausführlich beschrieben, warum gerade CI-Pipelines den größten Verdichtungspunkt für Eskalationen darstellen.

Genau für diese Klasse von Risiken planen wir KI-Security-Audits in jeden Release ein, als Frühwarnsystem für trivial ausnutzbare CVEs vor dem Day-Zero.

Fazit

CVE-2026-31431 ist eine reine Kernel-Schwachstelle. Container-Distributionen können sie weder verursachen noch beheben, Wolfi eingeschlossen. Bis ein offizieller Kernel-Patch verfügbar ist, mitigieren wir auf Host-Ebene; sobald der Patch stabil läuft, spielen wir ihn ein.