CISA warnt vor Linux-Kernel-Schwachstelle Copy Fail (CVE-2026-31431)

CISA hat die Schwachstelle CVE-2026-31431 (Copy Fail) im Linux-Kernel in ihren CISA-KEV-Katalog ausgenutzter Schwachstellen aufgenommen und damit ihre aktive Ausnutzung bestätigt: Der Fehler mit einem CVSS-Score von 7.8 ermöglicht jedem lokalen Benutzer ohne Privilegien, Root-Rechte zu erlangen, indem im Speicher gecachte ausführbare Dateien beschädigt werden – einschließlich setuid-Binaries. Dadurch wird ein sofortiges Aktualisieren von Linux-Distributionen auf Kernel-Versionen mit Fix (insbesondere in Cloud- und Container-Umgebungen) kritisch.

Технические детали уязвимости

Copy Fail (CVE-2026-31431), beschrieben im NVD-Eintrag CVE-2026-31431, ist eine Schwachstelle zur lokalen Privilegienerweiterung in der Subsystem-Komponente für kryptografische Authentifizierungstemplates des Linux-Kernels. CISA beschreibt sie als fehlerhafte „Übertragung von Ressourcen zwischen Sphären“, was in der Praxis dazu führt, dass ein Benutzerprozess Objekte in einem privilegierteren Bereich beeinflussen kann.

Schlüsselfakten zur Schwachstelle:

• Identifikator: CVE-2026-31431 (Copy Fail)
• Bewertung: CVSS 7.8 (hohe Gefährdung)
• Typ: lokale Privilegienerweiterung (LPE) bis root
• Vektor: lokal (AV:L), geringe erforderliche Privilegien, keine Benutzerinteraktion
• Betroffene Systeme: Linux-Distributionen, die seit 2017 ausgeliefert werden
• Fixes: Linux-Kernel-Versionen 6.18.22, 6.19.12 und 7.0

Forscher von Theori und Xint zeigten, dass das Problem nicht durch einen einzelnen fehlerhaften Commit entstand, sondern durch drei für sich genommen „sichere“ Änderungen am Kernel aus den Jahren 2011, 2015 und 2017. Zusammengenommen führten sie zu einem logischen Fehler in der Verarbeitung des kryptografischen Authentifizierungstemplates, der sich zuverlässig mit einem sehr kompakten (rund 732 Byte großen) Exploit in Python ausnutzen lässt. Auf Basis dieser Variante sind bereits Implementierungen in Go und Rust entstanden, die in öffentlichen Repositories gefunden wurden.

Ein kritisches Merkmal von Copy Fail ist das Angriffsobjekt: der page cache, also der Seitencache im Speicher, in dem der Kernel den Inhalt von Dateien vorhält. Die Schwachstelle ermöglicht es einem nicht privilegierten Benutzer, den Inhalt der gecachten Seiten beliebiger lesbarer Dateien zu verfälschen, einschließlich setuid-Binaries. Wie Wiz hervorhebt, ist die Seite im Cache genau das, was der Prozessor beim Start des Binaries tatsächlich ausführt. Eine Änderung des Page Cache modifiziert also faktisch das Programm „on the fly“, ohne dass etwas auf den Datenträger geschrieben wird.

Daraus ergibt sich folgendes typisches Ausbeutungsszenario:

• Ein Angreifer mit lokalem Zugang zum System nutzt die Schwachstelle, um Cache-Seiten zu manipulieren, die einem privilegierten Binary zugeordnet sind (z. B. /usr/bin/su);
• in die veränderten Seiten wird beliebiger Code eingeschleust;
• beim Start des privilegierten Binaries wird bereits der modifizierte Code ausgeführt, was dem Angreifer Root-Rechte verschafft.

Der Exploit verwendet ausschließlich legitime Systemaufrufe und ist weder auf Race Conditions noch auf das Erraten von Speicheradressen angewiesen. Das senkt unmittelbar die Komplexität der Ausnutzung und erschwert ihre Erkennung durch verhaltensbasierte Schutzmechanismen: Aus Sicht des Systems sieht alles wie normale Arbeit einer Anwendung mit dem kryptografischen Subsystem und Dateien aus.

Nach Angaben des Microsoft Defender Security Research Team wird bereits „vorläufige Testaktivität“ rund um CVE-2026-31431 beobachtet, und CISA weist durch die Aufnahme der Schwachstelle in den KEV-Katalog ausdrücklich auf laufende Ausnutzung in the wild hin.

Vom Kern her entspricht diese Technik einem typischen Szenario der Ausnutzung einer Schwachstelle zur Privilegienerweiterung, das in den Begriffen von MITRE ATT&CK zur Kategorie Exploitation for Privilege Escalation lokaler Schwachstellen gehört.

Оценка воздействия и профиль риска

Das potenzielle Impact von Copy Fail wird weniger durch den CVSS-Score bestimmt als durch den realen Einsatzkontext von Linux:

• Cloud und Virtualisierung. Linux dominiert in Cloud-Infrastrukturen. Jeder Fall, in dem ein Angreifer Code auf einer virtuellen Maschine oder in einem Container ausführen kann (etwa durch gestohlene SSH-Schlüssel oder eine verwundbare Webanwendung), kann bis zur vollständigen Kontrolle über das Gastsystem eskaliert werden und unter bestimmten Umständen zu Angriffen auf die Host-Plattform führen.
• Container-Plattformen (Docker, LXC, Kubernetes). Nach Einschätzung von Kaspersky stellt Copy Fail ein erhöhtes Risiko für containerisierte Umgebungen dar, da Prozesse innerhalb eines Containers standardmäßig Zugriff auf das AF_ALG-Subsystem erhalten, wenn das Modul algif_aead im Host-Kernel geladen ist. In diesem Fall kann eine Ausnutzung innerhalb des Containers zu einem Container Escape und zur Übernahme des physischen (oder virtuellen) Hosts führen, also zur Aufhebung des Isolationsmodells.
• Shared-Server und Multi-Tenant-Systeme. Lernplattformen, Hosting-Provider und alle Umgebungen, in denen verschiedene Benutzer Shell-Zugriff auf denselben Linux-Host bekommen, sind besonders verwundbar: Ein unkontrollierter Benutzer kann Root-Rechte erlangen und die Daten anderer Kunden kompromittieren.
• Kritische Infrastrukturen und Behörden. Für US-Bundesbehörden (FCEB) hat CISA eine strikte Frist für die Installation der Fixes gesetzt – bis zum 15. Mai 2026. Das spiegelt das Risiko für Integrität und Verfügbarkeit kritischer Dienste im Fall einer erfolgreichen lokalen Kompromittierung wider.

Unter Business-Risiko-Gesichtspunkten umfasst Untätigkeit folgende Konsequenzen:

• vollständige Übernahme des Servers mit der Möglichkeit nachfolgender horizontaler und vertikaler Bewegung innerhalb der Infrastruktur;
• Erschütterung des Vertrauens in die Integrität von Anwendungen: Die Einspeisung von Code in privilegierte Binaries kann als unauffälliger Mechanismus für langfristige Persistenz und zur Umgehung von Integritätskontrollen dienen, die nur auf Dateisystemebene prüfen;
• Kompromittierung von CI/CD-Pipelines: Verfügt ein Angreifer über Root-Rechte auf Build-Agenten, kann er erzeugte Artefakte unbemerkt manipulieren;
• regulatorische Folgen bei Vorfällen, in denen Root-Zugriff zur Exfiltration oder Zerstörung von Daten genutzt wird, die als kritisch oder personenbezogen eingestuft sind.

Практические рекомендации по защите

1. Оценка подверженности

Vorrangige Aufgabe ist es festzustellen, welche Systeme verwundbar sein könnten:

• prüfen Sie die Kernel-Version mit dem Befehl uname -r auf Servern und Workstations mit Linux;
• gleichen Sie die ermittelten Versionen mit denen ab, in die der Fix bereits integriert ist (6.18.22, 6.19.12, 7.0), oder mit den von Ihrem Distributionsanbieter veröffentlichten Updates;
• analysieren Sie Umgebungen, in denen Code unter nicht voll privilegierten Benutzern ausgeführt werden kann: Container-Cluster, Server mit SSH-Zugriff für Entwickler, CI-Maschinen.

Bei Unsicherheiten ist es sinnvoll, die Informationen zu CVE-2026-31431 in der NVD-Datenbank sowie die Dokumentation Ihres Distributions- oder Kernel-Anbieters (zum Beispiel die offizielle Website kernel.org) zu konsultieren.

2. Патч-менеджмент и приоритизация

Empfohlene Reihenfolge für die Aktualisierung:

1. Höchste Priorität (dringend): Systeme, auf denen externe oder bösartige Prozesse lokalen Shell-Zugriff erhalten können: Server mit öffentlichem SSH-Zugang, Kubernetes-Nodes, Hosts mit externen Containern, Shared-Server.
2. Hohe Priorität: CI/CD-Agenten, Infrastrukturdienste und Datenbanken, bei denen eine Root-Kompromittierung Kettenreaktionen auslösen würde.
3. Übrige Systeme: Kernel-Updates in das nächste geplante Wartungsfenster einplanen.

Für FCEB-Behörden ist die Frist durch CISA auf den 15. Mai 2026 festgelegt. Für kommerzielle Organisationen ist es sinnvoll, sich an ähnlichen Zeitrahmen zu orientieren: Es geht um Tage, nicht um Monate.

3. Временные меры при невозможности немедленного обновления

Wenn ein zeitnahes Kernel-Update nicht möglich ist (etwa aufgrund strenger Downtime-Vorgaben):

• Deaktivieren Sie die verwundbare Funktionalität. CISA empfiehlt, die betroffene Funktionalität vorübergehend abzuschalten. In der Praxis bedeutet das, die Nutzung des AF_ALG-Subsystems und zugehöriger Module (insbesondere algif_aead) entsprechend den Empfehlungen Ihres Distributionsanbieters einzuschränken.
• Verstärken Sie die Netzwerkisolation. Minimieren Sie die Möglichkeiten für einen Angreifer, lokalen Zugriff zu erlangen: Beschränken Sie SSH auf VPN oder vertrauenswürdige Adressen und verschärfen Sie die Zugriffspolitik auf Bastion-Hosts.
• Überarbeiten Sie die Zugriffspolitik in Container-Clustern. Begrenzen Sie die Ausführung nicht geprüfter Container auf Hosts, auf denen noch kein aktualisierter Kernel eingesetzt wird, und vermeiden Sie nach Möglichkeit Container mit unnötigen Privilegien und Zugriff auf kryptografische Kernel-Subsysteme.
• Verschärfen Sie die Kontrolle über Konten. Minimieren Sie die Anzahl der Benutzer mit interaktivem Zugang zu Systemen und setzen Sie das Need-to-know- und Least-Privilege-Prinzip für Service-Accounts konsequent um.

4. Мониторинг и обнаружение

Da der Exploit ausschließlich auf legitime Systemaufrufe setzt und keine Dateien auf dem Datenträger verändert, ist eine klassische Integritätsprüfung des Dateisystems wenig wirksam. Dennoch sind unterstützende Maßnahmen möglich:

• verstärkter Audit der Ausführung privilegierter Binaries (insbesondere setuid) und des anomalen Verhaltens von Prozessen mit Root-Rechten;
• Überwachung untypischer Nutzung kryptografischer Kernel-Subsysteme und von AF_ALG an Stellen, an denen sie normalerweise nicht von Anwendungen verwendet werden;
• Überarbeitung der Regeln für verhaltensbasierte Analysen in EDR-/EDR-ähnlichen Lösungen für Linux, mit zusätzlichem Fokus auf unerwartete Privilegienerweiterungen bei Anwendungen, die unter nicht privilegierten Benutzern laufen.

Zentraler Schluss: jede Umgebung, in der ein potenzieller Angreifer Code auf einem verwundbaren Linux-Host ausführen kann, ist als potenziell vollständig kompromittierbar anzusehen, solange der Kernel nicht auf eine Version mit Fix für CVE-2026-31431 aktualisiert oder die entsprechende Funktionalität deaktiviert wurde. Der praktikabelste Schritt ist, im nächsten Wartungsfenster den Kernel (oder die Kernel-Pakete der Distribution) auf Versionen mit Patch zu aktualisieren, mit Priorität für Hosts mit Containern, öffentlichem SSH-Zugang und Mehrbenutzerszenarien.