Zum Hauptinhalt springen
S-EDV news
← Alle News
Sicherheit & Datenschutz 04.11.2026 · 4 min Lesezeit

Xen-Lücke XSA-523: Bösartige VM liest und schreibt Speicher von Host und Gästen

Das Xen-Projekt hat am 3. November 2026 mit XSA-523 zwei Lücken veröffentlicht, über die eine bösartige VM beliebigen Speicher anderer Domänen einschließlich Dom0 lesen und schreiben kann. Betroffen sind alle Versionen ab Xen 4.6. XCP-ng 8.3 hat ein Update veröffentlicht, Qubes OS 4.3 verteilt den Fix zunächst über security-testing.

Mit KI erstellt – redaktionelle Prüfung ausstehend

Symbolbild: gestapelte Glaswürfel, von denen einer zerspringt, neben der Überschrift Xen-Lücke VM bricht aus

Das Xen-Projekt hat am 3. November 2026 das Advisory XSA-523 veröffentlicht. Zwei Fehler in der Grant-Copy-Funktion des Hypervisors (CVE-2026-102703 und CVE-2026-102704) erlauben einer bösartigen VM, beliebigen Speicher anderer Domänen zu lesen und zu schreiben, auch den von Dom0. Betroffen sind alle Xen-Versionen ab 4.6, eine Abschwächung ohne Patch gibt es laut Xen-Projekt nicht.

Relevant ist das für alle, die Xen-basierte Hosts betreiben, etwa XCP-ng, Qubes OS oder eigene Xen-Installationen unter Linux, besonders wenn dort VMs fremder oder weniger vertrauenswürdiger Nutzer laufen. Proxmox VE und andere KVM-basierte Plattformen nutzen kein Xen und kommen in den Advisories nicht vor. XCP-ng 8.3 hat ein Update veröffentlicht, Qubes OS 4.3 verteilt den Fix zunächst über das Repository security-testing. Beide verlangen einen Neustart. Wer Gäste mit unterschiedlichen Vertrauensstufen auf einem Host hat, sollte den Neustart nicht bis zum regulären Wartungsfenster aufschieben.

Was ist passiert?

Grant Copy ist der Mechanismus, mit dem Xen Daten zwischen VMs kopiert. Laut XSA-523 speichert Xen bei vielen Kopiervorgängen auf benachbarte Adressen derselben Speicherseite bereits geprüfte Angaben zwischen, um Zeit zu sparen. Die Bedingungen, wann diese Angaben neu geprüft werden müssen, waren in einigen Fällen falsch. Bei CVE-2026-102703 konnten Frame-Nummern und Grant-Referenzen verwechselt werden. Bei CVE-2026-102704 saß die Prüfung, die das Kopieren per Frame-Nummer auf den eigenen Speicher der aufrufenden Domäne beschränken soll, an der falschen Stelle.

Entdeckt hat die Fehler laut Advisory Anthropic mit dem KI-Modell Claude, bestätigt wurden sie von Stephan Lipp von Ada Logics. Unabhängig davon meldete das CodeAnt AI Security Research Team dieselbe Lücke.

Wer ist betroffen?

Verwundbar ist jede Xen-Version ab 4.6, Version 4.5 und älter nicht. Das Xen-Projekt liefert Patches für xen-unstable bis 4.19.x sowie für 4.18.x und 4.17.x. Für die Zweige 4.6 bis 4.16 enthält das Advisory keine Patches.

XCP-ng 8.3 hat am 3. November das Paket xen-4.17.7-4.2.xcpng8.3 veröffentlicht, Vates stuft die Lücke in VSA-2026-055 als kritisch ein, XCP-ng rät im Blog zum sofortigen Update. Qubes OS ist laut Bulletin QSB-121 in allen unterstützten Versionen und Konfigurationen betroffen. Der Fix kommt als Xen 4.19.6-3 in Dom0 von Qubes 4.3, zunächst über das Repository security-testing und in den folgenden zwei Wochen nach Tests im stabilen Zweig. Der Debian-Security-Tracker führte das Paket xen beim Abruf am 4. November für Debian 12, 13 und Testing noch als verwundbar, nur Unstable als behoben.

Wie kritisch ist das?

Es handelt sich um einen Ausbruch aus der VM: Laut XCP-ng kann ein einziger kompromittierter Gast seine Isolation verlassen und den gesamten Host übernehmen. Einen CVSS-Wert nennt das Xen-Projekt nicht, Vates gibt noch keinen an. Welche Rechte ein Angreifer innerhalb der VM braucht, beschreibt das Advisory nicht. Angriffe in freier Wildbahn erwähnt keine der Quellen.

Was sollten Admins jetzt tun?

  • Inventar: alle Hosts mit Xen erfassen, auch Testsysteme und Qubes-Arbeitsplätze, und den Patchstand über die installierte Paketversion prüfen (XCP-ng: xen-4.17.7-4.2.xcpng8.3 oder neuer, Qubes 4.3: Xen 4.19.6-3 oder neuer). Die Xen-Hauptversion allein zeigt den Patchstand nicht.
  • XCP-ng 8.3: Updates einspielen und die Hosts neu starten. XCP-ng hat am 4. November ein weiteres Update für eine Lücke im Linux-Kernel von Dom0 nachgeschoben, das ebenfalls einen Neustart braucht. Bis zum Wartungsfenster schützt laut XCP-ng dort eine iptables-Abschwächung.
  • Qubes OS 4.3: normal weiter aktualisieren, nach dem Xen-Update Dom0 neu starten. Wer Anti Evil Maid nutzt, muss die Passphrase für die neuen PCR-Werte 18 und 19 neu versiegeln.
  • Eigene Xen-Builds: Patches aus XSA-523 einspielen. Systeme mit Xen 4.16 und älter auf einen unterstützten Zweig bringen, für diese Zweige enthält XSA-523 keine Patches.
  • Debian-Hosts mit Xen: Security-Tracker beobachten, bis ein Paket für die stabile Version erscheint.
  • Vor dem Neustart: Sicherungen der VMs prüfen und Gäste mit fremden Nutzern vorrangig behandeln.

Einordnung für Unternehmen

Für kleine Firmen, die nur eigene VMs auf einem Xen-Host betreiben, ist eine kompromittierte VM die Voraussetzung. Das ist eine Hürde, aber keine hohe, denn jede bereits übernommene VM wird so zum Sprungbrett auf den Host und alle anderen Gäste. Hoster und Dienstleister mit Kunden-VMs sollten das Update mit Vorrang behandeln. Auffällig ist, dass KI-gestützte Fehlersuche hier eine schwere Hypervisor-Lücke zutage gefördert hat. Mit weiteren solchen Funden ist zu rechnen.

Passende Anleitungen auf S-EDV

Quellen

XenXSA-523CVE-2026-102703CVE-2026-102704XCP-ngQubes OSVirtualisierung