Vierzehnhundert Stunden, und die Seiten waren schon dunkel
Der Termin war präzise — so kündigen sich Notfälle gewöhnlich nicht an. Am Mittwoch, dem 21. Oktober 2026, um 14:00 UTC, würde PHP ein Sicherheitsupdate für zwei kritische Schwachstellen veröffentlichen. Die Stunde stand auf der eigenen Announce-Liste der Sprache, wurde von Forschern aufgegriffen, in einem Beitrag von Dane Knecht vermerkt und von Medien wiederholt, die Administratoren zum Durchhalten aufforderten. Huntress beschrieb in einer Schnellreaktion durchgesickerte kritische Lücken und gab ihnen Nummern: CVE-2026-109618 und CVE-2026-109619. PC Gamer, ein unwahrscheinliches Blatt für eine Laufzeitkrise, sagte Webadministratoren, sie sollten sich festhalten und mit Notfall-Updates rechnen, die geleakte Exploits schließen würden.
Als diese Stunde kam, hatte ein Teil des Webs die Dunkelheit bereits gewählt. Mehrere große Websites waren wegen einer kritischen Schwachstelle in PHP vom Netz genommen worden. Die BBC berichtete von weltweit heruntergefahrenen Websites, während das Cybersicherheitsupdate erschien. Das ist nicht ganz dieselbe Behauptung wie der Rat, der sie begleitete, und den Unterschied sollte man festhalten. US-amerikanische, europäische und britische Behörden empfahlen, Websites vorübergehend offline zu nehmen, bis sie repariert werden könnten. Eine Empfehlung ist kein Ausfall. Ein Ausfall war, in der Darstellung der Brussels Times und der BBC, bereits die gemeldete Tatsache des Tages: Seiten offline aus Sicherheitsangst, Seiten heruntergefahren, während das Update hinausging. Von außen betrachtet war das Bild ein Patch mit Termin — und ein Web, das zu dimmen begann, bevor man sagen konnte, die Pakete seien angekommen.
In Japan hatte das Dimmen Namen. Gigazine berichtete, NicoNico, pixiv und verschiedene andere Websites und Apps seien in die Wartung gegangen, um den Notfall-Patch zu erfüllen. ITmedia verzeichnete Notfallwartung bei CoDMon, Shadowverse: Worlds Beyond, Sakura's rental server, BASE, pictSQUARE, 킴블, X Server und つなぐ. Nichts in diesen Hinweisen ist, auf dem hier vorliegenden Material, ein Geständnis, dass ein Eindringling bereits drin war. Sie lesen sich als Urteil, dass Erreichbarkeit in den Stunden um den Fix herum der riskantere Zustand geworden war. Das Security-Team von PHP hatte Administratoren am Tag zuvor gewarnt, sich auf Notfall-Updates für zwei kritische Schwachstellen vorzubereiten. Das Team gab die Entdeckung zweier schwerer Lücken bekannt, und die Patches waren auf den 21. Oktober angesetzt. Die Maintainer planten sie für Schwachstellen mit Schweregraden von 9,2 von 10.
Als die Pakete erschienen, hatten sie Versionen. PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 beheben zwei kritische Schwachstellen, die unauthentifizierte Remote Code Execution erlauben können. Das National Cyber Security Centre und die BBC fassten das Update in den weitesten verfügbaren Begriffen: ein kritisches Problem, das Angreifern erlauben kann, Befehle auf jedem Webserver auszuführen, auf dem PHP läuft. Die Episode hatte bereits einen Namen, PHP2Shell, und der Name leistete die Arbeit einer Schlagzeile. Watchtowr benutzte ihn. Huntress benutzte ihn. Amazon benutzte ihn für einen Ausnutzungsversuch. Wiz benutzte ihn für einen Forschungsfund im Kern der Sprache.
Die öffentliche Geschichte war eine kontrollierte Veröffentlichung zu einer angekündigten Stunde. Die Telemetrie-Geschichte war ein Versuch, der nicht auf die Ankündigung wartete.
Amazon Threat Intelligence identifizierte einen PHP2Shell-Ausnutzungsversuch in der MadPot-Telemetrie, datiert auf den 17. Oktober 2026, vier Tage vor der öffentlichen Offenlegung dieser beiden CVEs. Zwischen der Announce-Liste und dieser Telemetrie sitzt das Unbehagen der Woche. Die für die Sprache Verantwortlichen hatten eine Uhr gestellt. Die Uhr war nicht die einzige, die lief.
Zwei Wege hindurch, und ein Streit darüber, wie weit
Die Schwachstellen sind, wie sie das eigene News-Archiv von PHP identifizierte, nicht ein Bug, zweimal beschrieben. CVE-2026-109618 ist Remote Code Execution über Out-of-Memory-Korruption. CVE-2026-109619 ist Remote Code Execution über veralteten globalen Zustand. Die bestätigte Auswirkung, in der Darstellung, die das Out-of-Memory-Problem untersuchte, ist unauthentifizierte Remote Code Execution als das Konto des Web-Workers. Dieser letzte Nebensatz leistet stille Arbeit. Es ist keine belegte Behauptung totaler Herrschaft über eine Maschine. Es ist die Behauptung, dass Code läuft, ohne Login, als das Konto, das der Webserver ohnehin für seine Arbeit benutzt. Für sehr viele Seiten ist dieses Konto die Arbeit.
Die Stale-State-Lücke hat eine Form, die sich benennen lässt, ohne zum Verfahren zu werden. PHP enthält verschiedenen globalen Zustand — Fehler-, Session-, Objekt- und Extension-Zustand —, den ein Worker behält, der aber auf Speicher zeigt, der einer Anfrage gehört. Ein Worker überlebt in dieser Anordnung die Anfrage, die ihn gefüllt hat. Der Speicher nicht. Was die Schwachstelle aus dieser Unstimmigkeit macht, ist in den Begriffen des Archivs Remote Code Execution. Die andere Lücke erreicht ein ähnliches Ziel auf dem Weg, der als Out-of-Memory-Korruption benannt ist. Zwei Mechanismen, eine Klasse von Ergebnis, und ein einziges Notfall-Release, gebaut, um beide zu schließen.
Das Risiko, sagte das Archiv, ist am höchsten für mod_php, mit einem demonstrierten Exploit, bei dem eine unauthentifizierte Anfrage den Angriff auslösen kann, bevor irgendein Anwendungscode läuft. Das ist der Satz, den ein Betreiber zweimal liest. Eine Lücke, die auf eine bestimmte Ecke einer Anwendung wartet, lässt sich triagieren. Eine Lücke, erreichbar durch eine unauthentifizierte Anfrage, bevor die Anwendung Gelegenheit hatte, vorsichtig zu sein, ist eine andere Warteschlange. Deshalb sitzt eine Schwere von 9,2 von 10, die Ars Technica als Bewertung der beiden Schwachstellen berichtete, die Maintainer gerade patchen wollten, nicht als Dekoration auf der Seite. Deshalb lautete die Botschaft des Security-Teams: auf Notfall-Updates morgen vorbereiten, nicht ein bequemes Fenster suchen.
Es gibt einen echten Unterschied darin, wie weit die Quellen den Wirkungsradius treiben, und er sollte benannt werden, nicht geglättet.
Auf der einen Seite fassten die BBC und das National Cyber Security Centre das Update als Behebung eines kritischen Problems, das Angreifern erlauben kann, Befehle auf jedem Webserver auszuführen, auf dem PHP läuft. „Jeder“ ist ein großes Wort. Es ist das Wort, das einen Laufzeit-Bug in etwas näher an einen Zivilschutzfall verwandelt. Auf der anderen Seite war das eigene Archiv der Sprache genauer darin, wo die demonstrierte Gefahr saß: am höchsten für mod_php, und in diesem demonstrierten Fall erreichbar, bevor Anwendungscode läuft. Das sind keine höflichen Synonyme. Ein Leser kann beides halten — eine breite behördliche Warnung über Server, auf denen PHP läuft, und eine engere technische Aussage darüber, wo das Risiko nachweislich am höchsten ist — ohne so zu tun, als sagten sie dasselbe. Die bestätigte Auswirkung bleibt unauthentifizierte Remote Code Execution als das Konto des Web-Workers. Wie weit diese Bestätigung reicht, über die Konfiguration hinaus, in der sie demonstriert wurde, ist das Argument, das die Advisories des Tages nicht anhielten, um es zu klären. Sie patchten, und sie sagten den Leuten, sie sollten erwägen, offline zu gehen, während sie das taten.
Die Versionsfrage hat eine ähnlich unfertige Kante. Die Schwachstellen gelten als betroffen für PHP 5, 6, 7 und 8 — gelten, nicht feierlich in jeder Zeile bestätigt, und der Glaube wird getragen von Watchtowr, BleepingComputer, der eigenen Security-Release-Notiz von PHP und Huntress. Die Versionen, die als Behebung der beiden kritischen Lücken genannt werden, sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die hier versammelten Quellen legen keine vollständige Karte dessen vor, was am 21. Oktober für jede ältere Linie verfügbar war, die Forscher für betroffen halten. Was sie vorlegen, ist eine Lücke in den Papieren: ein Glaube an die Reichweite, der durch 5, 6 und 7 zurückreicht, und eine Liste von Fixes, die im Archiv und in der Shipping-Notiz eine Liste von 8.x-Point-Releases ist. Für einen Administrator auf einem aktuellen 8.2, 8.3, 8.4 oder 8.5 war die Anweisung konkret. Für jeden, der noch weiter zurückliegt, ist die öffentliche Akte dieser Episode eine Warnung ohne, in diesen Quellen, eine passende Versionsnummer.
Wiz Research deckte mehrere kritische Schwachstellen im Kern von PHP auf und setzte die Exposition bei 70 Prozent aller Websites der Welt an. Die Australian Financial Review, die berichtete, künstliche Intelligenz habe kritische Bugs in der Sprache aufgedeckt, die die meisten Webserver nutzen, verwendete denselben Anteil: 70 Prozent der Websites der Welt in Gefahr. Diese Darstellung hat keine eigene Zählung. Die Zahl gehört diesen beiden Erzählungen, und sie ist die Zahl, vor der das Verhalten des Tages verständlich wird. Wenn auch nur ein ernsthafter Bruchteil dieses Anteils stimmte, wäre ein unauthentifizierter Weg zur Codeausführung auf dem Worker keine Spezialistengeschichte. Es wäre ein Grund für eine Regierungsstelle, einen Vormittag am Telefon zu verbringen — was die australische Berichterstattung beschreibt.
Eine Lücke von 2024, eine Einigung von 2026
Der Notfall hat eine Vorgeschichte, und sie ist der am wenigsten schmeichelhafte Teil der Akte.
Die PHP Foundation fand 2024 eine kritische Lücke, konnte sich aber bis 2026 nicht auf einen Fix einigen. Die Darstellung von The Next Web ist spezifisch in der Enge dieses Satzes: PHP wusste 2024 von einer der Lücken, und das Hindernis war nicht Unwissen. Es war Einigung. Die Quellen sagen nicht, welcher der beiden Oktober-CVEs dieser Fund war, wer für welches Mittel argumentierte oder was ein verworfener Fix gekostet hätte. Sie sagen, eine kritische Lücke sei gefunden worden, ein Fix habe sich nicht einigen lassen, und das Einigen habe bis 2026 gedauert.
Zwei Jahre sind eine lange Zeit, eine kritische Lücke in einer Sprache liegen zu lassen, die Wiz und die Australian Financial Review beide mit rund sieben von zehn Websites verbinden. Es ist länger, wenn das schließliche Release kein geplantes Point-Release mit vierzehntägiger Vorankündigung ist, sondern ein Notfall-Patch, angekündigt für einen Mittwochnachmittag in UTC, wobei Administratoren am Tag zuvor gesagt wurde, sie sollten bereit sein. Der Abstand zwischen „wir haben es gefunden“ und „wir haben uns geeinigt, wie wir es schließen“ ist in gewöhnlicher Software ein Werkstattstreit. In einer so weit eingebetteten Laufzeit ist derselbe Abstand, nach diesen Darstellungen, ein öffentliches Expositionsfenster. Die Oktober-Akte beweist nicht, was durch dieses Fenster ging. Sie zeigt, dass das Fenster real war und dass es Mitte des Monats nicht mehr nur eine Frage der Governance war.
Es gibt die Versuchung, das Scheitern der Einigung als Moral zu behandeln. Das Material trägt die Moral in keinem Detail. Es trägt eine Chronologie. Eine kritische Lücke, der Foundation 2024 bekannt. Kein vereinbarter Fix bis 2026. Dann, in wenigen Oktobertagen, ein Bündel von Dingen, die gewöhnlich nacheinander kommen, fast übereinander: eine Forschungsenthüllung, verbunden mit Wiz und mit Berichten, die künstliche Intelligenz zuschrieben; eine Warnung des Security-Teams; eine veröffentlichte Stunde; Patches für vier aktuelle Versionslinien; und, schon in der Telemetrie eines Cloud-Anbieters, ein Ausnutzungsversuch vom 17. Oktober, vor der öffentlichen Offenlegung der beiden CVE-Nummern.
Das Leck, wenn das das Wort ist, ist selbst ein belegtes Framing, kein geklärter Mechanismus. Huntress titelte durchgesickerte kritische Schwachstellen. PC Gamer schrieb von geleakten Exploits und von Administratoren, die sich auf die Updates gefasst machten, die sie schließen würden. Die offizielle Ankündigung galt einem bevorstehenden kritischen Security-Release, terminiert auf den 21. Oktober um 14:00 UTC. Nichts in diesen Quellen beschreibt, wie ein Leck entstand, wer die Details hielt oder ob der Versuch vom 17. Oktober dieselbe Information nutzte, die Forscher und Schlagzeilenschreiber später als geleakt bezeichnen würden. Was die Quellen erlauben, ist eine härtere, kleinere Behauptung. Der Versuch geht der öffentlichen Offenlegung voraus. Die öffentliche Offenlegung wurde als Notfall mit Uhr geführt. Und mindestens eine der zugrunde liegenden Lücken lag seit 2024 im Wissen der Foundation, ungelöst durch Einigung.
Sie haben es nicht übersehen. Bei einer der Lücken sind sie an der Einigung auf einen Fix gescheitert — von 2024 bis 2026.
Diese Unterscheidung ändert die Art von Beruhigung, die ein Patch bieten kann. Ein Bug, montags gefunden und mittwochs gefixt, ist ein Prozess, der mit Tempo arbeitet. Ein Bug, 2024 gefunden und unter Notfallbedingungen im Oktober 2026 ausgeliefert, ist ein Prozess, der schließlich funktionierte, nach einer Verzögerung, die Konsens, nach der Darstellung von The Next Web, nicht schließen konnte. Die Patches vom 21. Oktober löschen die Verzögerung nicht. Sie beenden sie.
Es lohnt sich zu bemerken, welche Art von Release daraus wurde, als die Einigung endlich kam. Kein stiller Commit. Ein Sicherheitsupdate mit veröffentlichter Stunde, angekündigt auf der Announce-Liste, schwer genug, dass das Security-Team den Vortag damit verbrachte, Administratoren zur Vorbereitung aufzufordern, und schwer genug, dass die Bewertungen der beiden Lücken bei 9,2 von 10 lagen. Die eigene Notiz von PHP an diesem Tag trägt im Titel das Versprechen zu sagen, wie das Projekt seine Sicherheit stärkt. Der Inhalt jeder längeren Reform liegt außerhalb dieser Quellen. Die Tatsache des Notfalls nicht. Sichtbar, im tatsächlich vorliegenden Material, ist die Entscheidung, zu einer genannten Stunde Fixes für zwei Lücken auszuliefern, die das Projekt nicht mehr bis zu einem bequemen Release liegen lassen wollte.
Der Tag, an dem das gewöhnliche Web sich selbst abschaltete
Ausfälle werden gewöhnlich von außen erzählt: eine Seite fällt aus, ein Nutzer merkt es, eine Statusseite holt auf. Dieser wurde an mehreren Stellen als Wahl erzählt.
Die Brussels Times berichtete, große Websites gingen offline, als die Schwachstelle Sicherheitsängste auslöste, und die Behauptung darunter ist direkt. Mehrere große Websites wurden wegen einer kritischen Schwachstelle in der Sprache vom Netz genommen. Der Maßstab der BBC war noch weiter: Websites weltweit heruntergefahren, während das Cybersicherheitsupdate erschien. Keine der Darstellungen listet die Methode auf — was gestoppt wurde, von wem, wie lange — und es wäre Fiktion, die fehlenden Operationen zu liefern. Sie binden die Ursache an das PHP-Problem. Sie binden die Reaktion, in der Berichterstattung mehr als eines Landes, als Abwesenheit statt als still angewendeten Hotfix.
Der offizielle Rat gab dieser Wahl einen Sponsor. US-amerikanische, europäische und britische Behörden empfahlen, Websites vorübergehend offline zu nehmen, bis sie repariert werden könnten. Es ist schwer zu überschätzen, wie selten dieser Satz der verantwortliche ist. Eine Seite herunterzunehmen ist in gewöhnlichen Zeiten das Ergebnis, das ein Angreifer will und ein Betreiber fürchtet. Hier behandelten drei Gruppen von Behörden vorübergehende Abwesenheit als den sichereren Zustand, solange der Fix noch nicht angewendet war. Die Mitteilung des National Cyber Security Centre über ein kritisches Sicherheitsproblem, das PHP betrifft, steht im selben Wetter, auch wo diese Akte das Centre nicht mit diesen Worten als Urheber der Offline-Empfehlung zitiert. Wofür das Centre neben der BBC zitiert wird, ist die Substanz: ein kritisches Problem, das Angreifern erlauben kann, Befehle auf jedem Webserver auszuführen, auf dem PHP läuft, und ein Sicherheitsupdate, veröffentlicht, um es zu beheben.
Australiens Version des Vormittags war ein Gedränge um den Patch. Die Australian Financial Review berichtete, künstliche Intelligenz habe kritische Bugs in der Programmiersprache aufgedeckt, die die meisten Webserver nutzen, und Regierungsbehörden hätten sich beeilt, Schwachstellen in Websites zu patchen. Dieses Detail zieht die Geschichte aus dem üblichen Theater der Verbraucherausfälle. Benannte Dienste in die Wartung zu schicken ist eine Art Schaden: eine Öffentlichkeit, die etwas nicht erreicht, das sie benutzt, ohne nachzudenken. Eine Regierungsbehörde, die in Eile patcht, ist eine andere. Dieselbe Sprache, eingebettet in Seiten, die nicht auf dieselbe Weise optional sind. Der Rahmen der AFR war die 70-Prozent-Zahl und die Entdeckung. Der operative Rahmen war einfacher. Der Bug steckte in der Sprache. Die Sprache steckte in den Seiten. Die Seiten mussten sich bewegen.
Japan liefert die konkreteste Liste und damit das nützlichste Korrektiv zur Abstraktion. Es ist leicht, „das Web“ zu sagen und ein Diagramm zu meinen. Schwerer ist es, einen Wartungshinweis abzutun, der CoDMon, Shadowverse: Worlds Beyond, Sakura's rental server, BASE, pictSQUARE, 킴블, X Server und つなぐ nennt. Dazu NicoNico und pixiv, wie Gigazine es tat, und die Liste hört auf, eine Metapher zu sein. Hosting ist der Multiplikator, der sich in diesen Namen verbirgt. Eine Schwachstelle in einer einzelnen Anwendung ist eine Schwachstelle in dieser Anwendung. Eine Schwachstelle in der Sprache, auf einem Mietserver oder auf X Server, ist eine Schlange von Kunden, die den Bug nicht gewählt haben und ihn, in jedem sinnvollen Sinn, nicht selbst umgehen können. Diese Quellen zählen diese Kunden nicht. Sie zeigen die Hoster, die den Patch als dringend genug behandelten, den Dienst in die Notfallwartung zu nehmen.
Das Security-Team hatte um Vorbereitung gebeten, und das Timing zeigt die Form dessen, was verlangt wurde. Die Warnung galt der Vorbereitung auf Notfall-Updates am nächsten Tag. Das Release war auf 14:00 UTC am 21. angesetzt. Die Patches, einmal ausgeliefert, waren die vier bereits genannten Point-Releases. Was die Stunden um diesen Termin füllte, war nach dieser Akte kein einziger koordinierter Blackout. Es war ein Flickenteppich: manche Seiten offline aus Sicherheitsangst, manche heruntergefahren, während das Update hinausging, manche in benannter Wartung, manche überrannt von australischen Regierungsbehörden, deren Problem der Patch selbst war. Das gemeinsame Element ist die Sprache und das Urteil, dass das Warten auf einen bequemen Abend nicht mehr die konservative Wahl war.
Schwere hilft, das Urteil zu erklären, ohne es wegzuerklären. Zwei Schwachstellen, jede mit einer Bewertung von 9,2 von 10, ist keine Paarung, die zu einem gestaffelten Rollout über ein stilles Wochenende einlädt. Unauthentifizierte Reichweite, im demonstrierten mod_php-Fall, bevor Anwendungscode läuft, ist keine Paarung, die Vertrauen in spätere Prüfungen einer Anwendung einlädt. Daneben eine Warnung, das Problem könne Befehlsausführung auf jedem Webserver erlauben, auf dem PHP läuft, und der Rat, offline zu gehen, bis gefixt ist, hört auf, nach Theater auszusehen. Er sieht aus wie die verbleibende Option, sobald die Lücke als in der Laufzeit sitzend verstanden wird und nicht in einer Ecke, die ein Betreiber einfach abschalten kann.
Nichts davon verlangte, dass die Schwachstellen für alle neu waren. Es verlangte, dass sie neu unleugbar waren. Das Wissen der Foundation von 2024 und ihre Unfähigkeit, sich bis 2026 auf einen Fix zu einigen, gehört in denselben Atemzug wie die Wartungshinweise. Die Seiten, die am 21. Oktober dunkel gingen, lebten in einer Verzögerung, über die sie nicht abgestimmt hatten. Das ist die politische Tatsache in einer Release-Engineering-Tatsache. Eine Sprache, die nach der Erzählung von Wiz und der AFR von etwas wie 70 Prozent der Websites der Welt genutzt wird, ist keine private Codebasis, auch wenn ihre Governance ein privater Streit ist. Die Kosten eines nicht vereinbarten Fixes zahlen Menschen, die nicht in der Sitzung sitzen.
Wer wusste, und wer es schon versuchte
Es gibt zwei Premieren in dieser Geschichte, und sie beantworten verschiedene Fragen.
Wiz Research deckte mehrere kritische Schwachstellen im Kern von PHP auf. Die Darstellung des Unternehmens und die der Australian Financial Review setzen beide künstliche Intelligenz in die Entdeckung. Wiz rahmte den Fund als KI, die kritische Remote-Code-Execution-Schwachstellen aufdeckte, die 70 Prozent des Internets betreffen. Die AFR berichtete, KI habe einen Bug entdeckt, der 70 Prozent der Websites der Welt in Gefahr bringe, und australische Regierungsbehörden seien in Eile. Wie ein Modell eingesetzt wurde, was ihm gezeigt wurde, was ein menschlicher Forscher noch beweisen musste: nichts davon steht im Material hier, und es wäre Fiktion, es zu liefern. Was im Material steht, ist die Zuschreibung. Eine mit Wiz verbundene Forschungsanstrengung, an mehr als einer Stelle als Arbeit von KI beschrieben, brachte mehrere kritische Lücken im Kern der Sprache an die Oberfläche. Nach dieser Erzählung war das keine Fehlkonfiguration in einer populären Extension. Es war PHP selbst.
Die andere Premiere ist keine Entdeckung. Sie ist ein Versuch. Amazon Threat Intelligence identifizierte einen PHP2Shell-Ausnutzungsversuch, datiert auf den 17. Oktober 2026, in der MadPot-Telemetrie, vier Tage vor der öffentlichen Offenlegung von CVE-2026-109618 und CVE-2026-109619. Ein Versuch ist keine Breach-Zählung. Diese Quellen sagen nicht, wie viele Server antworteten, was mitgenommen wurde oder ob der Versuch auf dauerhafte Weise gelang. Sie sagen, er sei identifiziert worden, auf den 17. datiert, und die öffentliche Offenlegung der beiden CVEs sei vier Tage später gekommen. In einer Woche großer Behauptungen — jeder Webserver, 70 Prozent der Websites, weltweite Abschaltungen — ist der Amazon-Satz fast asketisch, und er ist der, der die Temperatur am meisten verändert. Jemand wartete nicht auf das FAQ.
Flach gelegt ist die Sequenz diese. Eine kritische Lücke, der Foundation seit 2024 bekannt, ohne vereinbarten Fix. Ein Ausnutzungsversuch am 17. Oktober 2026, gesehen in Amazons MadPot-Telemetrie. Eine Warnung des PHP-Security-Teams, sich am nächsten Tag auf Notfall-Updates vorzubereiten. Ein angekündigtes Release um 14:00 UTC am 21. Oktober, getragen auf php.announce und bestätigt von Huntress, von PC Gamers Darstellung der sich wappnenden Administratoren und von Dane Knechts Beitrag. Patches am selben Tag ausgeliefert, als 8.5.12, 8.4.27, 8.3.36 und 8.2.35, die zwei kritische Schwachstellen schließen, die unauthentifizierte Remote Code Execution erlauben. Um diese Auslieferung herum: Seiten offline, Seiten in Wartung, Behörden in Eile, Behörden, die Dunkelheit als vorübergehende Kontrolle empfehlen.
Was diese Chronologie nicht trägt, ist eine einzige Handlung, die von einer Uneinigkeit 2024 zu einer Sonde am 17. Oktober läuft. Nichts hier verbindet das unveröffentlichte Scheitern der Foundation, sich zu einigen, mit dem MadPot-Versuch, oder diesen Versuch mit der Forschungsenthüllung, oder die Forschungsenthüllung mit einem genannten Betreiber. Das ehrliche Bild ist das mehrerer Uhren, nicht einer Verschwörung. Eine Governance-Uhr, die zwei Jahre lief. Eine Forschungsuhr, die in einer öffentlichen Aufdeckung endete, zugeschrieben Wiz und der KI. Eine defensive Uhr, sehr bewusst auf 14:00 UTC an einem Mittwoch gestellt. Und eine offensive Uhr, die nach Amazons Darstellung am 17. bereits geschlagen hatte.
Das Framing der geleakten Exploits sitzt unbeholfen über diesen Uhren, und die Unbeholfenheit sollte sichtbar bleiben. Wenn Huntress und PC Gamer recht haben, dass die Schwachstellen oder die Exploits geleakt waren, dann ist das Notfall-Release zum Teil eine Antwort auf einen Kontrollverlust über die Information, nicht nur eine Antwort auf einen Bug. Liest man die Announce-Liste für sich, ist das Release ein geplantes kritisches Sicherheitsupdate mit Startzeit. Beides kann wahr sein: ein Plan, und ein Plan, geführt dort, wo andere bereits ein Leck beschrieben. Die Quellen urteilen nicht. Sie zeigen ein Projekt, das eine öffentliche Stunde wählt, Forscher, die geleakte Lücken beschreiben, und Sensoren eines Cloud-Anbieters, die einen Versuch aufzeichnen, bevor die CVE-Nummern öffentlich waren. Das reicht, um die tröstliche Version zu verwerfen, in der das Erste, was irgendjemand draußen von den Lücken hörte, ein poliertes Advisory und ein Satz Pakete war.
Es reicht auch, um bei Erfolg vorsichtig zu sein. „Exploitation attempt“ ist die Formulierung, die Amazons Darstellung trägt. „May allow“ ist die Formulierung, die an der Befehlsausführung auf jedem Webserver mit PHP hängt. „Demonstrated“ ist das Wort, das das PHP-Archiv für den mod_php-Pfad benutzt, bei dem eine unauthentifizierte Anfrage den Angriff auslösen kann, bevor Anwendungscode läuft. „Confirmed impact“ ist unauthentifizierte Remote Code Execution als das Konto des Web-Workers. Unvorsichtig gestapelt werden diese Sätze zu einem Gefühl allgemeiner, bereits vollzogener Kompromittierung. Gelesen wie geschrieben sind sie genauer, und die Genauigkeit ist die Nachricht. Es gibt einen demonstrierten Pfad. Es gibt eine bestätigte Klasse von Auswirkung. Es gibt einen aufgezeichneten Versuch vor der Offenlegung. Es gibt eine Warnung, breit genug, jeden Server zu decken, auf dem die Sprache läuft. Es gibt in diesem Material keine veröffentlichte Zählung von Intrusionen.
Was vier Versionsnummern schließen können
Die Pakete sind der Teil der Geschichte mit Versionsnummern, und Versionsnummern sind eine Gnade. PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 beheben zwei kritische Schwachstellen, die unauthentifizierte Remote Code Execution erlauben können. Vier Zweige, vier Point-Releases, ein Nachmittag. Für die Betreiber auf diesen Zweigen hatte der Notfall ein Ende, das sich herunterladen ließ. Das Sicherheitsupdate war nicht nur für 14:00 UTC versprochen. Es wurde veröffentlicht, um ein kritisches Problem zu beheben, das Angreifern erlauben kann, Befehle auf jedem Webserver auszuführen, auf dem PHP läuft. Das ist der Satz, den das National Cyber Security Centre und die BBC in der Akte lassen, und es ist der Satz, gegen den die Wartungsfenster geöffnet wurden und gegen den sie sich schließen können.
Was die Pakete nicht automatisch schließen, ist der Streit um den Umfang.
Sie beantworten, auf der Fläche dieser Quellen, nicht den Administrator, dessen PHP 7 ist, oder 5, oder 6, die alle in der Menge der Versionen sitzen, die als betroffen gelten. Glaube ist kein Patch. Der Glaube ist gut bezeugt — vier Quellen, darunter das eigene Security-Release-Schreiben des Projekts und ein spezialisiertes FAQ von Watchtowr. Die Fixes, die genannt sind, sind kein passendes Set. So zu tun, als wäre es anders, um eines sauberen Endes willen, hieße, ein Backport zu erfinden, das diese Cluster nicht enthalten. Die saubere Aussage ist die unordentliche. Aktuelle 8.2, 8.3, 8.4 und 8.5 haben benannte Fixes. Ältere Linien liegen, im Urteil dieser vier Quellen, im geglaubten Wirkungsradius, und diese Akte endet dort.
Noch lösen die Pakete den Unterschied zwischen „jedem Webserver, auf dem PHP läuft“ und „am höchsten für mod_php“ auf. Ein Betreiber, dessen Setup nicht das ist, das das Archiv als höchstes Risiko markierte, kann die offizielle Warnung und die technische Notiz lesen und nicht wissen, welche die Nacht regiert. Der demonstrierte Fall des Archivs ist der, in dem eine unauthentifizierte Anfrage den Angriff auslöst, bevor irgendein Anwendungscode läuft, und es knüpft diese Demonstration an mod_php als höchstes Risiko. Die breitere Warnung wartet nicht auf die Unterscheidung. Behörden in den Vereinigten Staaten, Europa und Großbritannien empfahlen vorübergehenden Offline-Status, bis Seiten gefixt werden könnten, und diese Empfehlung liest sich nicht als auf ein einzelnes Servermodul beschränkt. Wenn es in dieser Episode einen Streit gibt, ist es kein Geschrei zwischen Anbietern. Es ist dies: eine weite institutionelle Beschreibung, wer exponiert ist, und eine engere technische Beschreibung, wo die Gefahr nachweislich am höchsten ist, in derselben Woche veröffentlicht, über dieselben zwei CVEs. Beides steht in der Akte. Keines hebt das andere auf.
Die Impact-Aussage hat ihre eigene Grenze, und die Grenze ist es wert, gehalten zu werden. Die bestätigte Auswirkung ist unauthentifizierte Remote Code Execution als das Konto des Web-Workers. Das ist schwer, und es ist spezifisch. Befehlsausführung, in der Formulierung von BBC und NCSC, ist die Macht, vor der gewarnt wird. Das Konto, das in der Impact-Bestätigung genannt ist, ist das des Workers. Ein sorgfältiger Leser tauscht das eine nicht gegen das andere hoch. Codeausführung als der Worker reicht, nach der belegten Behauptung, um enorm zu zählen: es sind die eigenen Hände der Website. Es ist nach dieser Evidenz keine belegte Behauptung automatischer Kontrolle jenseits dieses Kontos. Die Angst des Tages war auf die Behauptung kalibriert, die die Quellen tatsächlich machen, und diese Behauptung reichte bereits, Homepages zu leeren und, im Urteil dreier Behördengruppen, ein vorübergehendes Verschwinden zu rechtfertigen.
Es gibt eine weitere Grenze um das Wort „Versuch“. Amazon sah am 17. Oktober einen PHP2Shell-Ausnutzungsversuch, vor der Offenlegung. Die Patches vom 21. können ihn nicht ungesehen machen. Sie können die Bugs schließen, die ein solcher Versuch gebraucht hätte, auf den Versionen, die sie decken, für die Betreiber, die sie anwenden. Sie können nicht sagen, wie viele Versuche dieser Art nie gesehen wurden oder wie viele an Orten ohne Telemetrie von MadPots Art gelangen. Das Fehlen einer Opferliste in diesen Quellen ist kein Beleg für eine stille Woche. Es ist der Beleg, dass diese Akte von der Lücke, dem Fix, dem Rat und einem identifizierten Versuch handelt — nicht von einer abgeschlossenen Bilanz des Schadens.
Und es gibt die Grenze um 2024. Die Patches einigen einen Fix. Sie erklären nicht die Uneinigkeit, die einen verzögerte. Der Befund von The Next Web steht als das Rauschen unter den Release Notes: eine der Lücken war 2024 bekannt; ein Fix ließ sich bis 2026 nicht einigen; die Einigung, als sie kam, kam als Notfall, am Vortag angekündigt und mit 9,2 von 10 bewertet. Wer eine Geschichte von einem Sprint von der Entdeckung zum Patch will, muss die Uhr im Oktober starten. Wer sie dort startet, wo The Next Web sie startet, sieht einen zweijährigen Streit und dann einen Mittwoch.
PHP2Shell ist ein guter genug Name für eine Woche. Es ist ein schlechter Name für den Zustand, den die Woche bloßlegte. Der Zustand ist, dass eine Lücke in dieser Sprache bekannt sein kann und uneinig und dann plötzlich jedermanns; dass der Patch, wenn er kommt, real sein kann und trotzdem, in den Quellen, die wir haben, nicht jede Version deckt, die Forscher für im Scope halten; dass die offizielle Warnung und die technische Notiz beide sorgfältig sein können und trotzdem nicht dasselbe sagen. Die vernünftige Anweisung, für einen Tag, war nicht, klüger als den Bug zu sein. Sie war, offline zu sein, bis die Pakete mit diesen vier Nummern nicht mehr ein Versprechen für 14:00 UTC waren, sondern eine Datei, die tatsächlich ausgeliefert worden war.
Das Web, in den Darstellungen jenes Mittwochs, fiel nicht von allein um. Teile davon wurden absichtlich schlafen gelegt, von Betreibern und Hostern, die die Warnung gelesen hatten und eine Wartungsseite einem Worker vorzogen, der die Befehle eines anderen ausführt. Das ist keine kleine Geschichte über ein Point-Release. Es ist die Geschichte, wie viel gewöhnliches Leben inzwischen in einem PHP-Prozess sitzt — ein Anteil, den Wiz und die Australian Financial Review beide nahe 70 Prozent der Websites der Welt setzen — und wie wenig Raum das lässt, wenn einem Worker nicht mehr zu trauen ist, den Speicher einer Anfrage nicht als Zustand der nächsten Anfrage nachklingen zu lassen. Der Fix, auf den Linien, die er deckt, sind vier Versionsnummern und ein Nachmittag. Die Verzögerung, die den Nachmittag zum Notfall machte, war zwei Jahre lang.