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 19. August 2026 zeigt die offizielle Lage eine hochschwere Schwachstelle in der Komponente algif_aead, von allen grossen Linux-Distributoren veroeffentlichte, gefixte Kernel-Pakete und die Aufnahme in den CISA Known Exploited Vulnerabilities Catalog seit dem 1. Mai 2026. Das Bild hat sich seit der Offenlegung veraendert: Die temporaeren, modul-deaktivierenden Mitigations, die Ende April veroeffentlicht wurden, waren eine Uebergangsloesung, und die Hersteller haben inzwischen gefixte Kernel ausgeliefert und begonnen, sie zurueckzuziehen.

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 zwei Schwachstellenklassifikationen unterschiedlicher Herkunft auf — CWE-669 (Incorrect Resource Transfer Between Spheres, die Klassifikation, die auch CISA in KEV verwendet) und CWE-1288 (Improper Validation of Consistency within Input, von Red Hat) — und listet acht kernel.org-Patch-Referenzen fuer stabile Branches.

Bei den betroffenen Versionen ist der Upstream-Eintrag eindeutig. Die Regression wurde durch den Commit 72548b093ee3 eingefuehrt, sodass die CVE Linux 4.14 und neuer betrifft, mit Fixes in den stabilen Releases 5.10.254, 5.15.204, 6.1.170, 6.6.137, 6.12.85, 6.18.22 und 6.19.12. Distributionen bilden das auf ihre eigenen Paketversionen ab: Ubuntu gibt an, dass das Problem jede Release vor Resolute (26.04) betrifft, und SUSE gibt an, dass Kernel ab 4.14 betroffen sind, von SLES 12 SP5 bis SLES 16.0, wobei SLES 11 zu alt ist, um betroffen zu sein.

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.

Diese Einstufung ist nicht spekulativ. Das Bulletin von Red Hat veroeffentlicht eine Remediation-Timeline, wonach der Melder am 29. April 2026 einen Blogbeitrag, ein technisches Write-up und einen Proof-of-Concept veroeffentlichte, dass am selben Tag ein Metasploit-Modul veroeffentlicht wurde und dass die CISA die CVE zwei Tage spaeter in KEV aufnahm. Ubuntu bestaetigt, dass der veroeffentlichte Exploit auf Deployments ohne Container-Workloads abzielt. Dieser Artikel reproduziert nichts davon — aber ein funktionierender oeffentlicher Exploit ist ein Triage-Signal und erklaert, warum sich die Hersteller-Zeitplaene so verdichtet haben.

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 boesartige Workloads ausfuehren koennen: Die Schwachstelle kann container escape scenarios erleichtern. Das Bulletin RHSB-2026-002 von Red Hat enthaelt separate produktspezifische Mitigationsabschnitte fuer OpenShift 4 und fuer Managed OpenShift (ROSA Classic, ROSA HCP, ARO und OpenShift Dedicated), was bestaetigt, dass der Hersteller Container-Plattformen als eigenen operativen Track behandelt. SUSE trifft von der anderen Seite dieselbe Unterscheidung: Rancher Prime, RKE2 und K3s sind nicht direkt betroffen, aber privilegierte Container mit nicht vertrauenswuerdigen Workloads koennen weiterhin einen Weg zur Kernel-Schwachstelle bieten, weshalb SUSE auf Pod Security Admission und aequivalente Kontrollen verweist statt auf einen Produktpatch.

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.

Bei der Offenlegung veroeffentlichte das Ubuntu Security Team eine Mitigation, die das betroffene Modul algif_aead ueber das Paket kmod deaktiviert. Ubuntu hat diesen Hinweis inzwischen aktualisiert: Gefixte Kernel-Pakete sind jetzt verfuegbar, und die kmod-Mitigation wird zurueckgenommen, sodass das Blockieren des Moduls ein Fallback fuer Hosts ist, die das Kernel-Update noch nicht einspielen koennen, und nicht das Ziel. SUSE dokumentiert einen aequivalenten modprobe-Workaround (blacklist algif_aead plus install algif_aead /bin/false) und hat Updates fuer alle gepflegten SUSE-Linux-Enterprise- und openSUSE-Leap-Distributionen veroeffentlicht.

Red Hat ist die Ausnahme, die man kennen sollte. Auf RHEL ist der betroffene Code fest in den Kernel einkompiliert und kann nicht als Modul geblockt werden; der dokumentierte Uebergangsschritt ist deshalb ein Boot-Argument — initcall_blacklist=algif_aead_init, oder initcall_blacklist=af_alg_init, um die AF_ALG-Schnittstelle vollstaendig zu blockieren — mit einem ausdruecklichen Hinweis auf Performance-Auswirkungen fuer alles, was Kernel-Kryptofunktionen nutzt. Eine modprobe-Regel, die aus einem Debian- oder SUSE-Runbook uebernommen wird, hat dort keine Wirkung.

Jede dieser Massnahmen verschafft Zeit und bringt jeweils eigene 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

Das Bulletin RHSB-2026-002 von Red Hat ist jetzt als Resolved markiert und besagt, dass alle Fixes verfuegbar sind. Zwei Red-Hat-Seiten sind tatsaechlich oeffentlich zugaenglich und liefern den massgeblichen Produktstatus: das Bulletin selbst und die Red-Hat-CVE-Seite fuer CVE-2026-31431, die die betroffenen Produkte, die veroeffentlichten Errata, Red Hats eigene Important-Einstufung und die CWE-Zuordnung auflistet. Die von diesen Seiten verlinkten How-to-Artikel zu RHEL, OpenShift 4 und ROSA/OpenShift Dedicated sind ausschliesslich fuer Abonnenten zugaenglich, sodass ein Engineer, der dorthin verwiesen wird, zuerst ein Red-Hat-Konto benoetigt.

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 Bulletin RHSB-2026-002: Cryptographic Subsystem Privilege Escalation - Linux Kernel (CVE-2026-31431) - Copy Fail
• Red Hat CVE database: CVE-2026-31431
• Red Hat: Is my RHEL system vulnerable to the Copy Fail (CVE-2026-31431) flaw? (subscription required)
• Red Hat: How to mitigate the Copy Fail CVE-2026-31431 in OpenShift 4 (subscription required)
• Red Hat: Mitigation and Remediation for CVE-2026-31431 ("Copy Fail") in ROSA Classic and OpenShift Dedicated (subscription required)
• kernel.org patch references listed in NVD
• CISA Known Exploited Vulnerabilities Catalog entry for CVE-2026-31431