Jede Cloud hat eine Mauer, von der sie behauptet, sie sei tragend. Auf einem virtualisierten Host ist diese Mauer der Hypervisor: jene dünne Codeschicht, die jeden Kunden davon überzeugt, sein Stück Maschine gehöre nur ihm. Am 3. November teilte das Xen Project der Welt mit, dass eine Mauer, die es seit 2016 pflegt, eine Tür hat, und dass eine KI diese Tür gefunden hat.
Der Advisory heißt XSA-523. Die beiden CVEs sind CVE-2026-102703 und CVE-2026-102704. Die Auswirkung in der vorsichtigen Formulierung des Projekts: «Ein bösartiger Gast kann beliebigen Speicher lesen und schreiben, der anderen Domains gehört, inklusive Dom0.»
Lies das zweimal. Nicht «ein Gast kann seinen Nachbarn zum Absturz bringen». Nicht «ein Gast leakt ein paar Bytes». Ein Gast kann in den Speicher eines anderen Kunden und in den von Dom0 greifen, der Kontroll-Domain, die den Host betreibt. XCP-ng, die Open-Source-Plattform auf Xen-Basis, formuliert es in den Update-Hinweisen noch klarer: «Ein einzelner kompromittierter Gast kann seine Isolation durchbrechen und den gesamten Host übernehmen.»
Und es gibt keine Mitigation. Nur Patches und einen Neustart.
Was genau kaputtging
Die Grant Table von Xen ist der Mechanismus, mit dem virtuelle Maschinen Speicher teilen, ohne einander zu vertrauen. Ein Gast erklärt: «Diese Seiten von mir darf jene VM lesen», und Xen setzt das Versprechen durch. Der Hypercall GNTTABOP_copy führt diese Kopien in Batches aus, und weil benachbarte Elemente eines Batches meist benachbarten Speicher derselben Seite berühren, cached Xen die validierte Beschreibung des vorherigen Elements und verwendet sie erneut, wenn das nächste äquivalent aussieht.
In diesem Cache ist die Mauer gerissen.
Der erste Fehler, CVE-2026-102703, ist eine Gültigkeitsprüfung, die zwei Identifier-Typen verwechselt. Wenn das neue Element per Machine Frame Number kopiert, vergleicht Xen diese Nummer mit dem Cache-Eintrag, ohne vorher zu prüfen, ob der Cache-Eintrag selbst ein Frame war. Eine Grant-Referenz aus einem früheren Element kann so für eine physische Framenummer gehalten werden, und der gecachte Puffer wird für Speicher wiederverwendet, auf den der Gast kein Recht hat.
Der zweite, CVE-2026-102704, ist eine Berechtigungsprüfung an der falschen Stelle. Das Kopieren per Framenummer statt per Grant-Referenz ist nur erlaubt, wenn ein Gast auf seinem eigenen Speicher arbeitet, und Xen prüft das in einer Funktion, die es beim erneuten Sperren der beteiligten Domains aufruft. Nennt das nächste Element dieselben Domains wie das vorherige, wird diese Funktion komplett übersprungen, und die Regel «nur eigener Speicher» läuft nie.
Keiner der beiden Pfade braucht eine besondere Konfiguration, root im Gast oder eine öffentliche Exploit-Kette. Beide brauchen genau eines: eine funktionierende Grant Table. Jede Xen-Version ab 4.6 ist verwundbar. Das ist ein Jahrzehnt Hypervisor, und deshalb reicht die Bedeutung weit über die Xen-Mailingliste hinaus.
Der Teil, der eure Security-Besetzung verändern sollte
Das Xen Project schreibt die Entdeckung Anthropic zu, mit Claude. Stephan Lipp von Ada Logics validierte den Fund. Das CodeAnt AI Security Research Team meldete dasselbe Problem unabhängig.
Halte diese Abfolge kurz fest. Ein Modell fand einen Logikfehler in der Speicherverwaltung der Grant Table eines Hypervisors, den zehn Jahre lang menschliche Expertinnen und Experten gelesen haben. Ein menschliches Validierungsteam bestätigte, dass der Fund echt ist. Ein zweites, unabhängiges KI-Forschungsteam kam von selbst auf denselben Fehler.
Es ist dieselbe Woche, in der Googles Threat-Intelligence-Gruppe LLMjacking-Kampagnen beschrieb, die über eine Million Dollar gestohlenen Cloud-KI-Verbrauch abziehen, und in der Wiz mehr als neun kompromittierte KI-Entwicklungsplattformen im Oktober zählte. Zwei Kurven kreuzen sich. Angreifer automatisieren Discovery und Monetarisierung mit KI, und Verteidiger haben jetzt KI, die echte Bugs in der tiefsten Schicht des Stacks findet.
Die praktische Konsequenz für einen CTO ist unbequem: Euer Patch-Kadenz orientiert sich nicht mehr an menschlichen Forschern. Sie orientiert sich an Maschinen, die die ganze Nacht Kernel-Code lesen.
Wer exponiert ist und wer nicht
Wer eine VM bei einem Hyperscaler mietet, überlässt den Patch dem Anbieter, und die Exposition hängt an dessen Wartungsfenster. Fragt nach. In einer Managed Cloud kann die Sicht des Gasts hinter dem echten Patch-Stand des Hosts zurückliegen, deshalb zählt nur eine schriftliche Antwort des Anbieters.
Wer eine eigene Xen- oder XCP-ng-Umgebung betreibt, was bei Hosting-Anbietern, Agenturen mit Kundeninfrastruktur und allen, die on-premise virtualisieren, üblich ist, hat die Uhr selbst in der Hand.
- Xen unstable bis 4.19.x: xsa523-1.patch und xsa523-2.patch anwenden.
- Xen 4.18.x bis 4.17.x: xsa523-4.18-1.patch und xsa523-4.18-2.patch anwenden.
- Xen 4.6.x bis 4.16.x: kein Upstream-Patch. Diese Branches sind End of Life. Wer hier steht, hat keinen Patch-Moment, sondern einen Migrationsmoment.
- XCP-ng 8.3 LTS: xen-4.17.7-4.2.xcpng8.3 einspielen und den Host neu starten. Vates bewertet die Auswirkung als kritisch.
- Qubes OS 4.3: Xen-Pakete 4.19.6-3 in dom0, dom0-Neustart erforderlich. Wer Anti Evil Maid nutzt, muss die Passphrase neu versiegeln, weil die neuen Xen-Binaries PCR18 und PCR19 verändern.
Zwei operative Wahrheiten aus früheren Hypervisor-Schrecken gelten erneut. Erstens: Patches sind gegen stabile Branches vorbereitet, also zuerst auf die Spitze des Branches aktualisieren, sonst blockt ein Release-Tarball. Zweitens: Patchen stoppt künftige Angriffe, sagt aber nichts darüber, ob bereits einer stattgefunden hat. Ein Gast, der fremden Speicher liest, hinterlässt beim Nachbarn keine Spur in den Logs. Wer nicht vertrauenswürdige Mandanten hostet, beginnt mit dem Patch die Incident-Review, nicht mit dem Abschluss.
Was wir tun, und was wir für euch tun würden
Bei aratech behandeln wir Hypervisor-Patches als Change der Klasse eins: geplantes Reboot-Fenster, Mandanten-Info, Snapshot vor dem Neustart und danach ein Blick ins Changelog des Pakets, damit wir den XSA-Eintrag belegen können, statt ihn anzunehmen. Kunden auf gemeinsam genutzter virtualisierter Infrastruktur bekommen eine Frage schriftlich beantwortet: welcher Hypervisor, welche Version, welcher Patch-Stand.
Die Kurzfassung für diese Woche:
- Inventarisiert den Hypervisor, nicht nur die VM. Auf Xen-Hosts hilft
xl info | grep '^xen_version', im Gast bestätigtcat /sys/hypervisor/type. Die meisten Teams kennen ihre OS-Versionen und haben keine Ahnung, was darunter liegt. - Holt euch von jedem Anbieter den XSA-523-Status schriftlich, inklusive Branch und Reboot-Datum. «Wir sind gepatcht» ohne Versionsnummer ist eine Vermutung.
- Patchen, neu starten, verifizieren. Ein Hypervisor-Patch ohne Reboot ist eine Notiz im Ticket, kein Fix.
- Wer End-of-Life-Branches betreibt, nutzt XSA-523 als Anlass für einen Migrationsplan. Für 4.6 bis 4.16 kommt kein Patch mehr.
- Geht davon aus, dass Discovery jetzt in Maschinengeschwindigkeit läuft. Drückt die Zeit zwischen «Advisory veröffentlicht» und «Host neu gestartet» auf Stunden und schreibt das Runbook, bevor ihr es braucht.
Die Mauer hält, wenn ihr sie neu baut
Die Hypervisor-Mauer ist weiterhin die beste, die wir haben. Sie hielt ein Jahrzehnt gegen menschliche Forscher, und sie hielt, weil die Prüfungen fast richtig waren. «Fast» ist heute alles, was ein KI-Auditor braucht, um euch zu finden.
Die Tür in Xen ist gepatcht. Ob die Tür in eurer Umgebung geschlossen ist, hängt an einer langweiligen Frage: Wisst ihr heute, auf welcher Hypervisor-Version eure Produktionslast läuft?
Wenn die ehrliche Antwort lautet «da müsste ich fragen», ist das der Fund, der vor dem nächsten Advisory zählt.