KI half beim Aufspüren der PHP-Lücke, doch das Patchen alter Server bleibt Menschenarbeit

Am Mittwoch, dem 21. Oktober, veröffentlichten die PHP-Entwickler die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35, die sie einen Tag zuvor ohne Details angekündigt hatten. Sie schließen zwei Sicherheitslücken, die zusammen PHP2Shell genannt werden und beide auf der CVSS-Skala mit 9,2 von 10 bewertet sind. Am gefährlichsten sind sie auf Apache-Servern mit mod_php: Dort kann ein Angreifer ohne Anmeldung, allein mit HTTP-Anfragen, eigenen Code ausführen, bevor die Website auch nur eine einzige Zeile ausgeführt hat. Andere Arten, PHP zu betreiben, sind aber ebenfalls nicht sicher, auch das verbreitete PHP-FPM nicht. PHP läuft auf rund 69 Prozent der Websites, deren serverseitige Sprache sich ermitteln lässt, darunter Wikipedia und Websites auf WordPress-Basis, berichtet The Verge unter Berufung auf W3Techs. Über die Entdeckung haben wir am Mittwoch berichtet.

Der älteste betroffene Code stammt aus PHP 5.4, das 2012 erschien. Der zugrunde liegende Fehler bei der Behandlung von Speichermangel fiel schon 2024 auf, als Probleme aus einem externen Audit behoben wurden. Doch niemand zeigte, wie er sich ausnutzen lässt, und so schob das Sicherheitsteam von PHP, dem Leute fehlten, die Korrektur immer wieder auf - die PHP Foundation spricht von einem „strukturellen Versagen“. Im August dieses Jahres meldeten Calif und OpenAI den Fehler unabhängig voneinander, zwei Wochen später folgte Wiz, das zu Google gehört.

Wiz schreibt, es habe die Modelle Gemini 4 Argon und GPT-5.6 Sol sowie das eigene Tool Wiz Atlas eingesetzt. Das Unternehmen schreibt dazu: „Mit KI-Spitzenmodellen und den richtigen Werkzeugen hat ein einzelner Forscher in einer Woche geschafft, wofür früher ein Weltklasse-Team monatelange Arbeit gebraucht hätte.“ Welches Modell Calif geholfen hat, wissen wir nur von OpenAI. Calif suchte im Rahmen von Patch the Planet nach Fehlern, einem Programm von OpenAI, und es war OpenAI, das bekannt gab, die Lücke sei mit GPT-5.6 Sol gefunden worden. Calif selbst nennt das Modell nicht und schreibt nur, man habe Modelle genutzt, die allen zugänglich sind.

KI beschleunigt auch die Angreifer. CJ Moses, Chief Information Security Officer bei Amazon, erklärt, dass früher die meisten Angriffe erst begannen, nachdem ein funktionierender Exploit veröffentlicht worden war. Laut Moses macht es KI heute billig, allein aus dem Patch oder der Sicherheitsmeldung einen funktionierenden Exploit zu bauen. Dadurch können mehr Angreifer innerhalb von Stunden oder sogar Minuten zuschlagen, nachdem die Details öffentlich geworden sind. Matthew Prince, CEO von Cloudflare, sagte, Cloudflare habe in den 45 Minuten nach Veröffentlichung des Patches Zehntausende Exploit-Versuche in seinem Netz gesehen und weniger als 12 Stunden später Millionen.

Manche Angreifer warteten nicht einmal auf den Patch. Laut der PHP Foundation gelangten die Kennungen der Lücken am Tag vor der Veröffentlichung ins Netz, und Calif stellte versehentlich für kurze Zeit ein Video eines funktionierenden Angriffs online. Cloudflare registrierte in den 10 Stunden vor dem Patch Tausende Versuche. Amazon fand in seinen Daten einen noch früheren Versuch vom 17. Oktober, also noch vor dem Leak. Woher jemand so früh von der Lücke wusste, weiß niemand. Ein erfolgreicher Einbruch wurde bislang allerdings nicht bestätigt.

Manche Institutionen wollten nicht abwarten. Wie CNBC unter Berufung auf Reuters berichtet, wurden in den Niederlanden unter anderem das Regierungsportal Overheid.nl, die Website des Hafens Rotterdam und sogar die Website des NCSC, des nationalen Zentrums für Cybersicherheit, vom Netz genommen. In Finnland trennte der staatliche IT-Dienstleister Valtori öffentliche Behördendienste vom Internet, und in Frankreich wurden Websites der lokalen Verwaltung abgeschaltet. CERT Polska, das nationale Computer-Notfallteam (CERT) Polens, empfahl schon vor dem Patch dasselbe: aus dem Internet erreichbare Dienste mit PHP vorübergehend abzuschalten, sofern das die Arbeit der Organisation nicht beeinträchtigt. Die US-Behörde CISA rät, alle Systeme vom Netz zu nehmen, die sich nicht sofort aktualisieren lassen, ebenso alles, was mit PHP 8.1 oder älter läuft.

Einige Administratoren haben alte Systeme bereits mit Hilfe von KI aktualisiert und berichten in Foren davon. In einem Reddit-Beitrag heißt es: „Ich habe mit Claude gerade mal 30 Minuten gebraucht, um ein komplexes LMS-System von 5.6 auf 8.5 zu aktualisieren.“ Jemand, der Hunderte Drupal-7-Websites betreut, sagt, dass diese Upgrades ohne KI Monate gedauert hätten und Claude Code nun die Fehler behebt, die nach dem Wechsel der PHP-Version auftreten. Ein anderer Beitrag beschreibt, wie jemand aus der Systemadministration zwei Stunden lang mit einem Agenten die eigenen Systeme durchging und das Update plante. Danach bekam der Agent den Auftrag, ein Dashboard mit einer Zusammenfassung zu bauen, und die Person ging zum Mittagessen. Auf Hacker News schrieb jemand, Claude habe den eigenen MediaWiki-Blog in statische Seiten umgewandelt, sodass der Blog ohne PHP laufen kann, bis der Server gepatcht ist. Das sind nur die Schilderungen der Verfasser selbst, und niemand hat sie überprüft.

Das sind allerdings Geschichten von Leuten, die wussten, was sie tun, und ohne Eile auf eine neue Version umsteigen konnten. Wer heute in aller Eile einen Produktivserver retten muss, hat es viel schwerer, und solche Server gibt es reichlich. Recorded Future verweist auf Scans von VirusTotal: Server unter rund 1,1 Millionen IP-Adressen geben ihre PHP-Version preis, und auf etwa 758.000 davon, fast 70 Prozent, läuft PHP 8.1 oder älter. Das PHP-Team unterstützt diese Versionen nicht mehr und hat für sie kein fertiges Release mit der Korrektur veröffentlicht. Die US-Behörde CISA rät, solche Server vom Netz zu nehmen, bis sie aktualisiert sind.

Bleiben die Korrekturen von Linux-Distributionen und Hosting-Control-Panels, doch nicht jeder bekommt eine. Laut einer Übersicht von Digital Applied will Amazon einige PHP-Pakete in Amazon Linux überhaupt nicht patchen. Ubuntu 20.04 bekam die Korrektur nur in Ubuntu Pro, das auf höchstens fünf Rechnern kostenlos ist. Laravel Forge rät deshalb, jeden Server mit Ubuntu 20.04 oder älter durch einen neuen zu ersetzen und den alten abzuschalten.

Ohne fertiges Paket bleiben nur Korrekturen am Quellcode, die das PHP-Team für die Versionen 7.4, 8.0 und 8.1 veröffentlicht hat. Man muss sie selbst einspielen und PHP kompilieren, und zwar mit denselben Erweiterungen wie bisher. Ältere Versionen bekamen nicht einmal das. Jemand auf Reddit betreibt eine Website mit PHP 5.6 und ließ deshalb Claude die Korrekturen auf diese Version portieren. Und räumte sofort ein: „Ist das brauchbar? Wer zum Teufel weiß das schon.“

Selbst nach dem Update ist schwer zu sagen, ob ein Server sicher ist. Die Versionsnummer aus php -v entscheidet das nicht: In der Übersicht von Digital Applied sind 21 von 76 Einträgen Pakete, die die Korrektur erhalten, aber die alte Versionsnummer behalten haben. Ubuntu 24.04 zum Beispiel zeigt nach dem Update weiterhin 8.3.6 an. Auch das Prüftool von OpenAI für Server weist darauf hin, dass ein Ergebnis „UNKNOWN“ nicht „gepatcht“ bedeutet. Mit der Installation der Korrektur ist es auch nicht getan. Alle PHP-FPM-Prozesse müssen neu gestartet werden, weil die vor dem Update gestarteten weiterhin den alten, verwundbaren Code ausführen. Auf Servern mit cPanel oder Plesk muss jede installierte PHP-Version einzeln gepatcht werden.

Schnelle Behelfslösungen haben ihren Preis. Das Blockieren von Multipart-Anfragen, das unter anderem Sansec empfiehlt, unterbindet Datei-Uploads, und in manchen Shops legt es, wie das Unternehmen selbst einräumt, auch den Warenkorb lahm. Das Aufheben des Speicherlimits (memory_limit=-1) umgeht den Fehler bei Speichermangel, doch dann kann eine einzige Anfrage den gesamten Arbeitsspeicher des Servers aufbrauchen. Und das PHP-Team warnt, dass keine Einstellung vollständig schützt.

Auch KI hat versagt. Kunden von Hostinger zufolge versicherte der Chatbot des Unternehmens, PHP-FPM sei nicht verwundbar, obwohl die PHP-Entwickler klar sagen, dass es das ist. Auf Hacker News beklagten mehrere Nutzer, dass die Sicherheitsfilter von Claude und Codex ihre Arbeit an der Lücke unterbrachen.

Aus diesen Berichten ergibt sich eine einfache Trennlinie. KI beschleunigt die Arbeit erheblich für alle, die wissen, wie PHP auf dem eigenen Server läuft, woher die Pakete stammen und was nach einem Update zu prüfen ist. Wer das nicht weiß, bekommt trotzdem einen fertigen Plan, kann aber nicht beurteilen, ob er etwas taugt.

Wer eine Website betreibt, ohne sich selbst um den Server zu kümmern, kann mit zwei Fragen an die Zuständigen beginnen: Ist die Korrektur schon installiert, und hat jemand die Logs seit dem 17. Oktober durchgesehen, als Amazon den ersten Exploit-Versuch registrierte? Wenn niemand darauf antworten kann, schlägt ein Kommentar auf Hacker News vor, über Managed Hosting nachzudenken, bei dem der Anbieter PHP aktuell hält.

Glossar: CVSS - eine Skala von 0 bis 10, mit der bewertet wird, wie schwerwiegend eine Sicherheitslücke ist. Exploit - ein Programm oder eine Folge von Anfragen, die eine Sicherheitslücke in der Praxis ausnutzt. mod_php - PHP, das als Modul des Webservers Apache läuft. PHP-FPM - PHP, das als separater Pool von Prozessen läuft, an den der Webserver Anfragen weitergibt. Multipart - ein Format für HTTP-Anfragen, mit dem Browser Formulare samt Dateien senden.