Eine Lücke im Linux-Kern ließ Programme aus virtuellen Maschinen ausbrechen, ein Hoster startete alle Server neu und nannte es Wartung. Was berichtet wird, was offen bleibt und was Betriebe bei Hoster, Zugangsdaten und Ausfallplan prüfen können.
Am 15. Oktober 2026 wurde eine Lücke im Linux-Kern bekannt, die unter der Nummer CVE-2026-99999 geführt wird. Sie betrifft das Netzwerk des Betriebssystems und ließ ein Programm in einer virtuellen Maschine auf den Rechner zugreifen, auf dem sie läuft. Der Hoster Fly.io startete am Tag darauf alle seine Server neu. Wir haben die Beschreibung der Entdecker (pwn.ai) und den Bericht von Fly.io im Original gelesen, den Eintrag im Kernel-Verzeichnis selbst nicht. Zur Transparenz: Die Entdecker nutzten ein KI-Modell von OpenAI zur Suche, wir erzeugen Bilder mit OpenAI-Modellen, und wir arbeiten in der Redaktion mit Claude von Anthropic. Wir haben also ein eigenes Interesse am Thema.
Die Lücke: Laut pwn.ai kann ein Programm in einer virtuellen Maschine über falsche Angaben zur Prüfsumme eines Netzwerkpakets erreichen, dass der Rechner darunter nach der Prüfung den Kopf des Pakets verändert. Damit ließen sich im Versuch 32 Byte Arbeitsspeicher des Rechners auslesen. In einer eigenen Testumgebung zeigten die Entdecker außerdem einen vollständigen Ausbruch auf den Rechner, nicht in der Produktion eines Anbieters. Sie stufen die Lücke als kritisch ein. Die Korrektur wurde laut pwn.ai am 8. Oktober in den Entwicklungszweig und am 14. Oktober in den Hauptzweig des Linux-Kerns übernommen. Gefunden wurde sie während eines Wettbewerbs von Vercel mit einer Million Dollar Preisgeld. Die Entdecker schreiben, ein KI-Modell von OpenAI habe die Quelltext-Analyse getragen, Menschen hätten geführt, die Kosten lägen unter 700 Dollar für Rechenzeit. Das sind Herstellerangaben.
Der Hoster: Fly.io schreibt, am 16. Oktober habe man die gesamte Flotte aktualisiert und neu gestartet, in zehn Stunden. Jeder Rechner brauchte 15 bis 20 Minuten, in dieser Zeit lief darauf nichts. Programme mit nur einer Instanz waren zwangsläufig kurz offline. Einige Rechner kamen nicht wie geplant zurück und liefen erst am 20. Oktober wieder. Daten seien keine verloren gegangen. Zur Frage, ob etwas abgeflossen ist, schreibt Fly.io, es sei unwahrscheinlich und man habe keinen Hinweis darauf. Wer zwischen dem 15. und 17. Oktober Zugangsdaten über unverschlüsselte Verbindungen geschickt hat, solle sie ändern. Die Meldung auf der Statusseite sprach von „Wartung“ und nannte keinen Grund. Kunden beschwerten sich, Fly.io begründet das damit, nicht bestätigen zu wollen, dass die Rechner gerade verwundbar waren, und hat den Ablauf für Meldungen danach geändert.
Die Lücke betrifft vor allem Anbieter, die fremde Programme auf gemeinsamer Hardware ausführen. Ob und wie stark andere Hoster betroffen waren, wissen wir nicht. Beide Berichte sind von den Beteiligten selbst, wir konnten nichts unabhängig prüfen. Die Entdecker erwarten Angriffe auf schwächer eingerichtete Systeme „in Wochen“, das ist ihre Einschätzung.
Ab hier gilt: Das ist unsere Einschätzung, keine Studie und keine Sicherheitsberatung. Viele Betriebe betreiben eine Website, einen Shop oder Software bei einem Hoster oder in der Cloud, oft ohne zu wissen wo. Erstens: Frage deinen Anbieter schriftlich, wie schnell er Sicherheitsupdates einspielt und wie er dich darüber informiert. Der Fall zeigt, dass eine Meldung „Wartung“ ein Sicherheitsgrund sein kann. Vereinbare, dass du bei Neustarts und Ausfällen im Voraus oder zeitnah erfährst, was los ist. Zweitens: Weißt du, wo deine Zugangsdaten stehen, und kannst du sie in Minuten ändern? Dazu zählen Passwörter, Schlüssel für Schnittstellen und die Zugänge deiner KI-Werkzeuge. Schicke keine Zugangsdaten über unverschlüsselte Verbindungen, die Adresse muss mit https beginnen.
Drittens: Plane den kurzen Ausfall ein. Fly.io schreibt, Programme mit nur einer Instanz seien offline gegangen. Überlege, was passiert, wenn dein Shop oder deine Kasse eine halbe Stunde nicht erreichbar ist: Wer entscheidet, wer wird informiert, was machst du ohne das System. Wer KI-Agenten mit Zugängen arbeiten lässt, gibt ihnen nur Rechte, die für die Aufgabe nötig sind und bald ablaufen, das empfiehlt auch Fly.io. Warum ein Update zählt, steht in unserem Beitrag zu den 948 Linux-Lücken, und was Agenten mit Zugangsdaten riskieren, in unserem Beitrag zur Dreierkombination.
Fly.io hat nach eigenen Angaben keinen Hinweis auf einen Abfluss, und die meisten Betriebe haben mit der Hardware darunter nichts zu tun. Die Frage ist, ob dein Anbieter bei so etwas schnell handelt und ehrlich informiert. Das erfährst du nur, wenn du vorher fragst.
Vier Minuten: Schreibe auf, bei welchem Hoster oder Dienst deine Website, dein Shop und deine wichtigsten Programme laufen. Drei Minuten: Schicke jedem eine kurze Frage, wie schnell Sicherheitsupdates kommen und wie du informiert wirst. Drei Minuten: Lege eine Liste an, wo deine wichtigsten Zugangsdaten stehen und wer sie ändern kann.
Ein Hoster startet zehn Stunden lang neu und nennt es Wartung. Du erfährst das Wichtige nur, wenn du vorher gefragt hast.
Anbieter fragen, Zugangsdaten kennen, Ausfall einplanen. Das ist unsere Einschätzung, keine Studie.
Quellen: Fly.io, „Well, That Wasn’t Fun: October 16 ’26“ (abgerufen am 9. November 2026); pwn.ai, „PwnEscape: Guest-to-Host KVM Escape (CVE-2026-99999)“ (abgerufen am 9. November 2026); TLDR DevOps, Ausgabe vom 9. November 2026. Den Eintrag im Kernel-Verzeichnis haben wir nicht gelesen. Die Einordnung für Betriebe ist unsere Einschätzung, keine Sicherheitsberatung.
Welches Modell für welche Aufgabe, welche Tools wirklich zählen und wie du richtig promptest. Komplett lesbar, kein Download.
Jetzt gratis lesenWir gehen mit dir durch, welche Dienste und KI-Werkzeuge in deinem Betrieb laufen, bei wem, und bauen eine einfache Liste mit Zuständigkeit, Zugängen und Ausfallplan.