Was, wenn ein neun Jahre alter Linux-Kernel-Bug in einer Standard-Dateisystemfunktion jedem lokalen Benutzer dauerhafte Root-Rechte verschaffen kann? Genau diese Frage stellt CVE-2026-64600, genannt RefluXFS: eine Race-Condition im XFS-Reflink-Code, die Qualys am 22. Juli 2026 öffentlich machte und die auf Standard-Installationen von Red Hat Enterprise Linux, Fedora Server und Amazon Linux direkt zur Eskalation auf root führt. Laut NVD erreicht die Schwachstelle einen CVSS-v3.1-Base-Score von 7.8 (High). Die Lücke existiert seit Linux 4.11 – also seit 2017 – und blieb fast ein Jahrzehnt unentdeckt.

RefluXFS im Überblick: Neun Jahre alte Race-Condition im Linux-Kernel

Wie CVE-2026-64600 funktioniert

RefluXFS nutzt eine Race-Condition in der XFS-Copy-on-Write-Implementierung. Ein unprivilegierter lokaler Benutzer klont eine root-eigene Datei mit FICLONE; dazu reicht Leserecht auf die Quelldatei. Beide Dateien verweisen anschließend auf dieselben physischen Blöcke. Führt der Angreifer nun parallele O_DIRECT-Schreibzugriffe auf den Klon aus, entsteht während der KoW-Reservierung ein Zeitfenster, in dem das Dateisystem die alte Blockadresse erneut verwendet. Der Schreibvorgang landet dadurch nicht im Klon, sondern überschreibt das Original – beispielsweise /etc/passwd oder ein setuid-root-Binary.

Der entscheidende technische Aspekt: Da der Schreibzugriff direkt auf der Blockschicht erfolgt, bleiben Eigentümer, Berechtigungen, Zeitstempel und das setuid-Bit des Ziels unverändert. Ein manipuliertes setuid-root-Binary wird also weiterhin als root ausgeführt, ohne dass Sicherheitstools wie SIEM oder Datei-Integritätsmonitoring Alarm schlagen. Qualys demonstrierte den Angriff auf einer Standard-RHEL-10.2-Installation: Das üblicherweise in weniger als zehn Sekunden gelingt.

Betroffene Versionen und Distributionen

Drei Bedingungen müssen gleichzeitig erfüllt sein: Linux 4.11 oder neuer ohne den RefluXFS-Fix, ein XFS-Dateisystem, das mit reflink=1 erstellt wurde, sowie ein lesbares Ziel und ein beschreibbares Verzeichnis auf demselben XFS-Dateisystem. Die betroffenen Standard-Installationen laut Qualys und Red Hat umfassen Red Hat Enterprise Linux 8, 9 und 10 sowie deren Derivate, Fedora Server 31 und neuer, Amazon Linux 2023 und Amazon-Linux-2-Images ab Dezember 2022.

RHEL 7 ist nicht betroffen, weil XFS-Reflink dort noch nicht unterstützt wurde. Debian, Ubuntu, SUSE und openSUSE verwenden XFS üblicherweise nicht als Root-Dateisystem, sind aber gefährdet, wenn Administratoren bei der Installation bewusst reflink=1 aktiviert haben. Die Prüfung ist einfach: xfs_info / | grep reflink= zeigt sofort, ob die zweite Bedingung greift.

Angreifer im Wohnzimmer des Kernels: Warum RefluXFS so gefährlich ist

Von lokaler Shell zu dauerhaftem Root

Typische Angriffsszenarien sind Multi-Tenant-Server, Container-Hosts, Build-Agents oder Entwickler-Workstations, auf denen nicht vertrauenswürdiger Code läuft. Ein lokaler Account – etwa über einen kompromittierten Web-Service, einen CI-Job oder einen Shell-Zugang – genügt, um die Rechte eskalation auszulösen. Anders als bei Speicherfehlern wie Dirty COW basiert RefluXFS auf einer Block-Layer-Schreiboperation; daher helfen KASLR, SMEP, SMAP, SELinux Enforcing, seccomp, Kernel Lockdown oder Container-Grenzen laut Qualys nicht.

Ein Sicherheitsadministrator, der bislang glaubte, mit modernen Exploit-Mitigations und Mandatory-Access-Control abgesichert zu sein, sieht sich hier mit einer völlig anderen Kategorie von Bedrohung konfrontiert. Der Angriff hinterlässt zudem praktisch keine Spuren, weil Metadaten des Ziels unverändert bleiben. Er überlebt auch einen Neustart: Ein überschriebenes setuid-root-Binary bleibt persistent auf der Platte.

Langzeitwirkung und Supply-Chain-Risiko

Da der Bug neun Jahre lang im Kernel schlummerte, kann er in ungepatchten Systemen, Backup-Images, Golden-Master-VMs und IoT-Geräten mit langem Lebenszyklus weiterexistieren. Build-Pipelines, die auf RHEL- oder Fedora-basierte Container-Images setzen, müssen prüfen, ob diese Images vor dem 16. Juli 2026 erstellt wurden. Die Schwachstelle zeigt erneut, wie lange Latenzzeiten zwischen Bug-Einführung und Entdeckung selbst im Linux-Kernel auftreten können – und wie wichtig regelmäßige Kernel-Updates und Reboots im Patch-Rhythmus sind.

Patch-Stand: Wer hat Fixes veröffentlicht?

Red Hat, Fedora und Amazon Linux

Red Hat hat die Lücke mit Important-Rating eingestuft und mehrere Kernel-Errata veröffentlicht: RHSA-2026:39179, RHSA-2026:39180 für RHEL 8 und RHSA-2026:39494 für RHEL 10. Erweiterte Support- und SAP-Streams folgten bis zum 17. Juli 2026. Die Patches begannen bereits am 14. Juli 2026 zu landen – acht Tage vor der koordinierten Veröffentlichung. Administratoren, die ihre Systeme pünktlich gepatcht haben, waren also bereits vor der öffentlichen Bekanntmachung geschützt.

Der Upstream-Fix wurde am 16. Juli 2026 in den Linux-Kernel-Tree gemerged; der Commit 2f4acd0fcd862e22eab45690ec2c08c80b6ef2e7 ändert die Helper xfs_reflink_fill_cow_hole() und xfs_reflink_fill_delalloc(), indem er den Sequenzzähler ip->i_df.if_seq vor dem Freigeben des Inode-Locks speichert und nach dem Wiederanlegen der Sperre das Mapping neu einliest, falls sich der Zähler verändert hat. Der Fixes:-Tag verweist auf Commit 3c68d44a2b49, der Linux 4.11 einführte.

Debian, Ubuntu und andere Distributionen

Stand 23. Juli 2026 listet der Debian-Sicherheits-Tracker den Fix in trixie-security als Kernel 6.12.96-1 und in unstable als 7.1.4-1. Die Basis-Kernel 6.12.94-1 (Trixie) und 7.1.3-1 (Forky) waren noch verwundbar; ebenso bookworm und bullseye. Ubuntu und SUSE veröffentlichten Backports in ihren üblichen Sicherheitskanälen. Amazon Linux kündigte ebenfalls Kernel-Updates an, da Amazon Linux 2 und 2023 in der Standard-XFS-Konfiguration betroffen sein können.

Erkennung, Prüfung und Sofortmaßnahmen

Schritt-für-Schritt-Anleitung für Administratoren

Administratoren sollten zunächst die Verwundbarkeit ihres Bestands ermitteln. Auf jedem Linux-Host mit XFS-Dateisystemen führt der Befehl xfs_info / | grep reflink= zur schnellen Klassifizierung. Liefert die Ausgabe reflink=1, ist die zweite notwendige Bedingung erfüllt. Anschließend prüft man den laufenden Kernel: Ist er neuer als die am 16. bzw. 22. Juli 2026 veröffentlichten gepatchten Versionen? Falls nicht, muss gehandelt werden.

Als Sofortmaßnahmen empfehlen sich:

• Kernel-Update auf die vom Distributor ausgewiesene gepatchte Version einspielen.
• System rebooten und den laufenden Kernel mit uname -r verifizieren.
• Alle XFS-Volumes mit reflink=1 inventarisieren, nicht nur das Root-Dateisystem.
• setuid-root-Binaries und /etc/passwd, /etc/shadow auf Integrität prüfen.
• SIEM-Regeln für ungewöhnliche FICLONE-Aufrufe, O_DIRECT-Schreibzugriffe auf setuid-Binaries und lokale Race-Aktivitäten anpassen.

Was funktioniert nicht als Workaround

Es gibt keinen praktischen Workaround, der RefluXFS nach der Dateisystemerstellung vollständig stoppt. Ein nachträgliches Deaktivieren von XFS-Reflink ist nicht möglich. SELinux Enforcing Mode, seccomp-Profile, Kernel Lockdown, Container-Isolation und Speicherschutzmechanismen wie KASLR oder SMEP verhindern den Angriff laut Qualys nicht, weil der Exploit keine Speicherkorruption nutzt, sondern direkt auf die Block-Layer-Schreiboperation zielt. Die einzige verlässliche Abhilfe ist das Einspielen des gepatchten Kernels gefolgt von einem Reboot.

Der KI-Faktor: Wurde RefluXFS von einer KI entdeckt?

Claude Mythos Preview und der Qualys Threat Research Unit

Eine bemerkenswerte Facette der Veröffentlichung: Qualys gab an, die Schwachstelle mit Claude Mythos Preview, einem Frontier-Modell von Anthropic, gefunden zu haben. Die Forscher präsentierten dem Modell den XFS-Reflink-Code und baten darum, eine Lücke ähnlich Dirty COW zu identifizieren. Das Modell entdeckte die Race-Condition, schrieb einen funktionierenden Root-Exploit und entwarf den ersten Advisory-Entwurf. Menschliche Forscher reproduzierten den Bug auf einer Standard-Fedora-Server-44-Installation, prüften die Modell-Reasoning-Logs und führten die koordinierte Offenlegung mit den XFS-Maintainern durch.

Saeed Abbasi, Leiter der Qualys Threat Research Unit, sagte, dass nur drei Abschnitte des Modell-Entwurfs umgeschrieben werden mussten: die letzte Notiz, die Danksagungen und der Zeitplan sowie die Epigraphen, die ursprünglich Zitate aus einer Fernsehserie enthielten. Auch wenn der menschliche Verifizierungsschritt entscheidend bleibt, zeigt der Fall, wie KI-gestützte Sicherheitsforschung die Skalierung der Bug-Suche verändern kann. Es ist nicht der erste Qualys-Fund dieser Art: Einen Tag zuvor veröffentlichte das Unternehmen CVE-2026-8933, eine Race-Condition in snap-confine von Ubuntu Desktop, und im Mai 2026 eine neun Jahre alte Schwachstelle in den Kernel-ptrace-Checks.

XFS-Reflink unter der Lupe: Technischer Hintergrund für Administratoren

Was ist Reflink und warum ist es überall?

XFS-Reflink, eingeführt mit Linux 4.11, ermöglicht es, Dateien als logische Kopien anzulegen, ohne ihre physischen Datenblöcke sofort zu duplizieren. Stattdessen teilen Quelle und Klon dieselben Blöcke, bis einer der beiden in einen Block schreibt; dann erzeugt das Dateisystem via Copy-on-Write (KoW) eine private Kopie. Diese Technik spart Platz und beschleunigt Kopiervorgänge – daher wird sie in Standard-Installationen von RHEL und Fedora auf XFS-Volumes automatisch aktiviert.

Für Speicher- und Backup-Szenarien ist Reflink attraktiv, weil große virtuelle Disk-Images, Container-Layer oder Datenbank-Backups nahezu augenblicklich geklont werden können, ohne den doppelten Speicherplatz zu belegen. Genau diese weite Verbreitung macht RefluXFS aber so brisant: Eine Funktion, die als Leistungsoptimierung gedacht war, wird zum Angriffsvektor, weil die KoW-Reservierung unter bestimmten Race-Bedingungen eine veraltete Blockadresse verwendet.

Der Check-then-use-Fehler im Detail

Der Linux-Kernel liest unter dem Inode-Lock das Data-Fork-Mapping und übergibt es an xfs_reflink_fill_cow_hole(). Diese Funktion gibt den Lock kurz frei, um Transaktionsraum zu reservieren. In diesem Fenster kann ein zweiter Schreiber die KoW-Operation abschließen und den Klon auf einen neuen Block umleiten. Wenn der erste Writer den Lock wiedererlangt, refreshed er zwar die Copy-on-Write-Fork, arbeitet aber mit dem alten Data-Fork-Mapping weiter. Der Upstream-Patch behebt das, indem er den Sequenzzähler ip->i_df.if_seq vor dem Lock-Freigeben speichert und nach der Wiederanforderung das Mapping neu einliest, falls der Zähler gestiegen ist. Ohne diesen erneuten Lesevorgang schreibt O_DIRECT auf die veraltete Adresse und trifft damit das ursprüngliche Ziel.

Direct I/O ist hier entscheidend, weil es den Page-Cache umgeht und keinen Revalidierungs-Hook besitzt. Ein normaler Buffered-Write würde im Page-Cache landen und möglicherweise vor dem Commit erneut geprüft; O_DIRECT schreibt hingegen synchron auf die Platte. Für Angreifer ist das eine willkommene Eigenschaft, denn sie können die Race gezielt mit parallelen Threads und synchronen Schreiboperationen auslösen. Qualys berichtete, dass der Exploit auf ihrer Testmaschine in der Regel in unter zehn Sekunden erfolgreich war.

Incident-Response-Playbook: Was tun, wenn RefluXFS-Verdacht besteht?

Kompromiss-Anzeichen und Forensik

Da der Angriff Metadaten des Ziels nicht ändert, fällt er klassischen Integritätsprüfungen kaum auf. Administratoren sollten dennoch nach Auffälligkeiten suchen: unerwartete FICLONE– oder copy_file_range-Aufrufe auf sensible Dateien, parallele O_DIRECT-Schreibvorgänge in temporären Verzeichnissen, plötzliche Änderungen im Verhalten von setuid-Binaries oder unerklärliche Root-Aktivitäten nach einem lokalen Login. Ein Audit der letzten Kernel-Versionen, Patch-Datum und letzter Reboot-Zeit hilft, die Expositionszeit einzugrenzen.

Forensisch gilt: Da der Angriff persistente Änderungen am Dateisystem hinterlässt, reicht das bloße Patchen nicht, um eine mögliche Kompromittierung zu bereinigen. Wenn ein System in der exponierten Zeit nicht vertrauenswürdige lokale Prozesse ausgeführt hat, sollten kritische Systemdateien und setuid-Binaries gegen bekannte Good-Hashes verglichen oder das System aus einem verifizierten Image wiederhergestellt werden. In hochsensiblen Umgebungen empfiehlt sich eine Neuinstallation mit gepatchtem Kernel, bevor der Rechner wieder in Produktion geht.

Kommunikation und Eskalation

IT-Sicherheitsteams sollten RefluXFS in die aktuelle Bedrohungslage aufnehmen und Betriebsverantwortliche informieren, wenn RHEL-, Fedora- oder Amazon-Linux-Systeme ohne Juli-2026-Patch im Einsatz sind. Die Priorisierung sollte nach Exposition erfolgen: Internet-facing Server, Multi-Tenant-Hosts, CI/CD-Runner und Entwicklungs-Workstations zuerst; isolierte, gut gehärtete Management-Systeme danach. Ein kurzes Status-Update mit der Anzahl gepatchter und noch verwundbarer Systeme sowie dem Reboot-Plan hilft, das Management-Risiko transparent zu machen und Ressourcen für das Rollout zu mobilisieren.

Vergleich mit anderen aktuellen Kernel- und Systemlücken

RefluXFS hebt sich von den anderen Einträgen ab, weil es weder ein Netzwerk-Dienst noch eine Anwendungsschwachstelle ist. Es betrifft das Betriebssystem-Dateisystem selbst und erfordert deshalb ein klassisches Kernel-Patch-Management, das in Cloud-Umgebungen oft durch Live-Patching oder ausgefeilte Update-Strategien ersetzt wurde. Genau diese Standard-XFS-Installationen zeigen aber, warum der Kernel weiterhin im Patch-Fokus stehen muss.

Fazit und Handlungsempfehlung

CVE-2026-64600 zeigt, dass selbst im reifen Linux-Kernel neun Jahre alte Race-Conditions im Standard-Dateisystem-Code existieren können, die unter realen Bedingungen zuverlässig zur Root-Übernahme führen. Die Kombination aus weitreichender Verbreitung von XFS mit reflink auf RHEL-Derivaten, fehlenden praktischen Workarounds und der Tatsache, dass der Angriff praktisch spur- und persistent ist, macht RefluXFS zu einer der wichtigsten Kernel-Schwachstellen des Jahres 2026.

Betreiber von RHEL-, Fedora- und Amazon-Linux-Systemen sollten sofort prüfen, ob ihr Kernel die im Juli 2026 veröffentlichten Fixes enthält, und ein Reboot durchführen. In Multi-Tenant-Umgebungen, Build-Clustern und Container-Hosts ist diese Prüfung besonders dringlich. Gleichzeitig empfiehlt es sich, XFS-Dateisysteme mit reflink=1 zu inventarisieren und sicherzustellen, dass Patch-Zyklen für den Kernel nicht durch Live-Patching-Optimismus ersetzt werden.

Wer die technischen Details nachlesen möchte, findet sie im Qualys Advisory, bei The Hacker News sowie im Linux Upstream Patch. Weitere distributionspezifische Informationen bieten der Red Hat CVE Tracker und der Debian Security Tracker. Der CISA KEV Catalog listet die Schwachstelle, sobald aktive Ausnutzung nachweisbar ist, und dient als zusätzlicher Priorisierungsmaßstab.