Die Wand zwischen den Mietern hatte einen Riss

Das stille Versprechen jedes Cloud-Servers und jedes virtuellen privaten Servers ist Trennung. Ihre Maschine und die Maschine des Fremden, der denselben Anbieter bezahlt, laufen auf derselben physischen Hardware, und eine in den Linux-Kernel eingebaute Schicht namens KVM hält sie auseinander. Januscape, geführt als CVE-2026-53359, ist ein Riss in dieser Wand. Es ist eine Race Condition in der Art, wie KVM Shadow Page Tables verwaltet, die interne Karte, die den Speicher einer Gastmaschine auf echten Speicher übersetzt. Durch den Fehler kann der Host einen dieser Karteneinträge dem falschen Gast-Frame zuordnen, eine Frame-Nummer- und Typverwechslung, die, sorgfältig gesteuert, eine feindliche virtuelle Maschine den Host in das Abbilden von angreiferbestimmtem Speicher treiben lässt. Das ist eine Gast-zu-Host-Flucht: Der Mieter klettert aus seiner Kiste auf den Boden, den alle teilen.

Ernst macht es die Reichweite. Der Fehler sitzt in Code, der Intel- und AMD-Prozessoren gemein ist, er greift also bei VMX und EPT auf der einen und SVM und NPT auf der anderen Seite. Er wurde 2010 eingeführt und lag sechzehn Jahre still, das heißt nahezu jeder in diesem Zeitraum ausgelieferte Linux-Kernel trägt ihn. Er wurde am 6. Juli auf der öffentlichen oss-security-Liste offengelegt, am 16. Juni im Upstream behoben, und die korrigierten stabilen Kernel, die Versionen 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 und 5.10.260, kamen erst am 4. Juli.

Warum es ist gepatcht nun zwei Antworten hat

Die ungewöhnliche Gefahr liegt hier nicht im Fehler, sondern in der Gestalt der Korrektur. Januscape zu schließen braucht zwei gekoppelte Upstream-Commits, nicht einen: den Ausbruch-Fix mit CVE-2026-53359 und eine begleitende Frame-Nummer-Korrektur mit CVE-2026-46113. Spielt man nur den ersten ein, den mit dem einprägsamen Namen, bleibt die Tür angelehnt. Ein Administrator, der die Schlagzeilen-Meldung las, diesen einen Patch aufspielte und das Ticket schloss, hat das Vernünftige getan und ist trotzdem verwundbar. Genau darum klärt der routiniert klingende Satz, wir haben gepatcht, die Sache bei dieser Lücke nicht mehr.

Für einen Eigentümer ist die Angriffsfläche selten das eigene Server-Rack. Es ist der Anbieter unter Ihren Zulieferern: der VPS-Host, der Ihre Website betreibt, die Private Cloud, die Ihre Fachsoftware betreibt, die verwaltete Plattform, die Ihre Daten betreibt. In Deutschland setzt das NIS2-Umsetzungsgesetz genau diese Erwartung, und das BSI ist die Stelle, an die gemeldet wird: Sie bleiben für die Sicherheit der in Ihrem Namen erbrachten Dienste verantwortlich. Eine Hypervisor-Flucht ist genau die Art geteiltes Infrastrukturversagen, für die diese Regeln geschrieben wurden, denn ein ungepatchter Host kann die Trennung zunichtemachen, für die tausend Kunden bezahlt haben.

Die Frage an Ihren Hosting-Anbieter in dieser Woche

Für die meisten Eigentümer ist das keine Kernel-Compile-Aufgabe, sondern eine schlicht gestellte Beschaffungsfrage. Legen Sie demjenigen, der Ihre virtuellen Maschinen betreibt, ob VPS-Host, internes Private-Cloud-Team oder verwalteter Plattformanbieter, drei Dinge vor: Läuft der Host-Kernel jetzt auf einer korrigierten stabilen Version oder einem Live-Patch; enthält diese Korrektur beide Commits, den Ausbruch-Fix und seinen Begleiter; und wann kam sie. Es gibt keinen Konfigurationsschalter, der das sicher macht. Ein gepatchter Kernel mit Neustart oder ein ohne Neustart eingespielter Live-Patch ist die einzige vollständige Antwort, und bis sie steht, sollte jeder Mehr-Mieter-Host als von einem feindlichen Nachbarn erreichbar gelten.

Die praktische Verschiebung ist klein, aber echt. Der Mieter neben Ihnen, ein Name, den Sie nie erfahren, wurde diesen Monat von einer abstrakten Sorge zu einer Zeile in Ihrem Bedrohungsmodell. Die Eigentümer, die daraus eine konkrete schriftliche Antwort ihres Anbieters machen statt einer bequemen Annahme, sind die, die nicht raten müssen, falls diese Lücke je zu einem echten Einbruch verkettet wird.