StartseiteArtikel

Die PHP-Krise löst weltweit Notfall-"Kabelziehen"-Maßnahmen aus, verlasse dich nicht darauf, dass KI das Internet rettet.

爱范儿2026-10-23 07:41
Nachdem die Website kompromittiert wurde, können Daten, Passwörter und Tokens betroffen sein.

Die erschreckenden 48 Stunden des Internets spielen sich gerade ab.

Bild | Quelle: Wired

Gestern Abend gingen die Regierungswebsites mehrerer europäischer Länder nacheinander zur gleichen Zeit offline.

Die finnische Verkehrs- und Kommunikationsbehörde hat einige Online-Dienste abgeschaltet; das niederländische elektronische Identitätssystem DigiD, die persönliche Dienstleistungsplattform der niederländischen Regierung MijnOverheid und das Regierungsportal wurden alle außer Betrieb gesetzt, sogar die eigene Website des niederländischen Nationalen Zentrums für Cybersicherheit war zeitweise geschlossen……

In Japan haben mehrere bekannte Internet-Community-Plattformen, wie pixiv, die größte japanische Community für Illustrationen, Manga und Roman-Einreichungen, die etablierte japanische Bullet-Chat-Videoplattform Niconico sowie BOOTH, die E-Commerce-Plattform für Schöpfer unter pixiv, eine Notfallwartung angekündigt.

Sogar Sushiro hat auf seiner offiziellen Plattform angekündigt, dass die Mini-Programm heute aufgrund von Systemwartung und -aktualisierung vorübergehend nicht verfügbar ist.

Was so viele Institutionen in Alarmbereitschaft versetzt, sind zwei neu veröffentlichte Schwachstellen mit den Nummern CVE-2026-109618 und CVE-2026-109619.

Die Sicherheitsgemeinschaft hat ihnen einen direkten Spitznamen gegeben: PHP2Shell. Das bedeutet, dass ein Angreifer durch das Senden einer einzigen Anfrage an Ihre Website eine Shell (Eingabeaufforderung für die Befehlszeile) auf Ihrem Server erhalten kann, also die uneingeschränkte Kontrolle über alles hat.

Am 21. Oktober veröffentlichte das offizielle PHP-Team die Notfallaktualisierungen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 und bestätigte gleichzeitig: Die Schwere beider Schwachstellen beträgt 9,2 Punkte nach CVSS (maximal 10 Punkte), sie kann aus der Ferne ohne Benutzernamen und Passwort ausgenutzt werden.

Und bei Apache, der ältesten quelloffenen Webserver-Software der Welt und der häufigsten Bereitstellungsart für PHP, wird der Angriff ausgelöst, bevor der Code der Website selbst überhaupt ausgeführt wird.

Das Gerücht von einer „Vollpunkt-Schwachstelle“ stellte sich als wahr heraus

Der Beginn dieser Krise war dramatisch.

Nach dem ursprünglichen Plan sollten die Details der Schwachstelle am 22. Oktober koordiniert veröffentlicht werden. Aber am Nachmittag des 20. Oktober erschien ein Beitrag auf Hacker News, der behauptete, dass PHP zwei Schwachstellen zur Ausführung von Remotecode mit einer Bewertung von 10,0 aufweist.

Bild | Quelle: Reuters

Obwohl der Beitrag schnell gelöscht wurde, verbreiteten sich die Screenshots bereits. Das Sicherheitsunternehmen watchTowr bestätigte innerhalb weniger Stunden, dass diese Leckage wahr ist, die Schwachstelle existiert und sie bereits eine davon nachgestellt haben.

Das PHP-Sicherheitsteam veröffentlichte in derselben Nacht eine Warnung, verschob den Veröffentlichungstermin um 24 Stunden und fügte ungewöhnlich hinzu: „Wenn die Details der Schwachstelle öffentlich werden oder Beweise für eine Ausnutzung in der Wildnis (in-the-wild exploitation) auftauchen, behalten wir uns das Recht vor, die Veröffentlichung weiter vorzuziehen.“

Das Chaos ging weiter. In derselben Nacht veröffentlichte das Sicherheitsunternehmen Calif, das an der Entdeckung der Schwachstelle beteiligt war, versehentlich ein Demonstrationsvideo, das zeigte, dass ihr Angriffscode auf mehreren echten Zielen funktioniert, und Kopien des Videos verbreiteten sich sofort auf sozialen Plattformen.

Am nächsten Morgen brach der Händler Chainguard, der den Patch vorzeitig erhalten hatte, einseitig die Geheimhaltungsvereinbarung und veröffentlichte vorab das Image mit der Reparatur. Der Patch selbst ist eine „Schwachstellenkarte“: Angreifer müssen nur die Binärdateien der alten und neuen Version vergleichen, um zu sehen, welcher Codeabschnitt geändert wurde, und können so Position und Prinzip der Schwachstelle ableiten.

In der nachträglichen Analyse der PHP-Stiftung war man sehr wütend über die Art und Weise, wie diese Schwachstelle veröffentlicht wurde.

Nach der Branchenregel sollten nach der Entdeckung einer Schwachstelle dieses Niveaus Forscher, Hersteller und Händler einen einheitlichen Zeitpunkt vereinbaren, vor dem niemand Details öffentlich machen darf. Das Ziel ist es, dass Patch und Informationen zur Schwachstelle gleichzeitig die Öffentlichkeit erreichen: Sobald der Nutzer von der Schwachstelle erfährt, kann er sofort den Patch installieren, sodass das Zeitfenster für die Verteidiger maximal ist.

Die betroffene Seite ist das Fundament des Internets

Um zu verstehen, warum dieses Ereignis so erschreckend ist, muss man zuerst verstehen, was PHP ist.

Es ist die „Hinterküche“ des Internets. Wenn wir uns im Vordergrund anmelden, suchen, bestellen und kommentieren, verarbeitet PHP im Server die Anfragen, liest und schreibt Datenbanken und sendet die Ergebnisse zurück an den Browser. WordPress, Drupal, Joomla, Magento, MediaWiki hinter Wikipedia – alle laufen auf PHP.

Laut Daten von W3Techs verwenden unter den Websites, deren serverseitige Technologie identifiziert werden kann, 69,3 % PHP; der Zweitplatzierte JavaScript hat nur 8,1 %.

In FOFA, unserer im Inland entwickelten Suchmaschine für die Kartierung des Cyberspace bei Baimaohui, haben wir auch die gesamten Netzwerkdatensätze mit WordPress durchsucht. Man kann erkennen, warum die ersten Reaktionen aus Regionen wie Europa, Amerika und Japan kamen: In diesen Regionen gibt es die meisten Asset-Einträge, die der WordPress-Fingerabdruckregel entsprechen.

Die meisten früheren Nachrichten über „gehackte PHP-Websites“ hatten Probleme mit einem bestimmten Plugin oder einer bestimmten Anwendung. Diese Schwachstelle befindet sich im Kern des PHP-Interpreters und hat nichts mit den Anwendungen auf höherer Ebene zu tun. Mit den Worten von Wiz, einem der Entdecker: „Selbst wenn auf Ihrer Website nur ein einfaches Hello World läuft, ist sie trotzdem betroffen.“

Die technischen Prinzipien beider Schwachstellen sind nicht besonders neu, aber das Beeindruckende ist, dass sie nachweislich „wirklich funktionieren“.

CVE-2026-109618: PHP verarbeitet den „Speichererschöpfung“ auf eine grobe Weise mit einem abrupten Stopp (longjmp).

Wenn der Stopp genau in einem heiklen Moment erfolgt, sind die internen Daten nur teilweise initialisiert, aber der anschließende Bereinigungsprozess behandelt diese halbfertigen Daten als normale Daten, und Angreifer können dies nutzen, um den Server dazu zu bringen, ihren eigenen Code auszuführen.

Das Offizielle hat bestätigt: In der Standardkonfiguration kann man den Angriff vor der Ausführung des Anwendungscodes abschließen, indem man eine spezielle multipart-Anfrage erstellt, um den Speicher „genau richtig“ zu erschöpfen.

CVE-2026-109619: Nachdem eine Anfrage verarbeitet und der Speicher freigegeben wurde, sind einige globale Zustände nicht vollständig bereinigt.

Wenn derselbe Arbeitsprozess die nächste Anfrage verarbeitet, könnte er diese bereits ungültigen Speicherbereiche erneut verwenden. Dieses klassische „Use-after-free“ kann sorgfältig zu einer Codeausführung gestapelt werden und zudem Passwörter, Token und API-Schlüssel anderer Benutzer im Speicher preisgeben.

Bemerkenswert ist, dass einer der nachgewiesenen Ausnutzungspfade über die standardmäßig aktivierte Funktion session.upload_progress (Sitzungs-Upload-Fortschritt) läuft, und die Anwendung muss nicht einmal session_start() aufrufen.

Die reparierten Versionen decken derzeit nur die vier Zweige von PHP 8.2 bis 8.5 ab. Gleichzeitig zeigen die Daten von W3Techs, dass unter allen PHP-Websites noch 27,0 % auf PHP 7.x und 7,7 % auf PHP 5.x laufen, diese längst nicht mehr gewarteten Versionen erhalten keine offiziellen Patches.

Der Forensiker für Computersysteme Hal Pomeranz erwähnte: „Es gibt zu viele eingebettete Installationen, die niemals gepatcht werden, zu viele vergessene, ungewartete Anwendungen. Diesmal wird der lange Schwanz sehr lang sein.“

Hat KI sie gefunden? Eine Woche und mehrere Monate

Sobald die Schwachstelle veröffentlicht wurde, veröffentlichte OpenAI einen Artikel, der dieses Ereignis in seine KI-Sicherheitserfolge aufnimmt: Die Forscher von Calif haben den entscheidenden Fehler mithilfe von GPT-5.6 Sol gefunden, und mehrere Teams haben gemeinsam die Überprüfung und Gegenmaßnahmen abgeschlossen.

Wir, die mit den Werbestrategien von KI-Unternehmen vertraut sind, werden uns unwillkürlich fragen: Hat das Modell die Schwachstelle wirklich entdeckt, oder wurde die Forschungsergebnis des Menschen nur mit einem KI-Etikett versehen?

Am Tag der Offenlegung hat Calif auf X öffentlich „die Wahrheit klargestellt“ und erklärt, dass Ryan Austin der erste war, der die Schwachstelle entdeckt und einen funktionsfähigen Angriffscode erstellt hat. Der Beweis ist ein Tweet, den er am 5. August veröffentlicht hat, der den Hash der Entdeckung enthält.