Copy Fail CVE-2026-31431: Globale Linux-Root-Lücke prüfen

Stand: 30. April 2026 – zuletzt aktualisiert

Autor: Mika Schmidt (IT-Security Experte) – Six Eight Consulting, Fokus: Analyse, IAM, Security Engineering.

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. [Disclosure] [Technical Write-up]

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. [Demo]

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. heise ordnet die Lücke ebenfalls als Linux-Root-Szenario für große Distributionen ein. [NVD] [News]

Kurzfassung für Admins

• Impact: Ein lokaler Nutzer oder lokaler Prozess kann Root-Rechte erhalten, wenn der Kernel verwundbar ist.
• Reichweite: Kein Randfall, sondern ein breit relevantes Linux-Kernel-Thema; betroffene Kernel-Linien seit 2017 können in vielen produktiven Umgebungen im Einsatz sein.
• Voraussetzung: lokale Codeausführung, erreichbares AF_ALG/algif_aead und ein Kernel ohne Fix.
• CVSS-Falle: 7.8 klingt niedriger als „kritisch“, kann aber bei Multi-Tenant-Systemen, CI und Container-Plattformen das tatsächliche Betriebsrisiko unterschätzen.
• Warum kritisch: Container und Nutzer teilen sich den Kernel; der Page Cache ist hostweit relevant. Dadurch wird eine lokale LPE schnell zu einem Mandanten- oder Node-Risiko.
• Fix: Kernel-Update mit dem Rückbau der in-place-AEAD-Logik einspielen; bis dahin algif_aead deaktivieren oder AF_ALG für untrusted Workloads blockieren.

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. [NVD] [Vendor Tracker]

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. [Technical Write-up]

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. [Disclosure]

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. [Disclosure] [Technical Write-up]

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. [Distro Tracker] [Vendor Tracker] [Vendor Tracker]

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.

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. [Kernel Patch] [Disclosure]

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. [Disclosure]

# 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. [Disclosure] [Technical Write-up]

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. [GitHub]

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. [PoC Repository] [GitHub]

Incident-Checks nach der Offenlegung

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.

FAQ