Root im Gast. Griff in Firecracker.
Root innerhalb einer microVM soll dort bleiben. CVE-2026-122192 kann diese Grenze unter bestimmten Bedingungen aufweichen. Entscheidend sind Version, Snapshot-Wiederherstellung und Speicher-Backend.
Die Grenze liegt außerhalb des Gasts
Eine Sandbox ist gerade dann wichtig, wenn der Code darin nicht vertrauenswürdig ist. Root im Gast darf deshalb nicht automatisch Zugriff auf den Prozess bekommen, der die virtuelle Maschine auf dem Host betreibt. Für die eigene Architekturprüfung würde ich diese Grenze ausdrücklich benennen.
AWS beschreibt für CVE-2026-122192 einen möglichen Lese- und Schreibzugriff aus dem Gast auf den Speicher des Firecracker-Prozesses. Voraussetzung sind Root-Rechte im Gast und bestimmte Host-Speicherbedingungen. Daraus folgt keine allgemeine Aussage, jede Firecracker-Instanz lasse sich aus dem Netzwerk übernehmen.
Nicht jede Firecracker-VM ist betroffen
Laut Projekt-Advisory betrifft die Lücke Versionen von 0.23.0 bis einschließlich 1.16.1, wenn eine VM aus einem Snapshot mit File-Memory-Backend wiederhergestellt wird und ein Balloon- oder virtio-mem-Gerät hat. Ohne Snapshot gestartete VMs sowie Wiederherstellungen mit Uffd-Backend sind laut Advisory nicht betroffen.
Ich würde deshalb vier Angaben zusammen erfassen: tatsächlich laufende Version, Start- beziehungsweise Restore-Pfad, Speicher-Backend und Gerätekonfiguration. Eine Versionssuche allein beantwortet die Betroffenheit nicht vollständig. Auch die im Betrieb selten verwendeten Wiederherstellungspfade gehören in diese Aufnahme.
Ein fehlgeschlagener Speicherwechsel wird zur Isolationsfrage
Coinspect erklärt den Fehler auf hoher Ebene so: Nach einem fehlgeschlagenen Austausch kann eine Zuordnung von Gast-Speicher fehlen, während KVM den zugehörigen Bereich weiter als Gast-RAM behandelt. Wird die Adresse für Firecracker-Daten wiederverwendet, kann der Gast diese erreichen.
Die Forschung beschreibt zusätzlich eine unabhängige zweite Stufe rund um die seccomp-Regeln. Diese ist von CVE-2026-122192 zu unterscheiden. Coinspect hat die genannten Cloud-Dienst-Deployments ausdrücklich nicht geprüft; die Nutzung von Firecracker allein belegt deren Betroffenheit nicht.
Fix und Workaround konkret zuordnen
AWS nennt 1.16.2 und 1.17.0 als korrigierte Versionen; Betreiber von Forks sollen die entsprechenden Änderungen übernehmen. Ist ein Upgrade nicht sofort möglich, empfiehlt AWS die Snapshot-Wiederherstellung über das Uffd-Backend unter Beachtung seiner Anforderungen. Die zusätzlich genannten Host-Einstellungen decken nicht jeden möglichen Fehler beim Ersetzen der Speicherzuordnung ab.
Das Projekt beendet nach dem Fix bei einem gescheiterten Ersatz-Mapping den Prozess samt VM, statt mit einer ungültigen Zuordnung fortzufahren. Das ist für mich ein wichtiger Prüfpunkt: Wie reagiert eine Isolationskomponente auf einen Fehler, der ihre eigenen Annahmen verletzt?
Anbieterbetrieb und Eigenbetrieb getrennt bewerten
AWS erklärt ausdrücklich, dass seine Dienste einschließlich Lambda von diesem Problem nicht betroffen sind und Kunden nichts unternehmen müssen. Für selbst betriebene Firecracker-Umgebungen gelten die beschriebenen Versions- und Konfigurationsprüfungen.
Ich würde den Vorgang mit einem überprüften Laufzeitstand und einer dokumentierten Zuordnung der Restore-Pfade abschließen. Ein korrigiertes Binary auf einem Ablageserver ist noch kein Nachweis dafür, welche Fassung die laufenden Workloads isoliert. Gerade bei ausführbarem Agentencode sollte diese Antwort belastbar sein.