Claude fand eine Hypervisor-Lücke, deren einzige Lösung ein Neustart ist

Das Xen-Projekt veröffentlichte XSA-523, „beliebiges Lesen/Schreiben via Grant Copy“, am 3. November um 12:00 UTC, gültig für CVE-2026-102703 und CVE-2026-102704. Die Auswirkungsbeschreibung besteht aus einem Satz: „Ein bösartiger Gast kann beliebigen Speicher lesen und schreiben, der anderen Domains gehört, einschließlich Dom0.“ Dom0 ist die privilegierte Kontroll-Domain, die jede andere virtuelle Maschine eines Xen-Hosts verwaltet. Kann ein Gast dorthin schreiben, ist die Isolation zwischen den Mietern dieser Maschine aufgehoben.

Der Mechanismus ist eine Performance-Optimierung, die nicht mehr sicher war. Xen-Domains teilen Speicher über Grant Tables; Grant Copy erlaubt einer Domain, den Hypervisor zu bitten, Bytes zwischen zwei Adressen zu verschieben, die jeweils entweder durch eine Grant-Referenz oder eine eigene Frame-Nummer des Aufrufers benannt werden. Weil Workloads typischerweise Stapel von Kopien auf benachbarte Bereiche derselben Seite ausführen, cached Xen validierte Zuordnungen, um sie nicht erneut prüfen zu müssen. Laut Advisory waren die Bedingungen für die erneute Validierung dieses Caches „in einigen Fällen nicht korrekt“, was zwei getrennte Fehler erzeugte. Bei CVE-2026-102703 konnten „Frame-Nummern und Grant-Referenzen fälschlich verwechselt werden“, sodass eine gecachte Zuordnung wiederverwendet wurde, obwohl die nächste Operation ihren Speicher anders benannte. Bei CVE-2026-102704 war die Prüfung, die Frame-Nummern-Kopien auf den eigenen Speicher des Aufrufers beschränkt, „falsch platziert“.

Beide Pfade enden gleich: Ein Gast, der seine eigenen Hypercall-Argumente kontrolliert, kann den Hypervisor dazu bringen, in Seiten zu schreiben oder aus ihnen zu lesen, die ihm nicht gehören. Beliebiges Lesen legt Schlüssel und Geheimnisse anderer Mieter im Speicher offen; beliebiges Schreiben in Dom0 eröffnet einen Weg zum Host. Vates, das Unternehmen hinter XCP-ng, formuliert es in seiner Advisory ohne Schmuck: „Ein einzelner kompromittierter Gast kann aus seiner Isolation ausbrechen und den gesamten Host übernehmen.“

Die Behebungsgeschichte ist schlimmer als der Fehler. Xen erklärt, es gebe keine bekannte Mitigation: kein Konfigurationsschalter, kein Wechsel des Gasttyps, kein Feature-Toggle. Die Lösung ist ein gepatchter Hypervisor, und ein gepatchter Hypervisor greift erst nach einem Neustart des Hosts oder von Dom0. Upstream-Patches reichen von xen-unstable bis hinunter zu 4.17.x; für Xen 4.6 bis 4.16 listet die Advisory nichts, wobei der 4.16-Zweig seinen Sicherheitssupport im Dezember 2024 verlor. Alle Versionen ab 4.6 sind verwundbar. Downstream lieferten XCP-ng 8.3 sowie Citrix XenServer 8.4 und 9 am selben Tag Updates, SUSE veröffentlichte eine Korrektur für SLE 15 SP7, Qubes gab QSB-121 mit einer Korrektur im Security-Testing-Repository heraus, und Red Hat erklärte seine Produkte für nicht betroffen. Debians Tracker führte bookworm, trixie und forky am 4. November noch als verwundbar, nur sid war korrigiert; Ubuntu listete seine Pakete als noch zu bewerten. Xen hat keinen CVSS-Score veröffentlicht, und keiner der beiden CVEs steht in CISA's Katalog bekannter Ausnutzung.

Die Offenlegung markiert auch eine Verschiebung dabei, wer Infrastrukturfehler findet. XSA-523 schreibt Anthropic und dem Einsatz von Claude die Entdeckung beider Lücken zu; Stephan Lipp von Ada Logics validierte sie, das CodeAnt AI Security Research Team meldete sie unabhängig. Das ist jene Schicht, in der solche Funde früher jahrelang unveröffentlicht blieben: Grant-Table-Code in Hypervisoren ist klein, alt, stark geprüft und selten berührt – genau das Profil, das einen geduldigen automatisierten Leser belohnt. Kein Anbieter berichtet von Ausnutzung.

Für Betreiber ist das praktische Problem der Bestand, nicht die Dringlichkeit des Patches. Die meisten Organisationen betreiben Xen nicht selbst; ihre Hosting-, VPS- und Multi-Tenant-SaaS-Anbieter könnten es tun. Die Fragen lauten: Auf welchem Zweig laufen diese Hosts, ist der Patch installiert, und wurde die Maschine seither tatsächlich neu gestartet – und für alle auf 4.6 bis 4.16, ob es überhaupt einen Vendor-Backport gibt. Xen hat XSA-529 und XSA-530 bereits für den 10. November vorangekündigt; wer Wartungsfenster plant, sollte zwei einplanen.