Copy Fail CVE-2026-31431: aktive Angriffe, Patch und Linux-Root-Lücke

Copy Fail (CVE-2026-31431) ist eine neue lokale Root-Schwachstelle im Linux-Kernel. Nach der öffentlichen Analyse von Theori/Xint Code entsteht der Fehler in algif_aead beziehungsweise der Krypto-Vorlage authencesn: Ein lokaler, unprivilegierter Prozess kann über AF_ALG und splice() einen kontrollierten 4-Byte-Schreibzugriff in den Page Cache auslösen.

Die wichtigste Einordnung: Copy Fail ist kein isolierter Bug in einem einzelnen Produkt. Die Forscher sprechen von Mainstream-Linux-Kerneln seit 2017; praktisch kann die Schwachstelle damit zahlreiche Server, Cloud-Instanzen, Container-Nodes, Build-Systeme und Shared-Hosting-Umgebungen betreffen. Die Demo-Section auf copy.fail zeigt denselben Exploit-Pfad über mehrere große Linux-Distributionen hinweg.

Genau deshalb kann die reine CVSS-Bewertung von 7.8 zu falscher Gelassenheit führen. Ja, der Angreifer braucht lokale Codeausführung. In der Praxis ist „lokal“ aber häufig bereits erreicht: durch einen Container, einen selbst gehosteten CI-Job, eine Web-RCE, ein kompromittiertes Paket oder gestohlene SSH-Zugangsdaten. Sobald ein solcher Startpunkt existiert, kann aus einem normalen Nutzerkontext unter ungünstigen Bedingungen Root werden.

Was seit der Veröffentlichung neu ist

Seit dem ersten Stand vom 30. April hat sich die operative Lage verändert. heise berichtet am 4. Mai 2026, dass CISA vor Missbrauch von Copy Fail in freier Wildbahn warnt. Microsoft Defender bewertet die Lücke außerdem als relevantes Risiko für Cloud-, CI/CD- und Kubernetes-Umgebungen, sieht PoC-nahe Testaktivitäten und verweist auf die Aufnahme in den CISA-KEV-Kontext. The Hacker News berichtet am 3. Mai 2026 ebenfalls über die KEV-Aufnahme und die daraus folgende Priorisierung für betroffene Umgebungen.

Für Admins ist das wichtiger als die abstrakte CVSS-Zahl: KEV, öffentliche PoCs und bestätigte Ausnutzung bedeuten, dass Copy Fail in Patch-Backlogs nicht mehr als „lokale Lücke irgendwann später“ behandelt werden sollte. Besonders kritisch bleiben Hosts, auf denen Angreifer realistisch lokalen Code platzieren können: selbst gehostete Runner, Kubernetes-Nodes, Shared-Hosting-Systeme, Jump-Hosts, Build-Server und Webserver nach einer ersten RCE. Für US-Bundesbehörden nennt die KEV-Berichterstattung eine Fix-Frist bis zum 15. Mai 2026; für andere Betreiber ist das zumindest ein brauchbares Priorisierungssignal.

Auch die Patch-Lage ist konkreter geworden. heise verweist auf verfügbare Kernel-Updates und Backports; Sysdig nennt als gefixte Upstream-Linien unter anderem 7.0, 6.19.12 und 6.18.22. Hosting-Ökosysteme wie cPanel und Plesk verweisen zugleich darauf, dass cPanel/WHM oder Plesk selbst nicht die verwundbare Komponente sind: Entscheidend ist der laufende Betriebssystem-Kernel. Nach Updates reicht deshalb kein Paketstatus in der Theorie; prüfen Sie nach Reboot oder Livepatch, ob der laufende Kernel wirklich abgedeckt ist.

Kurzfassung für Admins

NVD führt für CVE-2026-31431 den CNA-Score von kernel.org mit CVSS 7.8 High und dem Vektor AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Canonical markiert die Ubuntu-Priorität als High und nennt als Begründung „trivial local privilege escalation“. Für die Priorisierung im Betrieb sollte der CVSS-Wert deshalb nicht isoliert betrachtet werden: Entscheidend ist, ob ein Host fremden Code ausführt, mehrere Nutzer oder Mandanten teilt oder nach einer ersten Kompromittierung als Sprungbrett dienen kann.

Was passiert technisch?

Die Kurzversion: splice() kann Page-Cache-Referenzen einer lesbaren Datei in den Linux-Krypto-Pfad liefern. Durch die in-place-Logik in algif_aead zeigen Quelle und Ziel der Operation auf dieselbe Scatterlist. Die Krypto-Vorlage authencesn führt dabei einen kleinen Scratch-Write aus. In der verwundbaren Kombination landet dieser Schreibzugriff nicht in einem harmlosen Zielpuffer, sondern in der Page-Cache-Kopie einer Datei.

Besonders tückisch ist: Die Datei auf der Platte muss dabei nicht verändert werden. Der manipulierte Zustand lebt im Page Cache, und genau diese In-Memory-Version wird von anderen Prozessen gelesen. Bei einem setuid-Binary oder einer für Login-Auflösung relevanten Datei kann daraus ein stabiler Privilegienwechsel entstehen. Die Copy-Fail-Seite beschreibt die Veränderung als nicht persistent über einen Reboot hinweg, aber der daraus entstehende Root-Kontext ist real.

Betroffenheit prüfen

Betroffen sind nach Angaben der Forscher grundsätzlich Kernel, die die 2017 eingeführte in-place-AEAD-Logik enthalten und den neuen Fix noch nicht tragen. Direkt getestet wurden Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 und SUSE 16; andere Distributionen mit entsprechenden Kernel-Linien müssen über den jeweiligen Vendor-Tracker bewertet werden. Sysdig konkretisiert die Upstream-Sicht und nennt 7.0, 6.19.12 und 6.18.22 als gefixte Linien; bei LTS- und Enterprise-Distributionen können dieselben Fixes aber in ältere Versionszweige zurückportiert sein.

Für Unternehmen heißt das: Nicht nur einzelne, sichtbar exponierte Server prüfen. Auch interne Linux-Systeme, Kubernetes-Nodes, Runner, Build-Hosts, Appliance-VMs, Entwickler-Jump-Hosts und kurzlebige Cloud-Instanzen gehören in die Abfrage. Bei einer breit wirksamen Kernel-Lücke entsteht das Risiko nicht nur durch die einzelne CVE-Zahl, sondern durch die Kombination aus großer Verbreitung und vielen Wegen, wie Angreifer heute lokalen Code auf Infrastruktur ausführen können.

Ein sinnvoller erster Check ist kein Exploit, sondern Inventar: Kernel-Version, Distribution, Paketstatus, Workload-Typ und die Frage, ob untrusted Code auf dem Host läuft. Vendor-Tracker sind dabei wichtiger als reine Versionsvergleiche, weil Distributionen Kernel-Fixes häufig backporten.

uname -a
cat /etc/os-release
lsmod | grep -E '^algif_aead|^af_alg' || true
ss -xa | grep -i AF_ALG || true

# Danach: Vendor-Tracker und Paketstatus prüfen, nicht blind nach Kernelnummer entscheiden.

Nach einem Update sollte die Prüfung ausdrücklich den laufenden Kernel erfassen. Bei klassischen Updates heißt das meist: Paket installieren, Host rebooten, uname -r prüfen und gegen Vendor-Advisory abgleichen. Bei Livepatching gilt dasselbe Prinzip: nicht nur den Update-Befehl ausführen, sondern die Abdeckung für CVE-2026-31431 nachweisen, etwa über die vom Anbieter vorgesehene Statusabfrage.

Sofortmaßnahmen

Die richtige dauerhafte Maßnahme ist ein Kernel-Update. Der Upstream-Fix entfernt die in-place-Komplexität in algif_aead und trennt Quelle und Ziel wieder so, dass Page-Cache-Seiten nicht in einer beschreibbaren Destination-Scatterlist landen. Praktisch heißt das: Vendor-Kernel installieren, rebooten oder einen Livepatch-Mechanismus nutzen, wenn Ihr Anbieter den Fix darüber bereitstellt.

Wenn Patching nicht sofort möglich ist, nennt die Disclosure als kurzfristige Mitigation das Deaktivieren von algif_aead. Für Container- und Sandbox-Umgebungen ist außerdem wichtig, die Erstellung von AF_ALG-Sockets per seccomp zu blockieren. Prüfen Sie vorher, ob eigene Anwendungen AF_ALG AEAD direkt verwenden; typische Standardpfade wie LUKS, SSH oder normale OpenSSL/GnuTLS-Nutzung laufen laut Copy-Fail-FAQ nicht über diesen User-Space-Zugang.

# Temporäre Mitigation, bis ein gepatchter Kernel aktiv ist:
printf 'install algif_aead /bin/false\n' | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo rmmod algif_aead 2>/dev/null || true

# Anschließend: Workloads testen, Patch einspielen, Host rebooten oder livepatchen.

Warum Container und CI besonders kritisch sind

Container isolieren Prozesse, teilen sich aber den Kernel des Hosts. Wenn eine Schwachstelle auf Kernel-Ebene aus einem unprivilegierten Prozess heraus ausnutzbar ist, kann die Grenze zwischen Pod, Container und Node deutlich schwächer sein, als Anwendungsteams erwarten. Copy Fail ist deshalb weniger ein einzelnes Serverproblem als ein Plattformrisiko.

Für CI-Systeme gilt das in besonderem Maße: Build-Jobs führen absichtlich Code aus, dem man noch nicht vollständig vertraut. Ein kompromittiertes Paket, ein manipuliertes Pull-Request-Skript oder ein Test mit beliebigem Shell-Code kann aus einem normalen Runner-Nutzer einen Host-Root-Kontext machen. Wer selbst gehostete Runner betreibt, sollte sie kurzfristig als Hochrisiko-Assets behandeln: isolieren, nur kurzlebig verwenden, Secrets begrenzen und Kernel-Fixes priorisieren.

Einordnung des rootsecdev-Repositories

Das Drittanbieter-Repository rootsecdev/cve_2026_31431 ist kein offizielles Kernel- oder Distro-Advisory, aber für die Lagebewertung relevant: Es beschreibt ein Toolkit mit einem nicht-destruktiven Detector und einem LPE-PoC. Der Detector arbeitet laut README mit einer temporären Sentinel-Datei und berührt keine Systemdateien; der Exploit-Teil dagegen ist echte Privilege Escalation und gehört nicht auf produktive Systeme.

Für Verteidiger ist die Existenz solcher Repositories ein klares Signal: Die Schwachstelle ist nicht nur theoretisch nachvollziehbar, sondern praktisch testbar. Gleichzeitig sollte jedes Ergebnis gegen Vendor-Status und Kernel-Paketstand abgeglichen werden. Ein „nicht verwundbar“ aus einem Dritt-Detector ersetzt kein Patch-Management, und ein „verwundbar“ sollte nicht mit ungeprüften Exploit-Versuchen in Produktion beantwortet werden.

Incident-Checks nach der Offenlegung

Durch die neuen Meldungen zur Ausnutzung reicht reines Patch-Management für bereits exponierte Systeme nicht immer aus. Wer vor dem Fix lokalen Fremdcode ausgeführt hat, etwa in CI-Jobs, Containern, Shared-Hosting-Umgebungen oder auf Jump-Hosts, sollte Copy Fail als möglichen Eskalationsschritt nach initialem Zugriff behandeln.

Copy Fail ist schwerer klassisch nachzuweisen als eine Datei-Manipulation, weil der zentrale Effekt im Page Cache liegen kann. Trotzdem sollten Betreiber nach der Offenlegung nicht nur patchen, sondern auch typische lokale Eskalations- und Post-Exploitation-Spuren prüfen:

• neue oder ungewöhnliche Root-Sessions, su/sudo-Nutzung und PAM-Logs,
• auffällige Build-Job-Kommandos, Forks oder Pull Requests auf self-hosted Runnern,
• neue Cronjobs, systemd-Units, SSH-Keys, SUID-Dateien und lokale Admin-Accounts,
• Container-Workloads, die AF_ALG-Sockets oder ungewöhnliche splice()-Pfadkombinationen nutzen,
• Secrets, die auf betroffenen Runnern oder Shared-Hosts im Zugriff waren.

Für besonders exponierte Systeme lohnt sich ein pragmatischer Ablauf: Host aus dem Pool nehmen, Kernel patchen, neu starten, kurzlebige Runner neu provisionieren und anschließend Credentials rotieren, die durch lokale Root-Rechte erreichbar gewesen wären.