Claude findet zwei kritische Xen-Lücken: Böse VMs konnten den ganzen Server übernehmen

Worum es geht

Das Xen-Projekt hat am Dienstag, 3. November 2026, um 12:00 UTC das Sicherheits-Advisory XSA-523 in Version 2 veröffentlicht. Xen ist einer der ältesten Open-Source-Hypervisoren. Ein Hypervisor ist die Software, die auf einem physischen Server viele virtuelle Maschinen (VMs) gleichzeitig laufen lässt und sie voneinander abschottet, ähnlich wie Wohnungen in einem Mehrfamilienhaus. Das Advisory beschreibt zwei kritische Lücken mit den Kennungen CVE-2026-102703 und CVE-2026-102704. Über sie kann eine bösartige VM (in der Xen-Sprache ein „Guest“) diese Abschottung durchbrechen und auf den Speicher anderer VMs auf demselben Server zugreifen.

Im Advisory heißt es, die Lücken wurden „von Anthropic mit Claude entdeckt“. Stephan Lipp von Ada Logics, einer Firma für Sicherheitsaudits von Open-Source-Software, hat sie bestätigt. Darüber berichtet unter anderem das indonesische Portal Industry.co.id.

Was technisch schiefläuft

In Xen heißen die einzelnen VMs „Domains“. Damit sie kontrolliert Daten austauschen können, gibt es den Mechanismus Grant Copy. Eine Domain erteilt dabei eine Art Erlaubnisschein, die Grant Reference, und Xen kopiert die Daten zwischen den Domains. Für mehr Tempo speichert Xen bereits geprüfte Angaben zwischen (Cache), wenn mehrere Kopiervorgänge nacheinander dieselbe Speicherseite betreffen. Dann muss nicht jedes Mal neu geprüft werden.

Genau hier liegt der Fehler: Die Bedingungen, wann diese zwischengespeicherten Angaben neu geprüft werden müssen, sind in manchen Fällen falsch. Daraus ergeben sich zwei Lücken:

Eine Frame-Nummer bezeichnet dabei einen konkreten Block im physischen Arbeitsspeicher. Werden Frame-Nummer und Erlaubnisschein verwechselt, kann eine VM Speicher ansprechen, der ihr gar nicht gehört.

Warum Dom0 der Ernstfall ist

Dom0 ist auf einem Xen-Server die privilegierte Domain. Sie verwaltet alle anderen VMs, steuert die Hardware und ist damit sozusagen der Hausmeister mit dem Generalschlüssel. Wer in den Speicher von Dom0 schreiben kann, kann laut dem Bericht in der Praxis den ganzen Host übernehmen, samt aller VMs darauf. Weil die Lücken schon mit Version 4.6 eingeführt wurden, steckten sie offenbar viele Jahre im Code, ohne dass jemand sie bemerkte.

Wer betroffen ist und was Admins tun sollten

Am größten ist das Risiko bei Anbietern, die VMs verschiedener Kunden auf denselben Xen-Servern betreiben, etwa VPS- und Cloud-Anbieter. Dort könnte ein bösartiger Kunde theoretisch Daten anderer Kunden auslesen oder verändern. Auch Produkte, die auf Xen aufbauen, wie XCP-ng, XenServer und das sicherheitsorientierte Betriebssystem Qubes OS, sollten Administratoren im Blick behalten und die Updates der jeweiligen Hersteller verfolgen.

Die praktischen Schritte laut Bericht:

• Prüfen, welche Xen-Version läuft. Bei 4.6 oder neuer ist der Server verwundbar.
• Den passenden XSA-523-Patch für den eigenen Versionszweig einspielen oder vorher auf den neuesten Stand des stabilen Zweigs aktualisieren.
• Sicherheitsmeldungen von XCP-ng, XenServer und Linux-Distributionen auf gepatchte Pakete verfolgen.
• Wer einen VPS mietet, sollte beim Anbieter nachfragen, ob dessen Hosts auf Xen laufen und schon gepatcht sind.

Einen vorübergehenden Workaround gibt es laut Advisory nicht.

Zwei Teams, eine Lücke

Neben Anthropic hat auch das Team CodeAnt AI Security Research dieselben Lücken unabhängig gemeldet. Dass zwei Gruppen denselben Fehler finden, ist kein Zufall: Laut Bericht setzen inzwischen viele Teams KI-Werkzeuge für die Fehlersuche ein, Verteidiger genauso wie möglicherweise Angreifer. Welches Claude-Modell Anthropic genau verwendet hat und wie viel menschliche Arbeit in den Fund geflossen ist, geht aus dem Bericht nicht hervor.

Einordnung

Der Fall reiht sich in eine wachsende Liste schwerer Lücken in wichtiger Software ein, die mit Hilfe von KI gefunden wurden. Bemerkenswert ist hier zweierlei. Erstens geht es nicht um ein Randprojekt, sondern um einen ausgereiften, jahrzehntelang geprüften Hypervisor, der in vielen Rechenzentren läuft. Zweitens betrifft der Fehler die wichtigste Sicherheitsgrenze, die ein Hypervisor überhaupt hat: die Trennung zwischen den VMs verschiedener Kunden.

Für Verteidiger ist das eine gute Nachricht, denn die Lücke wurde gemeldet und geschlossen, statt ausgenutzt zu werden. Die Kehrseite: Wenn KI solche Fehler zuverlässig findet, steht dieses Werkzeug auch Angreifern offen. Dass zwei Teams die Lücke unabhängig voneinander entdeckt haben, zeigt, wie schnell sich das Zeitfenster schließt, in dem nur die Verteidiger von einem Fund wissen. Für Betreiber von Xen-Servern ist die Lage eindeutig: Es gibt keine Gegenmaßnahme, also sofort patchen.