Copy Fail (CVE-2026-31431): Was Laravel-Forge-Nutzer jetzt tun sollten

Im April 2026 wurde CVE-2026-31431 veröffentlicht - eine Linux-Kernel-Schwachstelle mit dem griffigen Spitznamen "Copy Fail". Laravel Forge hat dazu eine kompakte Advisory veröffentlicht. Der Hinweis ist richtig, aber knapp: "Patch ist da, einfach neu starten." Wer einen Server betreibt, sollte trotzdem verstehen, was eigentlich passiert ist - und warum eine reine "lokale" Lücke in einer typischen Web-App-Umgebung ernster ist, als der Begriff vermuten lässt.

TL;DR: CVE-2026-31431 ("Copy Fail") ist eine Privilege-Escalation-Lücke im Linux-Kernel, ausgelöst über die Crypto-Schnittstelle AF_ALG in Kombination mit splice(). Remote ist sie alleine nicht ausnutzbar - sie wird aber zum Problem, sobald ein Angreifer bereits lokalen Zugriff hat (z. B. über eine kompromittierte PHP-Anwendung). Für Ubuntu 24.04 LTS reicht ein Update auf Kernel 6.8.0-107.107 oder höher plus Reboot. Auf 22.04 und 20.04 ist der Patch ebenfalls eingespielt, 18.04 ist End-of-Life und bekommt keinen Fix.

Was ist Copy Fail überhaupt?

Die offizielle Kurzbeschreibung im Linux-Kernel-Tree spricht von einem Logikfehler in der authencesn-Implementierung - einem AEAD-Algorithmus (Authenticated Encryption with Associated Data) mit Extended Sequence Number, ursprünglich aus dem IPsec-Umfeld (RFC 4543). Über die userspace-zugängliche Crypto-API AF_ALG lässt sich dieser Algorithmus von einem unprivilegierten Prozess ansprechen.

Der Trick liegt in der Kombination zweier Kernel-Mechanismen:

AF_ALG - eine Socket-Familie, mit der Userland-Prozesse Kernel-Krypto direkt nutzen können. Praktisch für Performance, historisch aber auch eine ergiebige Quelle für Bugs (kernel.org Crypto API Docs).
splice() - ein Syscall, der Daten zwischen File Descriptors verschiebt, ohne sie in den Userspace zu kopieren. Genau dieses "Zero-Copy" ist hier das Problem: Pages werden gemeinsam genutzt, und wenn ein Subsystem darauf vertraut, eine eigene Kopie zu haben, kommt es zum Konflikt.

Das Resultat: Ein lokaler User kann gezielt Speicher im Kernel überschreiben - ohne Race Condition und ohne Kernel-Offsets erraten zu müssen. Das ist der unangenehme Teil. Klassische Use-after-free- oder TOCTOU-Bugs sind oft zickig in der Ausnutzung. Copy Fail ist es nicht. Wer lokalen Shell-Zugriff hat, kommt zuverlässig an Root.

Das Muster ist nicht neu. Schon Dirty Pipe (CVE-2022-0847) hat genau diese Klasse von Fehlern - Pipe-Buffer und splice() - schmerzhaft ausgenutzt. Copy Fail ist im Kern eine Variation desselben Themas, nur an anderer Stelle im Kernel.

"Nur lokal" - warum das im Web-Kontext keine Entwarnung ist

Forge schreibt korrekt: Die Schwachstelle erlaubt für sich genommen keine Remote Code Execution. Das beruhigt nur, wenn der Server keine Software ausführt, die irgendjemand von außen erreichen kann. Auf einem Forge-Server ist das aber so ziemlich der Standardfall.

Realistisches Angriffsszenario:

Ein Angreifer findet eine Lücke in der Anwendung - veraltetes Composer-Paket, unsichere Datei-Uploads, eine Deserialisierungs-Lücke, ein Leak von API-Keys. Klassiker, alles aus den OWASP Top 10.
Damit landet er im Kontext des Webserver-Users (forge, www-data) - also unprivilegiert.
Genau hier setzt Copy Fail an. Aus dem unprivilegierten App-User wird Root.
Ab hier ist die Box komplett - inkl. .env-Dateien anderer Sites auf demselben Server, Datenbankzugängen, SSH-Keys.

Privilege-Escalation-Lücken sind das Bindeglied zwischen "kleiner App-Bug" und "Totalverlust". Genau deshalb sollte man sie nicht weniger ernst nehmen als RCEs.

Betroffene Versionen und der Patch-Stand

Ubuntu	Status	Notwendige Kernel-Version
24.04 LTS	gepatcht	`6.8.0-107.107` oder neuer
22.04 LTS	gepatcht (backport)	aktueller HWE/GA-Kernel
20.04 LTS	gepatcht (backport)	aktueller HWE/GA-Kernel
18.04 LTS	End-of-Life, kein Fix	Upgrade nötig

Forge-Server bekommen Sicherheitsupdates standardmäßig automatisch installiert. Das heißt: Das Kernel-Paket liegt in vielen Fällen bereits auf der Platte - aktiv wird der neue Kernel aber erst nach einem Reboot. Genau deshalb der trockene Forge-Hinweis: "Patch ist da, einfach neu starten."

Was konkret tun

1. Prüfen, welcher Kernel läuft

uname -r

Auf 24.04 sollte hier 6.8.0-107.107 oder höher stehen. Wenn nicht, ist entweder noch kein Update gezogen worden oder es fehlt der Reboot.

2. Updates ziehen (falls automatische Updates aus sind)

sudo apt-get update
sudo apt-get upgrade
sudo reboot

Auf Forge führt der "Reboot"-Button im Server-Dashboard genau das aus, was hier sudo reboot macht. Der Effekt ist derselbe - der neu installierte Kernel wird scharfgeschaltet.

3. Wenn ein Reboot gerade nicht geht: Workaround

Bei produktiven Servern ohne Cluster oder Failover ist ein Reboot nicht immer sofort möglich. Der temporäre Workaround deaktiviert das verwundbare Kernel-Modul:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead

Damit wird die AF_ALG-Variante für AEAD-Algorithmen blockiert. Wer das Modul nicht aktiv nutzt (und das tun die wenigsten Web-Apps), merkt davon nichts. Das ist ein Workaround, kein Fix - sobald der Reboot nachgeholt ist, gehört die Datei entfernt:

sudo rm /etc/modprobe.d/disable-algif.conf

4. Bonus: Livepatch

Wer Ubuntu Pro nutzt, bekommt für viele Kernel-Lücken einen Canonical Livepatch - der Patch wird ohne Reboot in den laufenden Kernel injiziert. Für CVE-2026-31431 wurde ein Livepatch bereitgestellt; wer Pro abonniert hat und Livepatch aktiv betreibt, kann den Reboot bis zum nächsten Wartungsfenster aufschieben. Auf Forge-Servern ist Livepatch nicht standardmäßig aktiv, lässt sich aber nachrüsten.

Was sich daraus für die Zukunft mitnehmen lässt

Drei Punkte, die über diesen konkreten CVE hinaus relevant sind:

Unattended Upgrades sind kein Selbstläufer. Sie installieren Kernel-Pakete, aber ein Server, der seit 80 Tagen läuft, fährt eben einen Kernel von vor 80 Tagen. needrestart oder unattended-upgrades mit Automatic-Reboot "true"; sind hier hilfreich - vorausgesetzt, ein Reboot ist für den Use Case verträglich.
Defense in Depth zahlt sich aus. Application Sandboxing (z. B. PHP-FPM-Pools pro Site mit eigenem User), Read-Only-Mounts, eingeschränkte seccomp-Profile - all das macht es schwerer, von einem App-Bug auf einen Local-Privesc zu pivotieren.
18.04 LTS ist 2026 endgültig vorbei. Wer noch Server darauf betreibt, hat inzwischen einen kontinuierlichen Strom ungepatchter Lücken. Dieses CVE ist nur der nächste Anlass, das Upgrade ernsthaft zu planen.

Fazit

Copy Fail ist keine Endzeitlücke, aber auch nichts, was man ignorieren sollte. Forge hat den Patch über die Distribution bereits ausgerollt - die Verantwortung, den Reboot zu drücken, liegt beim Betreiber. Auf den meisten Servern ist das ein Klick im Dashboard und drei Minuten Downtime. In der Risikoabwägung ist das ein sehr guter Tausch.

Wer mehr Hintergrund zur Klasse dieser Lücken sucht, findet im LWN-Archiv zu splice()-bezogenen Bugs eine ganze Reihe lehrreicher Post-Mortems. Und für Forge-Nutzer gilt: Server-Dashboard öffnen, "Reboot" klicken, uname -r checken. Fertig.