CVE-2026-31431 (Copy Fail): was die Linux-Kernel-Sicherheitsluecke betrifft und wie sie sich abmildern laesst

CVE-2026-31431 Copy Fail ist eine lokale Linux-Kernel-Privilege-Escalation-Schwachstelle, die sehr schnell von einer technischen Offenlegung zu einer operativen Prioritaet geworden ist. Mit Stand 2. Mai 2026 zeigt die offizielle Lage eine hochschwere Schwachstelle in der Komponente algif_aead, veroeffentlichte Hersteller-Mitigations grosser Linux-Distributionen und die Aufnahme in den CISA Known Exploited Vulnerabilities Catalog seit dem 1. Mai 2026.

Dieser Artikel bleibt bewusst eng gefasst. Er reproduziert den Exploit nicht, schaetzt keine Praevalenz und wiederholt keine Drittanbieter-Claims zur Zuverlaessigkeit. Er beschraenkt sich auf das, was die offiziellen Quellen tatsaechlich bestaetigen: was die Schwachstelle betrifft, wo die Exponierung am meisten zaehlt, welche temporaeren Mitigations es gibt und wie sich der Patch-Status validieren laesst, ohne blinde Flecken oder operative Regressionen zu erzeugen.

Fuer den breiteren Prozess der Pruefung isolierter Umgebungen siehe Air-gapped netzwerk sicherheitsaudit: Wie sich eine isolierte Umgebung ohne falsche Sicherheit pruefen laesst. Fuer einen begleitenden Leitfaden zu offline-faehigen Workflows und Werkzeugen siehe Welche Sicherheitstools funktionieren in isolierten Netzwerken ohne Internetzugang? Praktischer Leitfaden fuer offline-faehige Sicherheits-Workflows.

Was ist CVE-2026-31431 (Copy Fail)?

CVE-2026-31431 ist eine Linux-Kernel-Schwachstelle in algif_aead, einer Komponente der kryptografischen Kernel-Schnittstelle. Der NVD-Eintrag uebernimmt die Upstream-Beschreibung des Fix-Pfads: Das verwundbare Verhalten wird behoben, indem algif_aead wieder auf einen out-of-place-Betrieb zurueckgesetzt wird, statt die zuvor eingefuehrte komplexere in-place-Logik beizubehalten.

Die offizielle Schwere, die fuer Verteidiger jetzt am wichtigsten ist, ist der Kernel-CNA-Score von CVSS 3.1 7.8 HIGH, mit dem Vektor AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. NVD fuehrt ausserdem die Klassifikation CWE-669 auf und listet mehrere kernel.org-Patch-Referenzen fuer stabile Branches.

Operativ behandeln Hersteller dies als local privilege escalation im Linux-Kernel. Das ist wichtig, weil lokale Privilegieneskalation keine rein akademische Grenze ist. Wenn ein Angreifer bereits Code-Ausfuehrung als normaler Benutzer hat oder eine nicht vertrauenswuerdige Workload am falschen Ort ausfuehren kann, kann ein verlaesslicher Weg zu root die Vertrauensgrenze eines Bastions, eines gemeinsam genutzten Hosts oder eines Container-Knotens sehr schnell veraendern.

Was die offiziellen Advisories bisher bestaetigen

Die offizielle Lage ist bereits klar genug, um ein sofortiges Triage zu tragen.

Ein zweites operatives Signal ist der KEV-Status. NVD vermerkt ausdruecklich, dass diese CVE im CISA Known Exploited Vulnerabilities Catalog steht, mit Date Added: May 1, 2026 und Due Date: May 15, 2026. Selbst wenn Ihre Organisation keine US-Bundesfristen einhalten muss, ist das ein nuetzliches Priorisierungssignal: Die Schwachstelle ist nicht mehr nur "neu" oder "interessant". Sie gehoert bereits zu der Klasse von Problemen, die Verteidiger als dringend behandeln sollten.

Wo Copy Fail am meisten zaehlt

Es handelt sich nicht um eine aus dem Internet ohne Authentisierung ausnutzbare Edge-Schwachstelle. Die Exponierung haengt vom Vorhandensein eines lokalen Footholds oder eines Ausfuehrungspfads auf einem Linux-System ab. Das laesst dennoch mehrere High-Value-Szenarien offen.

Hosts mit lokalen Benutzern oder lokaler Code-Ausfuehrung

Ubuntu gibt an, dass die Schwachstelle in Umgebungen ohne Container-Workloads einem lokalen Benutzer eine Eskalation zu root erlaubt. Das bedeutet, dass die erste Frage nicht ist: "Ist mein internetexponierter Dienst direkt von aussen ausnutzbar?" Die erste Frage ist, ob der Host bereits untrusted oder semi-trusted Code unter einem niedrig privilegierten Konto ausfuehren kann.

Typische Beispiele sind:

• gemeinsam genutzte Linux-Administrationshosts
• Bastions oder Jump Hosts, die von mehreren Teams verwendet werden
• CI-Runner und Build-Systeme
• Mehrbenutzerserver mit Shell-Zugang
• Management-Server in der Naehe der Identitaetsinfrastruktur

Containerisierte Umgebungen

Ubuntu dokumentiert ausserdem eine separate Sorge fuer containerisierte Deployments, die potenziell bösartige Workloads ausfuehren koennen: Die Schwachstelle kann container escape scenarios erleichtern. Die oeffentliche OpenShift- und ROSA-Guidance von Red Hat bestaetigt, dass der Hersteller Managed- und OpenShift-spezifische Exponierung als separaten operativen Track behandelt, was das richtige defensive Framing ist.

Diese Unterscheidung ist wichtig. Ein Fleet-Team sollte "container escape" nicht als pauschalen Claim ueber jede Kubernetes- oder Container-Umgebung schreiben. Die korrekte Aussage ist enger: Herstellerdokumentation sagt, dass containerisierte Umgebungen besondere Aufmerksamkeit verdienen und dass Container-Node-Triage nicht mit einfacher Workstation- oder Server-Patch-Queue vermischt werden sollte.

Administrative und identitaetsnahe Systeme

Auch wenn es sich um eine Linux-Kernel-Schwachstelle und nicht um eine Active-Directory- oder Entra-Schwachstelle handelt, ist lokales root auf dem falschen Linux-Host fuer Identitaets- und Infrastrukturteams weiterhin relevant. Bastions, Provisioning-Knoten, Automatisierungs-Runner, VPN-Appliances, PAM-Jump-Hosts und Linux-Systeme, die zur Administration von Windows oder Cloud-Infrastruktur genutzt werden, gehoeren zur effektiven Identitaetsebene. Eine lokale Privilegieneskalation dort kann das Vertrauensmodell rund um Credentials, Tokens, Management-Schluessel und Automatisierungspfade veraendern.

Das ist auch der Grund, warum Teams, die bereits Active Directory sicherheit auditieren: Praktische Checkliste oder Active Directory härten: Was Sie zuerst absichern und wie Sie es validieren durchfuehren, Linux-Administrationshosts nicht als ausserhalb des Identitaets-Sicherungsbereichs liegend behandeln sollten. Wenn Ihre administrativen Pfade bereits mit der Zeit driften, gilt dasselbe operative Muster, das in Privilegierter Zugriff Drift in Active Directory: Wie Admin-Rechte nach Audits zurueckkehren beschrieben wird, haeufig auch fuer Bastions und angrenzendes Linux-Tooling.

Temporäre Mitigations und ihre Tradeoffs

Die Geschichte der temporaeren Mitigation ist wichtig, weil die offizielle Hersteller-Guidance sie nicht als neutralen Schalter beschreibt.

Ubuntu gibt an, dass das Security Team eine Mitigation veroeffentlicht hat, die das betroffene Modul algif_aead ueber das Paket kmod deaktiviert, waehrend Kernel-Pakete mit dem Fix ausgerollt werden. SUSE dokumentiert ebenfalls einen Workaround, der das Modul ueber modprobe-Konfiguration blockiert.

Das ist hilfreich, bringt aber Tradeoffs mit sich.

Die Mitigation ist nicht verhaltensneutral

Ubuntu warnt ausdruecklich, dass die Mitigation ein Modul deaktiviert, das fuer hardwarebeschleunigte Kryptografie genutzt wird. Das erwartete Verhalten ist ein Fallback auf Userspace-Kryptofunktionen, aber Ubuntu weist auch darauf hin, dass manche Anwendungen diesen Uebergang nicht sauber verarbeiten. Zusaetzlich koennen bereits laufende Anwendungen betroffen sein, wenn das Modul deaktiviert oder entladen wird, und ein Neustart kann erforderlich sein, um ein konsistentes Fallback-Verhalten zu erzwingen.

Das bedeutet, dass die Mitigationsentscheidung als echte operative Aenderung behandelt werden muss und nicht als harmloser Notfallschalter.

Die praktische Regel ist einfach: Wenn Sie den Workaround einsetzen, dokumentieren Sie ihn als temporaer, validieren Sie kryptografieabhaengige Anwendungen und bestaetigen Sie spaeter, dass das System einen gefixten Kernel-Zustand erreicht, anstatt dauerhaft in einer Workaround-Posture zu bleiben.

Wie sich Exponierung und Patch-Status pruefen lassen

Die sicherste Pruefreihenfolge ist vendor-first. Gehen Sie nicht davon aus, dass eine generische Kernel-Version aus Social Media ausreicht, um zu bestimmen, ob eine Fleet exponiert ist.

Ubuntu-Pruefungen

Ubuntu liefert konkrete Befehle in seinem Advisory:

uname -r

dpkg -l 'linux-image*' | grep ^ii

dpkg -l kmod

Ubuntu dokumentiert ausserdem, wie sich pruefen laesst, ob das betroffene Modul noch geladen ist:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Diese Pruefungen sind auch ausserhalb von Ubuntu hilfreich, weil sie die richtige Logik abbilden: laufenden Kernel pruefen, installierte Pakete pruefen und den Modulstatus separat pruefen.

SUSE-Pruefungen

SUSE stellt eine oeffentliche CVE-Seite mit Produkt-/Paketstatus und veroeffentlichten gefixten Versionen bereit. Fuer SUSE-betriebene Umgebungen ist der autoritative Pfad, die installierten kernelbezogenen Pakete mit den auf der CVE-Seite und den verlinkten Advisories aufgefuehrten Versionen zu vergleichen, statt sich auf eine generische Aussage zur Distributionsfamilie zu stuetzen.

Red-Hat-Pruefungen

Die oeffentliche Bulletin-Seite von Red Hat zeigt RHSB-2026-02 als laufend, und Red Hat veroeffentlicht ebenfalls oeffentliche Hinweise dazu, wie sich ueber die Red-Hat-CVE-Datenbank und die verknuepften Advisories feststellen laesst, ob ein Produkt von einer bestimmten CVE betroffen ist. Red Hat hat ausserdem separate oeffentliche Seiten fuer RHEL und OpenShift zu CVE-2026-31431 veroeffentlicht, was der richtige Pfad fuer produktspezifische Validierung ist.

Was waehrend der Triage erfasst werden sollte

Fuer jedes System oder jede Cluster-Gruppe sollten mindestens diese Daten erfasst werden:

• aktuell laufende Kernel-Version
• installierte Kernel-Paket-Version
• ob algif_aead geladen ist
• ob eine temporaere Mitigation angewendet wurde
• Hersteller-Advisory-Status fuer die jeweilige Produktlinie
• ob nach Patch oder Mitigation noch ein Neustart aussteht

Das reicht aus, um aus einer lauten Vulnerability-Schlagzeile eine echte Remediations-Queue zu machen. Wenn Sie bereits wiederkehrende Infrastruktur-Reviews durchfuehren, gilt hier dieselbe Evidenz-Disziplin wie in Wiederkehrendes Active Directory Audit: Warum jaehrliche Audits driften und wie kontinuierliches Posture Monitoring funktioniert: Status erfassen, nach der Remediation erneut pruefen und den Nachweis behalten, dass die temporaere Mitigation tatsaechlich wieder entfernt wurde.

Was nach dem Einspielen der Fixes validiert werden sollte

Eine Copy-Fail-Reaktion sollte nicht bei "Paket aktualisiert" enden. Die Validierungsphase ist der Ort, an dem sich temporaere Mitigations, ausstehende Neustarts und teilweise Rollouts am haeufigsten verstecken.

Der zentrale operative Fehler waere, den Workaround wie einen vollstaendig validierten Fix zu behandeln. Die Herstellerdokumentation stuetzt das nicht. Der Workaround kauft Zeit; der gefixte Kernel und die Post-Change-Validierung schliessen den Vorgang ab. Fuer Log- und Eskalationssichtbarkeit rund um angrenzende Identitaetssysteme kann dies mit Active Directory Sicherheitsueberwachung: Event IDs fuer SIEM, die zaehlen gekoppelt werden, wenn der betroffene Linux-Host auf einem Administrationspfad liegt oder in eine groessere Incident-Review einfliesst.

Warum diese CVE fuer Identitaets- und Infrastrukturteams weiter relevant ist

Copy Fail gehoert nicht zum AD/Azure-Vulnerability-Catalog von EtcSec, und dieser Artikel sollte nicht das Gegenteil behaupten. Er ist fuer Identitaets- und Infrastrukturteams trotzdem relevant, weil lokales root auf dem falschen Linux-System mehr als nur einen einzelnen Host veraendert.

Beispiele:

• Bastions, die fuer die Administration von Windows oder Cloud-Infrastruktur genutzt werden
• Linux-Knoten, die Automatisierungs-Credentials oder Konfigurationsgeheimnisse halten
• OpenShift- oder Container-Knoten an internen Vertrauensgrenzen
• Jump Systems in segmentierten oder air-gapped Umgebungen

Das ist der richtige Grund, diese CVE hier zu behandeln. Nicht weil sie sauber in den bestehenden Katalog passt, sondern weil Infrastrukturvertrauen, Administrationspfade und Remediation-Evidenz weiterhin wichtig sind, wenn das betroffene System in der Naehe der Identitaetsebene liegt.

Primaere Referenzen

• NVD: CVE-2026-31431
• Ubuntu: Fixes available for CVE-2026-31431 (Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability
• SUSE: SUSE responds to the copy.fail vulnerability
• SUSE CVE page: CVE-2026-31431
• Red Hat Security Bulletins: RHSB-2026-02
• Red Hat: Is my RHEL system vulnerable to the Copy Fail (CVE-2026-31431) flaw?
• Red Hat: How to Mitigate issue mentioned in CVE-2026-31431 in OpenShift 4
• Red Hat: Mitigation and Remediation for CVE-2026-31431 ("Copy Fail") in ROSA Classic and OpenShift Dedicated
• kernel.org patch references listed in NVD
• CISA Known Exploited Vulnerabilities Catalog entry for CVE-2026-31431