Agentic AI
Mai 7, 2026
Julia Wolf 
732 Byte Python-Code. Ein lokaler User-Account. Danach gehört der Server jemand anderem. CVE-2026-31431, Codename „Copy Fail“, ist seit Mai 2026 in aktiver Ausnutzung — und die CISA hat bereits Alarm geschlagen. Warum diese Linux-Schwachstelle so gefährlich ist, wie ganze Serverflotten kippen können und was Admins jetzt konkret tun müssen.
Manchmal liegt das Problem nicht im Angriff. Es liegt darin, wie lange die Lücke schon da ist. CVE-2026-31431 — intern „Copy Fail“ genannt — wurde von den Forschern des Cybersecurity-Unternehmens Theori mithilfe ihrer KI-Plattform Xint Code entdeckt. Das Pikante daran: Der zugrundeliegende Logikfehler schlummert seit mindestens 2017 im Linux-Kernel. Fast zehn Jahre. In Produktionssystemen, in Cloud-Instanzen, auf Unternehmensservern. Mehr Kontext liefert Cyberprotection: Was Unternehmen wirklich vor Angriffen schützt.
Der CVSS Base Score liegt bei 7.8. Das klingt nach einer Zahl unter vielen. Es ist sie nicht. Was diesen Bug von früheren Linux-Schwachstellen unterscheidet, ist seine erschreckende Zuverlässigkeit — aber dazu gleich. Wer tiefer einsteigen möchte, findet in SAP KI-Agenten am Rand: Mensch in der Fertigung weiteren Hintergrund.
Betroffen sind keine exotischen Nischenkernel. Verifiziert verwundbar sind laut CERT.at unter anderem Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 und SUSE 16. Sprich: die Standardausrüstung moderner IT-Infrastruktur. Das sind keine Randdistributionen. Das ist das, worauf ein erheblicher Teil des Internets läuft.
Zum Verständnis der zeitlichen Dimension: 2017 war das Jahr, in dem viele der heute laufenden Cloud-Architekturen grundgelegt wurden. Kubernetes wurde gerade populär. DevOps-Pipelines etablierten sich als Standard. Microservice-Architekturen erlebten ihren Durchbruch. All diese modernen Infrastrukturmuster wurden auf einem Fundament aufgebaut, das bereits einen schläfrigen Logikfehler im Kernel trug — ohne dass irgendjemand es wusste. Das ist keine Kritik an einzelnen Entwicklern. Der Linux-Kernel umfasst mittlerweile über 27 Millionen Codezeilen. Dass ein subtiler Fehler in dieser Masse jahrelang unentdeckt bleibt, ist erschreckend, aber nicht unplausibel.
Was die Entdeckung durch KI-gestützte Analyse besonders bedeutsam macht: Xint Code hat offenbar Muster erkannt, die menschliche Code-Reviewer in zahllosen Audits übersehen haben. Das ist kein Vorwurf an die Open-Source-Community, die enormen Aufwand in die Sicherheitsüberprüfung des Kernels steckt. Es ist ein Hinweis darauf, dass KI-gestützte statische Analyse möglicherweise eine neue Kategorie von Sicherheitswerkzeugen darstellt — und dass ihr Einsatz künftig nicht optional, sondern zwingend sein wird.
Die Schwachstelle basiert auf einem Logikfehler im Kernel. Angreifer können damit gezielt vier Bytes in den Seitencache beliebiger Dateien schreiben. Vier Bytes. Das klingt nach wenig. Es ist genug.
Der entscheidende Unterschied zu älteren Privilege-Escalation-Lücken: Copy Fail braucht kein präzises Timing, keine Race Conditions, keine Glückstreffer. Dirty Cow aus dem Jahr 2016 war instabil, erforderte mehrfache Versuche und konnte Systeme zum Absturz bringen. Dirty Pipe von 2022 hatte ähnliche Schwächen. Copy Fail funktioniert nach Einschätzung der Theori-Forscher zuverlässig — und das mit einem Python-Skript von 732 Byte. Weniger als eine durchschnittliche E-Mail-Signatur.
Das Ergebnis dieser Rechteausweitung: Ein lokaler Nutzer ohne jegliche Privilegien erreicht Root-Rechte. Voller Zugriff. Keine Einschränkungen mehr durch AppArmor oder SELinux — denn diese Sicherheitsmodelle greifen unterhalb der Root-Ebene. Wer Root ist, hat gewonnen. So einfach ist das.
Um den technischen Mechanismus etwas greifbarer zu machen: Der Seitencache des Linux-Kernels ist eine temporäre Zwischenspeicherung von Dateiinhalten im RAM, die Lesezugriffe beschleunigt. Der Logikfehler in CVE-2026-31431 ermöglicht es, diesen Mechanismus so zu manipulieren, dass Schreibzugriffe in Dateibereiche möglich werden, für die der angreifende Prozess eigentlich keine Schreibrechte besitzt. Vier Bytes an der richtigen Stelle — etwa in einer setuid-Binary oder in einer Konfigurationsdatei, die beim Systemstart gelesen wird — reichen aus, um die Privilegienstruktur des gesamten Systems zu kippen. Die Eleganz des Angriffs liegt in seiner Einfachheit: Es wird keine Speicherkorruption erzwungen, kein Heap-Spray benötigt, kein komplexes Timing koordiniert. Der Kernel tut genau das, was er tun soll — nur eben in einem Kontext, in dem er es nicht sollte.
Und noch etwas macht die Sache besonders unangenehm: Der Exploit läuft lokal, vollständig unterhalb des Radars gängiger Sicherheits-Scanner. Kein IDS-Alert. Kein Firewall-Log. Ein stiller Kompromiss.
Häufiges Missverständnis bei solchen Meldungen: „Lokal ausnutzbar bedeutet, der Angreifer muss physisch vor dem Gerät sitzen.“ Falsch. Lokal bedeutet hier: Ein gültiger User-Account auf dem System reicht aus. Über SSH. Über eine kompromittierte Web-Applikation. Über einen schwach gesicherten Container.
Meiner Einschätzung nach ist genau das der gefährlichste Aspekt dieser Schwachstelle. In modernen Cloud-Infrastrukturen ist ein erster Fuß in der Tür erschreckend oft nur eine schlecht konfigurierte Webanwendung, ein durchgesickertes Passwort oder ein Container mit zu weiten Berechtigungen entfernt. Ab dann übernimmt Copy Fail den Rest.
Das Angriffsszenario in der Praxis: Ein Angreifer findet einen Schwachpunkt in einer Webanwendung auf einer AWS EC2-Instanz mit Amazon Linux 2023. Er erlangt einen Shell-Zugriff als unprivilegierter App-User. Dann kommt das 732-Byte-Skript. Danach hat er Root-Rechte auf der gesamten Instanz. SSH-Keys auslesen, weitere Instanzen ansteuern, laterale Bewegung durch den Servercluster. Was als einzelner kompromittierter Dienst beginnt, kann sich zur vollständigen Infrastrukturübernahme ausweiten.
Ein weiteres realistisches Szenario betrifft Shared-Hosting-Umgebungen, wie sie vor allem bei kleineren Unternehmen, Agenturen und Entwicklern verbreitet sind. Wer einen Account auf einem gemeinsam genutzten Linux-Server hat — sei es für ein Webhosting-Paket, eine Entwicklungsumgebung oder einen CI/CD-Runner — befindet sich potenziell in derselben lokalen Umgebung wie Dutzende andere Kunden desselben Anbieters. Copy Fail bedeutet: Jeder dieser Accounts könnte theoretisch zum Sprungbrett für eine vollständige Host-Kompromittierung werden, die alle anderen Kunden mitbetrifft. Für Hosting-Anbieter ist das kein akademisches Problem. Es ist eine akute Gefährdung ihres gesamten Kundenstamms.
Auch im Unternehmenskontext ist „lokal“ keine Entwarnung. In vielen Organisationen haben Entwickler, Datenbankadministratoren, externe Dienstleister und automatisierte CI/CD-Systeme SSH-Zugriff auf Produktionsserver. Jeder dieser Zugänge — egal wie gut er im Normalfall abgesichert ist — wird zu einem potenziellen Angriffsvektor, sobald die Zugangsdaten kompromittiert werden. Und Zugangsdaten werden kompromittiert. Regelmäßig. Durch Phishing, durch Credential-Stuffing, durch schlecht gesicherte API-Keys in öffentlichen Git-Repositories.
Einzelne Server sind schlimm genug. In Cloud- und Container-Umgebungen multipliziert sich das Risiko. Wer Root-Rechte auf einem Host erlangt, kann unter Umständen aus Containern ausbrechen und benachbarte VMs angreifen. Shared-Hosting-Plattformen, auf denen viele Kunden denselben physischen Host teilen, sind besonders exponiert.
Das sind keine theoretischen Szenarien. Die CISA — die US-amerikanische Cybersecurity-Behörde — hat aktive Ausnutzung von Copy Fail in freier Wildbahn bestätigt. Das bedeutet: Irgendwo laufen gerade Angriffe. Nicht in einem Proof-of-Concept-Labor. In echten Produktionssystemen.
Plot Twist: Hostingprovider und Cloud-Anbieter sind doppelt betroffen. Einerseits als Betreiber eigener Infrastruktur. Andererseits als Anbieter, deren Kunden eigene Linux-Instanzen betreiben — und für deren Patching sie keine direkte Verantwortung tragen, aber sehr wohl die Haftungsfragen aushalten müssen, wenn etwas schiefläuft. Verantwortung ist in der Cloud eine erstaunlich dehnbare Kategorie.
Besonders kritisch wird die Situation in Kubernetes-Clustern. Wer in einem solchen Cluster einen Pod kompromittiert, der auf einem ungepatchten Node läuft, und über Copy Fail Root-Rechte auf dem Node erlangt, hat potenziell Zugriff auf alle anderen Pods desselben Nodes — inklusive deren Secrets, Umgebungsvariablen und Netzwerkverbindungen. In gut konfigurierten Clustern mit strengen Pod Security Standards und Network Policies ist der Schaden begrenzt. In der Realität vieler Produktions-Cluster, die über Jahre gewachsen sind und deren Sicherheitskonfiguration nie vollständig gehärtet wurde, kann ein einziger kompromittierter Pod zum Ausgangspunkt einer vollständigen Cluster-Übernahme werden. Das CISA-Confirmed-Status von Copy Fail macht dieses Szenario nicht hypothetisch. Es macht es wahrscheinlich.
Um einzuordnen, wie brisant diese Schwachstelle wirklich ist, lohnt ein kurzer Blick auf die Vorgänger. Dirty Cow, CVE-2016-5195, war eine berühmte Race-Condition-Lücke — gefährlich, aber instabil. Angriffe konnten fehlschlagen, Systeme abstürzen lassen, Spuren hinterlassen. Dirty Pipe, CVE-2022-0847, funktionierte ebenfalls über den Seitencache, konnte aber ebenfalls zum Crash führen.
Copy Fail macht keinen dieser Fehler. Die Theori-Forscher beschreiben den Exploit als zuverlässig und ohne die Risiken eines Systemabsturzes, die ältere ähnliche Angriffe mit sich brachten. Für Admins bedeutet das: Es gibt kein zuverlässiges Signal, dass ein Angriff stattgefunden hat. Kein Crash-Log, kein auffälliger Prozess, kein sofortiger Alarmindikator. Das System läuft — nur eben unter fremder Kontrolle.
Die folgende Gegenüberstellung verdeutlicht, warum Copy Fail in der Reihe der Linux-Privilege-Escalation-Schwachstellen eine neue Qualitätsstufe darstellt. Dirty Cow benötigte mehrere Sekunden Laufzeit und hinterließ durch seine Race-Condition-Natur gelegentlich sichtbare Anomalien in Systemlogs. Dirty Pipe war zwar schneller, konnte aber durch falsche Byte-Platzierung Dateien korrumpieren und damit Systeminstabilität erzeugen, die Administratoren aufmerksam machte. Copy Fail hingegen ist nach Beschreibung der Forscher in Sekunden abgeschlossen, hinterlässt keine Traces in Standard-Logs und verändert den Systemzustand nicht auf eine Weise, die Monitoring-Tools typischerweise als Anomalie erkennen würden. Das macht Post-Incident-Forensik erheblich schwieriger: Wenn nicht klar ist, ob ein Angriff stattgefunden hat, lässt sich auch nicht beurteilen, was der Angreifer nach erfolgreicher Privilegienausweitung getan hat.
Zur Klarstellung, weil das regelmäßig durcheinander geworfen wird: CVE-2024-0193, eine Use-after-free-Lücke im Netfilter-Subsystem aus dem Jahr 2024, ist eine völlig andere Schwachstelle. Beide geben Angreifern potenziell Root-Rechte. Beide sind ernst zu nehmen. Aber sie sind nicht identisch, und Patches für eine schließen nicht die andere.
Kurze Antwort: Der einzige vollständige Schutz ist ein Kernel-Update. CERT.at formuliert es unmissverständlich — nur der gepatchte Kernel mit dem behobenen Commit (a664bf3d603d) schließt die zugrundeliegende Logiklücke.
Für Debian- und Ubuntu-Systeme gibt es laut CERT.at einen Workaround: Das Kernelmodul algif_aead lässt sich deaktivieren, was den Angriffsvektor einschränkt. Das ist kein vollständiger Schutz, kann aber Zeit kaufen, bis das Kernel-Update eingespielt ist.
Was explizit nicht hilft: Ein einfacher Neustart ohne Kernel-Update lädt denselben verwundbaren Kernel neu. AppArmor und SELinux bieten nach erfolgreicher Rechteausweitung keinen Schutz mehr — Root hebelt diese Mechanismen aus. Firewalls und IDS-Systeme sehen den Exploit nicht, weil er lokal und unterhalb ihres Sichtbereichs stattfindet. Die Hoffnung, ein Scanner würde anschlagen, ist verständlich. Sie ist falsch.
Ein häufig genanntes Gegenargument in Diskussionen über diese Schwachstelle lautet: „Unser System ist durch Network-Segmentierung und Perimeter-Security ausreichend geschützt. Ein Angreifer kommt gar nicht erst an einen lokalen Account.“ Das ist eine gefährliche Selbstberuhigung. Perimeter-Security schützt vor direktem Netzwerkzugriff, nicht vor den vielfältigen Wegen, auf denen Angreifer in der Praxis lokale Accounts erlangen: kompromittierte Lieferketten, Supply-Chain-Angriffe auf Softwareabhängigkeiten, Social Engineering gegen Mitarbeiter mit SSH-Zugriff, oder schlicht der Entwickler, der seinen Laptop in einem Café unbeaufsichtigt lässt. Die Annahme, der Perimeter halte perfekt, ist in modernen IT-Umgebungen mit Remote-Arbeit, Cloud-Zugriff und externen Dienstleistern nicht realistisch.
Ein weiteres Gegenargument, das in manchen Sicherheitsdiskussionen auftaucht, betrifft den Aufwand des Patchens selbst: Kernel-Updates in großen Umgebungen können Downtime erzeugen, Abhängigkeiten brechen und in kritischen Produktionssystemen mit langen Wartungsfenstern nicht ad hoc eingespielt werden. Das ist real. Dieser Aufwand ist jedoch mit dem Risiko abzuwägen, einen Server in einem Zustand zu belassen, bei dem aktive Ausnutzung durch die CISA bestätigt ist. Die Risikoabwägung fällt eindeutig aus: Kontrollierter Neustart nach geplantem Kernel-Update ist besser als unkontrollierter Kontrollverlust durch erfolgreichen Angriff.
Jetzt wird es ungemütlich. Nicht wegen des Bugs. Sondern wegen der Realität in vielen IT-Abteilungen. Patch-Management ist die Disziplin, die alle für selbstverständlich halten und die in der Praxis regelmäßig an Kapazitäten, Change-Prozessen und dem klassischen „Wir können jetzt nicht neustarten, das System läuft produktiv“ scheitert.
Ein Kernel-Update erfordert einen Neustart. In vielen Umgebungen ist ein geplanter Neustart von Produktionssystemen ein mehrstufiger Genehmigungsprozess, der Tage dauern kann. In dieser Zeit läuft ein System, von dem nun öffentlich bekannt ist, wie man es übernimmt — und von dem die CISA bestätigt, dass aktive Angriffe stattfinden.
Wenig überraschend: Genau diese Zeitspanne zwischen Disclosure und Patch ist das bevorzugte Jagdrevier gut organisierter Angreifer. Der Bug ist öffentlich. Das Exploit-Skript ist kompakt. Die Angriffsfläche ist riesig. Wer jetzt noch wartet, macht es Angreifern unnötig leicht.
Konkret zeigt sich das Patch-Management-Problem in vielen mittleren und großen Unternehmen an einer wiederkehrenden Struktur: Es gibt einen definierten Patch-Zyklus — oft monatlich, manchmal quartalsweise — und Ausnahmen erfordern einen formellen Notfall-Change-Prozess. Dieser Prozess ist aus gutem Grund bürokratisch: Ungeplante Änderungen an Produktionssystemen können Ausfälle verursachen, und in regulierten Industrien müssen Änderungen dokumentiert und genehmigt werden. Das Problem ist, dass dieser sinnvolle Prozess in Situationen wie Copy Fail zu einem Sicherheitsrisiko wird, wenn er nicht mit der nötigen Dringlichkeit aktiviert wird. Eine CISA-Bestätigung aktiver Ausnutzung sollte automatisch ein Notfall-Patch-Protokoll auslösen. In Organisationen ohne solches Protokoll wird stattdessen die nächste reguläre Patch-Runde abgewartet. Das ist fahrlässig.
Positiv formuliert bietet Copy Fail eine Gelegenheit zur Überprüfung der eigenen Notfall-Patch-Prozesse. Wer heute feststellt, dass sein Unternehmen keinen definierten Prozess für die beschleunigte Bereitstellung kritischer Sicherheits-Patches hat, sollte das als dringendes organisatorisches Problem behandeln — unabhängig davon, ob Copy Fail bereits erfolgreich gepatcht wurde.
Konkret, ohne Umschweife. Vier Schritte, absteigend nach Dringlichkeit:
algif_aead-Modul gemäß CERT.at-Empfehlung deaktivieren. Das ist keine dauerhafte Lösung, aber besser als nichts bis zum Wartungsfenster.Über diese vier unmittelbaren Maßnahmen hinaus empfiehlt sich eine erweiterte Reaktion in drei Phasen. In der ersten Phase — innerhalb der nächsten 24 bis 48 Stunden — sollte eine vollständige Inventur aller Linux-Systeme in der eigenen Infrastruktur erfolgen, inklusive Cloud-Instanzen, CI/CD-Runner, Entwicklungsumgebungen und Monitoring-Server. Systeme, die oft vergessen werden, sind häufig gerade die mit den weitesten Netzwerkzugängen und den wenigsten Augen darauf. In der zweiten Phase — innerhalb der nächsten Woche — sollten Patch-Status und angewandte Workarounds dokumentiert und dem Management kommuniziert werden. Eine CISA-Warnung mit bestätigter aktiver Ausnutzung ist ein Sachverhalt, der Sicherheitsverantwortlichen formal bekannt sein sollte. In der dritten Phase — mittelfristig — sollten die Erkenntnisse aus dem Copy-Fail-Vorfall genutzt werden, um Patch-Prozesse zu überprüfen und gegebenenfalls zu beschleunigen.
Wer Unterstützung bei der Priorisierung von Sicherheitsmaßnahmen sucht, findet in der Detailanalyse von Fosstopia weitere technische Hintergründe zur Schwachstelle.
Jenseits der technischen Dimension hat CVE-2026-31431 auch eine rechtliche und compliance-relevante Seite, die in der unmittelbaren Hektik der Incident-Response leicht übersehen wird. In der Europäischen Union schreibt die DSGVO vor, dass personenbezogene Daten durch geeignete technische Maßnahmen zu schützen sind. „Geeignet“ wird von Aufsichtsbehörden regelmäßig so ausgelegt, dass bekannte Schwachstellen mit verfügbaren Patches in angemessener Zeit zu schließen sind. Was „angemessen“ bedeutet, ist nicht klar definiert — aber CISA-bestätigte aktive Ausnutzung bei verfügbarem Patch setzt die Messlatte sehr eindeutig.
Unternehmen, die im Rahmen von NIS2 als Betreiber kritischer Infrastrukturen oder wichtiger Einrichtungen eingestuft sind, unterliegen zusätzlich expliziten Anforderungen an das Schwachstellenmanagement und müssen erhebliche Sicherheitsvorfälle innerhalb definierter Fristen melden. Ein kompromittiertes System infolge eines ungepatchten CVE-2026-31431 — bei dem CISA aktive Ausnutzung bestätigt hat — dürfte in den meisten Interpretationen meldepflichtig sein. Wer diese Meldepflicht nicht kennt oder ignoriert, riskiert Bußgelder, die deutlich teurer werden können als das Patch-Fenster, das man sich durch Verzögerung zu sparen versucht hat.
Das eigentliche Problem löst ein einzelner Patch nicht. Copy Fail ist ein Symptom. Das Symptom heißt: Ein Logikfehler war fast zehn Jahre im meistgenutzten Server-Betriebssystem der Welt unentdeckt. Erst ein KI-gestütztes Analyse-Tool hat ihn gefunden.
Ich finde das ehrlich gesagt sowohl beunruhigend als auch faszinierend. Beunruhigend, weil es bedeutet: Es könnte weitere solcher Bugs geben, die noch warten. Faszinierend, weil es zeigt, dass KI-gestützte Code-Analyse offenbar Dinge findet, die menschliche Reviewers jahrelang übersehen haben.
Das wirft eine grundsätzliche Frage über die Zukunft der Kernel-Sicherheit auf. Der Linux-Kernel wird von einer globalen Community aus Tausenden Entwicklern gepflegt und von ebenso vielen Sicherheitsforschern analysiert. Trotzdem hat ein subtiler Logikfehler fast ein Jahrzehnt überlebt. Wenn KI-gestützte Analyse-Werkzeuge wie Xint Code in der Lage sind, solche Fehler zu finden, stellt sich die Frage, warum ihr Einsatz in der Kernel-Sicherheitsforschung nicht bereits Standard ist. Die positive Interpretation: Copy Fail könnte der Anstoß sein, KI-gestützte statische Analyse systematisch in den Kernel-Review-Prozess zu integrieren. Die pessimistische Interpretation: Wenn defensive Sicherheitsforscher jetzt beginnen, solche Werkzeuge einzusetzen, tun es offensive Akteure möglicherweise schon länger — und haben möglicherweise bereits andere Bugs gefunden, die noch warten.
Die Frage, die nach dem Patch bleibt: Wie viele CVE-2026-31431-Equivalente schlummern noch in kritischer Infrastruktur? Und wer findet sie zuerst — die Verteidiger oder die Angreifer?
Bis zur Antwort gilt: Kernel patchen. Jetzt. Nicht nach dem nächsten Change-Meeting.
