Copy Fail: Linux-Sicherheitslücke zwingt Distributionen zu Eil-Patches

Ein Python-Skript, das kaum länger ist als eine Bash-Funktion, reicht aus, um aus einem gewöhnlichen Nutzeraccount einen Root-Zugang zu machen. Genau das ist mit „Copy Fail“ (CVE-2026-31431) seit wenigen Tagen öffentlich Realität, und die Distributionen reagieren mit einer Hektik, die man sonst nur von Zero-Day-Wochenenden kennt. Wer Server betreibt, Container orchestriert oder auch nur eine Homelab-Maschine mit mehreren Nutzerkonten laufen hat, sollte sich diesen Bug genauer ansehen, bevor er zur nächsten Randnotiz im Changelog wird.

Was Copy Fail technisch anrichtet

Der Name ist Programm: Beim Kopieren von Daten zwischen dem AF_ALG-Socket-Interface des Kernels und dem Systemaufruf splice() passiert etwas, was nicht passieren sollte. Betroffen ist konkret die AEAD-Authentifizierungsvorlage im kryptografischen Subsystem des Kernels, ein Bereich, den die meisten Admins noch nie bewusst angefasst haben, obwohl er ständig im Hintergrund mitläuft. Ein Logikfehler erlaubt es, unter bestimmten Bedingungen vier Bytes gezielt in den Page Cache einer eigentlich nur lesbaren Datei zu schreiben, ohne dass sich etwas auf der Festplatte ändert.

Das klingt erst einmal harmlos. Vier Bytes sind kein Buffer Overflow, keine Remote Code Execution im klassischen Sinn. Das Problem ist, welche Dateien im Page Cache liegen können: Wird die im Speicher gehaltene Kopie einer Setuid-Root-Binary wie /usr/bin/su manipuliert, führt der nächste Aufruf dieses Programms zur vollständigen Rechteausweitung auf Root, obwohl die Datei auf der Platte selbst unangetastet bleibt. Forensisch ist das ein Albtraum, weil klassische Integritätschecks auf Dateisystemebene hier komplett blind sind.

Der eigentliche Ursprung des Fehlers liegt nicht in aktuellem Code. Die fehlerhafte Optimierung stammt aus dem Jahr 2017 und steckt seitdem in praktisch jedem Kernel, der auf diesem Codepfad aufbaut. Das erklärt, warum die Liste betroffener Systeme so lang ist: Es geht nicht um eine einzelne Distribution oder einen kurzen Zeitraum, sondern um fast ein Jahrzehnt Kernel-Historie.

Der Exploit ist öffentlich – und das ändert das Tempo

Die Schwachstelle selbst wurde bereits Ende April 2026 bekannt, ein offizieller Patch existiert seitdem im Kernel-Quellcode. Neu ist, dass ein funktionierender Exploit inzwischen frei kursiert, dokumentiert unter anderem von Phoronix. Damit verschiebt sich das Risiko von „theoretisch kritisch“ zu „praktisch trivial nachbaubar“. Genau das treibt jetzt Distributionen dazu, ihre Patch-Zyklen zu beschleunigen, statt Kernel-Updates im gewohnten Rhythmus auszuliefern.

Der kursierende Proof-of-Concept ist ein Python-Skript von überschaubarer Länge, in der Praxis irgendwo zwischen zehn handgeschriebenen Zeilen und rund 732 Byte kompiliertem Code, je nachdem welche Variante gerade die Runde macht. Wer schon einmal versucht hat, einen komplexeren Exploit gegen eine ASLR-gehärtete Umgebung zu schreiben, weiß, wie ungewöhnlich kurz das für eine funktionierende Privilegienerweiterung ist. Genau diese Kürze macht den Exploit so gefährlich: Er lässt sich in Sekunden kopieren, anpassen und in automatisierte Angriffsketten einbauen.

Meine persönliche Einschätzung: Die eigentliche Nachricht ist nicht der Bug selbst, sondern wie lange er unentdeckt im Kernel lag. Neun Jahre Optimierungscode, der ungeprüft durch zahllose Reviews rutscht, sagt mehr über die Grenzen von Code-Audits in großen Projekten aus als jede einzelne CVE-Nummer.

Forensik: Die Unsichtbarkeit im Page Cache

Ein massives Problem bei der Aufarbeitung von Incidents rund um Copy Fail ist die Flüchtigkeit des Angriffsvektors. Da die Manipulation ausschließlich im flüchtigen Page Cache des Kernels stattfindet und die physische Datei auf der Festplatte unverändert bleibt, schlagen klassische Forensik-Tools in ihrer Standardkonfiguration oft nicht an. Wer nach einem Verdachtsmoment ein Offline-Image der Festplatte analysiert, wird keine manipulierten Setuid-Binaries finden. Die bösartigen vier Bytes existierten nur im Arbeitsspeicher und sind beim Herunterfahren des Systems spurlos verschwunden.

Für Incident-Response-Teams bedeutet das ein Umdenken. Statt nach veränderten Dateien zu suchen, müssen sie nach den Spuren des Exploits selbst fahnden: Auffällige Systemaufrufe in Audit-Logs, unerwartete Abstürze von Diensten oder Netzwerkverbindungen, die kurz nach einem lokalen Login aufgebaut wurden. Wer kein detailliertes Audit-Logging oder eBPF-basiertes Monitoring aktiviert hatte, steht im Nachhinein oft vor einem leeren Blatt. Das unterstreicht, dass präventives Monitoring auf Kernel-Ebene für kritische Infrastrukturen unverzichtbar ist.

Wer wirklich betroffen ist

Ausgenutzt werden kann Copy Fail nur mit lokalem Zugriff, also über ein bestehendes Benutzerkonto, eine SSH-Sitzung oder einen bereits laufenden Prozess mit eingeschränkten Rechten. Ein reiner Remote-Angriff ohne jeglichen Zugang ist damit ausgeschlossen, was manche reißerischen Schlagzeilen der letzten Tage etwas relativieren sollte. Wer seinen Server ausschließlich über eine Webanwendung ohne Shell-Zugang exponiert, ist unmittelbar weniger gefährdet.

Trotzdem bleibt die Angriffsfläche riesig. Multi-User-Server, Hosting-Umgebungen, CI/CD-Pipelines mit fremdem Code und praktisch jede Shared-Hosting-Infrastruktur sind klassische Kandidaten. Wer Kunden, Studierenden oder Mitarbeitenden Shell-Zugänge gibt, muss davon ausgehen, dass mindestens einer dieser Zugänge irgendwann für mehr als das Vorgesehene genutzt wird. Genau dafür ist eine Linux-Sicherheitslücke wie diese gemacht: Sie braucht keinen Exploit-Ketten-Zirkus, sondern nur einen einzigen kompromittierten oder böswilligen lokalen Account.

Auch Distributionen mit besonders konservativer Update-Politik sind nicht automatisch sicher. Betroffen sind sämtliche Kernel, die seit 2017 gebaut wurden, unabhängig davon, ob es sich um Ubuntu, Debian, Fedora, SUSE, Rocky Linux oder eine schlankere Distribution wie Alpine Linux handelt. Distributionsspezifische Anpassungen braucht der Exploit nicht, was die Behauptung, nur bestimmte Systeme seien gefährdet, ziemlich klar widerlegt.

Verantwortungsgrenzen bei Cloud-Providern und VPS-Hostern

Besonders knifflig wird die Situation für Mieter von virtuellen privaten Servern (VPS). Während große Hyperscaler ihre Kernel-Infrastruktur oft automatisch im Hintergrund patchen, sind klassische VPS-Hoster auf die Update-Bereitschaft ihrer Kunden angewiesen – oder liefern eigene Kernel-Images aus, die erst durch interne QA-Prozesse müssen. Wer einen Root-Server mit Standard-Debian betreibt, wartet auf die offiziellen Repository-Updates. Wer jedoch ein vom Hoster vorinstalliertes Custom-Image nutzt, sitzt im schlimmsten Fall wochenlang auf einem verwundbaren Kernel, weil der Support die CVE noch nicht priorisiert hat.

Admins sollten proaktiv beim Hosting-Support nachfragen, wann der Provider die Host-Kernel für virtualisierte Umgebungen aktualisiert. Bei KVM-basierten VPS ist der Gast-Kernel zwar Sache des Mieters, aber der Host-Kernel muss ebenfalls frei von Lücken sein, um ein Ausbrechen aus der VM zu verhindern. Die Transparenz der Anbieter variiert stark, und im Zweifel hilft nur der Wechsel auf einen Kernel, den man selbst aus den offiziellen Quellen bezieht.

Was die Distributionen aktuell liefern

Debian hat als eine der ersten großen Distributionen aktualisierte Kernel-Pakete bereitgestellt, was angesichts der jüngsten Sicherheitsupdates und Upgrade-Leitfäden fast schon konsequent wirkt. Bei anderen Distributionen hängt der konkrete Rollout-Zeitpunkt von den jeweiligen Maintainer-Zyklen ab, und genau hier zeigt sich ein strukturelles Problem: Ein Fix im offiziellen Kernel-Quellcode bedeutet nicht automatisch ein installierbares Paket im eigenen Repository.

Wer auf Rolling-Release-Systeme wie Arch Linux setzt, bekommt Kernel-Updates in der Regel schneller, muss dafür aber auch häufiger und disziplinierter selbst aktualisieren. Nutzer von Long-Term-Support-Distributionen wie Rocky Linux oder älteren Ubuntu-LTS-Zweigen sitzen dagegen oft länger auf einem bekannten, aber ungepatchten Kernel, weil Stabilität dort bewusst über Aktualität gestellt wird. Beide Modelle haben ihre Berechtigung, aber bei einer aktiven Privilegienerweiterung mit öffentlichem Exploit verschiebt sich die Kalkulation deutlich in Richtung „lieber schneller patchen“.

Admins, die mehrere Distributionen parallel betreiben, etwa eine Mischung aus Debian-Servern, ein paar Fedora-Testmaschinen und einer Handvoll Container-Hosts, sollten jetzt eine einfache Inventarliste führen: Welcher Kernel läuft wo, und ist der Fix bereits eingespielt? Das klingt banal, ist aber in gewachsenen Infrastrukturen erfahrungsgemäß die größte Fehlerquelle.

Sofortmaßnahmen, wenn das Kernel-Update noch fehlt

Bis der passende Kernel im eigenen Repository ankommt, empfehlen Sicherheitsstellen eine klare Übergangslösung: das Deaktivieren des betroffenen Subsystems, konkret des Moduls algif_aead beziehungsweise die Nutzung von AF_ALG generell einzuschränken. Das erfordert in der Regel einen Neustart des Systems, ist aber deutlich weniger aufwendig als ein kompletter Kernel-Wechsel unter Produktionslast.

Ein zweiter, oft unterschätzter Hebel ist SELinux. Läuft SELinux im enforcing-Modus mit einer sauberen Policy, wird die Ausnutzung der Schwachstelle nach aktuellem Kenntnisstand verhindert. Wichtig ist dabei die Betonung auf „enforcing“: Wer SELinux nur im permissive-Modus mitlaufen lässt, weil eine Anwendung vor Jahren mal Ärger gemacht hat, hat in der Praxis keinen echten Schutz, sondern nur ein Log, das im Nachhinein zeigt, was schiefgelaufen wäre. Für AppArmor liegen bislang keine belastbaren Aussagen zur Schutzwirkung gegen Copy Fail vor, was eher an fehlenden Tests als an mangelnder Relevanz liegen dürfte.

Wer schon einmal die Härtungsmaßnahmen nach der Dirty-Frag-Lücke im Kernel umgesetzt hat, kennt das Muster: kurzfristige Mitigation, dann geordnetes Kernel-Update, dann Verifikation. Genau dieses Vorgehen lohnt sich auch bei Copy Fail, statt in Panik ein ungetestetes Update mitten am Nachmittag auf produktive Systeme zu schieben.

Container und Kubernetes: das unterschätzte Risiko

Besonders unangenehm wird Copy Fail in Container- und Kubernetes-Umgebungen, weil Host und Container sich denselben Page Cache teilen. Klassische Container-Isolation trennt Prozesse, Namespaces und oft auch Dateisysteme, aber der Kernel-Speicher-Cache ist eine gemeinsame Ressource. Wer also in einem Multi-Tenant-Setup arbeitet, bei dem verschiedene Kunden auf demselben Host laufen, sollte diese Lücke nicht als reines Server-Thema abtun, sondern als potenzielles Ausbruchsproblem zwischen Containern behandeln.

Das ist kein rein theoretisches Szenario. Ähnliche Diskussionen gab es bereits rund um Privilege-Escalation-Lücken in Docker Desktop, wo die Grenze zwischen Host und virtualisierter Umgebung ebenfalls dünner war, als viele Betreiber angenommen hatten. Copy Fail verschärft dieses Muster, weil hier keine zusätzliche Docker-Komponente nötig ist, sondern der Kernel selbst die geteilte Angriffsfläche liefert.

Für Betreiber von Kubernetes-Clustern bedeutet das: Node-Updates priorisieren, nicht nur Pod-Images. Ein aktualisiertes Container-Image auf einem ungepatchten Node bringt an dieser Stelle herzlich wenig, weil der Angriffspunkt unterhalb der Container-Ebene liegt. Wer Cluster mit gemischten Workloads fremder Kunden betreibt, sollte die Node-Patch-Priorität deutlich vor die übliche Wartungsfenster-Planung ziehen.

Praktische Schritte für Admins und Self-Hoster

Für den eigenen Homelab-Server oder die kleine Selfhosting-Instanz reicht in vielen Fällen ein normales Systemupdate, sobald die Distribution den gepatchten Kernel bereitstellt. Wer Debian, ein aktuelles Fedora oder eine gepflegte Ubuntu-Version nutzt, sollte routinemäßig apt update && apt upgrade beziehungsweise das jeweilige Distributionsäquivalent ausführen und danach neu starten, denn ein Kernel-Update ohne Reboot bleibt wirkungslos.

Bei produktiven Multi-User-Systemen lohnt sich zusätzlich ein kurzer Blick in die Logs auf ungewöhnliche Prozessaufrufe rund um AF_ALG-Sockets oder auffällige Nutzung von splice() in Kombination mit Setuid-Binaries. Das ist kein vollständiges Monitoring-Konzept, aber ein schneller erster Filter, um zu sehen, ob bereits vor dem Patch Aktivität in diese Richtung stattgefunden hat.

Wer öffentlich erreichbare Shell-Zugänge anbietet, etwa für Studierende, Kunden oder Community-Projekte, sollte die eigene Nutzerliste kurz durchgehen: Wie viele Accounts haben tatsächlich Shell-Zugriff, und ist das noch nötig? Diese Frage stellt sich unabhängig von Copy Fail eigentlich ständig, wird aber gerne verschoben, bis genau so eine Lücke sie unangenehm aktuell macht.

Ist eine sofortige Kernel-Aktualisierung nicht möglich, etwa weil ein Wartungsfenster erst in einigen Tagen ansteht, bleibt die Kombination aus SELinux-enforcing und dem Deaktivieren von algif_aead die pragmatischste Zwischenlösung. Details zu betroffenen Subsystemen und Mitigationsschritten hat unter anderem der Sicherheitsdienstleister Consecur zusammengetragen, ergänzend zur laufenden Berichterstattung auf linuxnews.de.

Lehren aus der Vergangenheit: Dirty COW und strukturelle Blindstellen

Wer die aktuelle Hektik rund um Copy Fail beobachtet, fühlt sich an Dirty COW (CVE-2016-5195) erinnert. Auch damals handelte es sich um eine Race Condition im Speichermanagement, die jahrelang unentdeckt blieb und lokale Rechteausweitungen ermöglichte. Der Vergleich zeigt: Komplexe Optimierungen im Memory-Subsystem sind anfällig für logische Fehler, die in statischen Code-Reviews kaum auffallen. Erst unter spezifischen Bedingungen offenbart sich der Fehler.

Die Kernel-Community hat zwar massiv in Fuzzing-Tools wie Syzkaller investiert, um solche Fehler automatisiert aufzuspüren. Copy Fail beweist jedoch, dass Fuzzing allein nicht ausreicht, wenn der Fehler in einer fehlerhaften Annahme über die Zustandsmaschine des Kryptografie-Subsystems liegt. Für das Kernel-Engineering bedeutet das, dass auch alte Optimierungen regelmäßig auf den Prüfstand müssen. Bis dahin bleibt die Lücke ein Mahnmal dafür, dass kein Codepfad im Kernel zu unbedeutend ist.

Was bleibt von Copy Fail?

Bemerkenswert an dieser Linux-Sicherheitslücke ist weniger die Technik, die im Kern ein klassisches Page-Cache-Problem ist, sondern die Reaktionszeit der Community. Innerhalb weniger Tage nach Auftauchen des öffentlichen Exploits laufen Patch-Diskussionen in Mailinglisten, Foren und Distributions-Trackern parallel, und genau das ist der eigentliche Stresstest für das Open-Source-Modell. Kann eine dezentrale Struktur aus Kernel-Maintainern, Distributions-Teams und Sicherheitsforschern schneller reagieren als ein einzelner Hersteller mit geschlossenem Patch-Prozess? Bei Copy Fail sieht es bislang so aus, als würde genau das funktionieren, wenn auch mit unterschiedlichem Tempo je Distribution.

Für alle, die Linux-Systeme betreiben, bleibt die Aufgabe simpel formuliert, aber unbequem in der Umsetzung: Kernel-Version prüfen, Patch-Status der eigenen Distribution checken, Mitigation setzen, wenn das Update noch fehlt. Wer das in den nächsten Tagen konsequent durchzieht, dürfte von Copy Fail am Ende nur als weiterer Eintrag in der langen Liste kritischer Kernel-Bugs übrig behalten, nicht als reale Kompromittierung. Wer wartet, testet gerade, wie geduldig ein öffentlich verfügbarer Exploit tatsächlich ist.