Da war das Internet mal kurz weg. Und so 100%ig wieder da ist es immer noch nicht.
Aber während die Fachpresse völlig selbstverständlich von "heap overflow", "memory-corruption vulnerability", "use after free" und "remote code execution" spricht, und die übrige Presse nur von gefährlicher Sicherheitslücke redet, haben wir nirgendwo eine Erklärung gefunden, die man "nicht-nerdigen" Kunden geben kann.
Also versuchen wir uns selbst daran: Was war eigentlich das Problem? Eine Erklärung nahezu ohne Computer.
Stellen Sie sich vor, Sie betreiben ein Hotel. Vielleicht haben Sie sich alles selbst überlegt und geplant, vielleicht haben Sie dabei auf fertige Konzept-Module von einem Berater (sog. Framework) zurückgegriffen. Vielleicht setzen Sie aber auch auf eine bewährte Hotel-Marke und betreiben ein günstiges Ketten-Hotel der Marke Joomla, Wordpress oder etwas gehobenere Kategorie der Marke TYPO3. Völlig egal.
Eines haben fast alle Marken und Hotels gemeinsam: Rund 75% aller Häuser weltweit beziehen ihr Personal vom Marktführer, von der renommierten Privatschule für Hotel-Personal, kurz PHP. Und auch an Ihrer Rezeption arbeiten verschiedene Team-Mitglieder, in der PHP-Sprache "Worker" genannt.
Und diese Worker machen ihren Job zuverlässig und gut. Und doch wurden Generationen von Workern beim Handling von Spezialfällen nicht richtig geschult.
CVE-2026-109618: "RCE via Out-of-Memory-Corruption"
Unser Worker, er heißt Waldemar, arbeitet an der Rezeption, als Bruno Betrüger reinkommt. Hätte Bruno direkt nach vier freien Zimmern gefragt, hätte Waldemar abgelehnt, so viele sind nicht frei.
Aber Bruno beginnt das Gespräch mit einer Autopanne, weshalb er eine Unterkunft bräuchte. Waldemar holt ein Meldeformular, legt es auf seinen Tresen, trennt den unteren Abschnitt (zur Reservierung des Zimmers) ab und legt ihn hinter sich im Schlüsselregal in das Fach für Zimmer 11. Dann trägt er ein: "Vorname Bruno, Nachname Betrüger" und fragt: "Reisen Sie alleine?"
Bruno hat seine Frau Franziska dabei, aber die beiden haben getrennte Schlafzimmer, sie braucht ein eigenes Zimmer. "Multipart MIME" nennt sich die Technik, mit der bei einer Anfrage mehrere unabhängige Teile übermittelt werden können. Waldemar holt ein zweites Anmeldeformular, legt das daneben, trennt den unten Abschnitt ab, legt den in Schlüsselfach 12 und trägt ein "Nachname Betrüger, Vorname Franziska".
Einen Sohn Siegfried habe er auch noch, fällt Bruno ein. Der soll Privatsphäre haben. Waldemar holt ein drittes Formular, trennt einen Abschnitt ab, reserviert Zimmer 13 damit und trägt Siegfried Betrüger ins Formular ein.
Ach ja, und Tante Elsa noch. Waldemar nimmt das nächste Formular, trennt den Abschnitt ab, dreht sich um ... und sieht, dass Zimmer 14 gar nicht frei ist, da liegt schon eine Reservierung von ganz jemand anderem. Gekonnt zerknüllt er seinen Abschnitt, wirft ihn in den Papierkorb, dreht sich wieder zu Bruno und sagt "Es tut mir leid, so viele Zimmer haben wir nicht, wir sind "out of memory", probieren Sie es bitte wann- oder woanders". Bruno geht, und Waldemar nimmt die vier angefangenen Meldeformulare, plus die vier Reservierungsabschnitte aus den Zimmern 11 bis 14 und wirft alles weg. Dann kümmert er sich um das klingelnde Telefon, und die nächsten Gäste stehen auch schon in der Schlange.
Haben Sie aufgepasst? Weil er sich beim Aufräumen an seinen vier Meldeformularen orientiert hat, hat er auch vier Zimmer wieder freigegeben - auch das Zimmer 14, was er gar nicht reservieren konnte, weil das eigentlich für einen anderen Gast reserviert war. Und damit haben wir eine out-of-memory-corruption, durch das Provozieren dieser zu großen Anfrage hat der Angreifer die interne Zettelwirtschaft Ihres Hotels korrumpiert.
Ist das schlimm? Im einfachsten Fall ist das Hotel irgendwann ausgebucht, dann steht der Gast aus Zimmer 14 da, möchte einchecken, aber sein Zimmer ist zwischenzeitig vergeben worden. Das gefällt dem Gast gar nicht und der bleibt jetzt so lange an der Rezeption stehen und reagiert nicht, bis er einchecken kann. Im Computerleben wäre die Software dann abgestürzt und braucht einen Neustart.
Die Geschichte könnte aber auch so weitergehen: Brunos Gangsterbande reserviert telefonisch die Zimmer 11, 12 und 13. Das vermeintlich freie Zimmer 14 ist jetzt als einziges übrig. Eine Komplizin geht ins Hotel und fragt, ob sie sich kurz ein Zimmer angucken kann (sie möchte nächste Woche Kunden dort einquartieren). Also bekommt sie Schlüssel 14, guckt sich kurz das Zimmer an (einschließlich des Gepäcks, das der echte Gast aus Zimmer 14 schon vorab aufs Zimmer hat liefern lassen), deponiert einen Brief, bringt den Schlüssel zurück, bedankt sich und verschwindet.
Wenn dann später ihr gewähltes Opfer eincheckt - der Gast, für den Zimmer 14 vorgesehen ist - wird er auf seinem Zimmer einen Brief vorfinden. Und er wird glauben, dieser wäre vom Hotel (und dem Inhalt vertrauen), obwohl unsere Betrügerbande ihn dort deponiert hat.
"Remote code execution" (RCE) nennt man das Ganze, wenn man Code (einen Brief) irgendwo einschleust, den jemand anderes gutgläubig ausführt.
CVE-2026-109619: "RCE via Stale Global State"
Das zweite Szenario ist viel schneller klärt, aber nicht weniger gefährlich:
Bruno Betrüger ruft im Hotel an, Worker Waldemar hebt ab. Bruno habe eine Autopanne und lasse sich gleich in die Stadt schleppen und brauche ein Hotel, wie er denn an den Schlüssel käme, wenn die Rezeption nicht mehr besetzt ist? Kein Problem, Ihr Hotel hat ja einen Schlüsselsafe.
Bruno reserviert also telefonisch das Zimmer, oh der Akku ist gleich alle, am besten schreibt er sich schon mal den Code für den Schlüsselsafe auf. Und dann diktiert er langsam seine Daten für die Reservierung ... ach nein, der ADAC-Mann signalisiert ihm, er bekäme das Auto wieder flott. Vielen vielen Dank trotzdem.
Waldemar legt auf, wirft seinen Meldezettel weg (dieses Mal auch ohne Fehler beim Reservierungs-Abschnitt), vergisst das Telefonat. Und irgendwann abends bestückt er den Schlüsselsafe mit den Schlüsseln für die spät-anreisenden Gäste.
"Use after free" nennt sich das in der Fachsprache. Waldemar hat im Schlüsselsafe auch das erste Fach bestückt (mit dem Schlüssel für Familie Friedlich), was ja frei war. Aber er hat nicht bedacht, dass Bruno Betrüger noch Zugriff auf diesen Ablageort hat.
Und Bruno? Der kann jetzt entweder eine der beiden Schlüsselkarten aus dem Safe holen (die andere lässt er drin) und hat Zugang zu dem Zimmer, während die Fröhlichs schlafen. Oder er kann auch hier wieder einen Brief hineinlegen (remote code execution).
"Hammer immer esu jemaat."
(Zusatzartikel zum Rheinischen Grundgesetz. Übersetzt: "Das haben wir doch immer schon so gemacht.")
Worker Waldemar kann es nicht anders wissen, so wird es seit Jahrzehnten an der fiktiven PHP-Schule gelernt. Dabei sind die Probleme schon längere Zeit bekannt. Aber das gesamte PHP-Projekt (wie viele OpenSource-Projekte) lebt von Spenden und von der ehrenamtlichen Arbeit einiger Nerds, und so muss priorisiert werden.
Damit eine Schwachstelle aufwendig beseitigt wird, muss sie nicht nur existieren. Sie muss auch wirklich ausgenutzt werden können. Und der Beweis wurde in den letzten Jahren von niemandem erbracht. Bis jetzt. Die Geschwindigkeit, in der KI beim Analysieren (und damit auch beim Finden eines Weges, diese Schwachstelle auszunutzen) hilft, ist beeindruckend und beängstigend zugleich.
Darum musste auch sehr schnell gehandelt werden: Natürlich war es ein immenser Aufwand, unzählige PHP-Worker auf der ganzen Welt zur Nachschulung zu schicken (und in der Zeit die Hotels teilweise stillzulegen). Aber bereits die wenigen Details, die im Vorfeld über die Lücke bekannt waren, haben ausgereicht, damit Bruno Betrüger und seine Komplizen mit Hilfe von KI das fehlende Wissen über die Lücke rekonstruieren konnten. Berichten zufolge gab es Angriffsversuche schon, bevor die Updates (und damit das genaue Wissen, wo es hakt) veröffentlicht waren.