PHP liefert Notfall-Fixes für zwei CVSS-9.2-Lücken, für die eine einzige Anfrage reicht

PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erschienen am 21. Oktober 2026 um 13:30 UTC, einen Tag nachdem das Projekt ein außerplanmäßiges Sicherheitsrelease angekündigt hatte. Die Builds enthalten Korrekturen für zwei Schwachstellen, CVE-2026-109618 und CVE-2026-109619, die beide mit 9.2 nach CVSS 4.0 bewertet wurden. Beide ermöglichen nicht authentifizierte Remote-Code-Ausführung, und öffentlicher Proof-of-Concept-Code begann zu zirkulieren, sobald das Release draußen war.

Zum Weiterlesen: WordPress stopft Comment2Shell, eine Kommentar-Lücke, die zur Server-Übernahme führen kann · Check Point schließt zwei VPN-Lücken der Schwere 9,8, die nicht authentifizierte Codeausführung erlauben.

Die meisten Sicherheitslücken im Web stecken im Anwendungscode. Diese beiden stecken im Interpreter. Ein demonstrierter Exploit braucht eine einzige Anfrage von einem anonymen Client, und er greift, bevor eine Zeile WordPress- oder Drupal-Code ausgeführt wird. Ein gepatchtes Plugin und eine gut abgestimmte Regel einer Web Application Firewall liegen beide hinter der Stelle, an der der Angriff einschlägt.

Zwei Wege, einen Worker zu brechen

Die beiden Fehler haben vom Mechanismus her nichts miteinander zu tun und treffen doch an derselben Stelle.

CVE-2026-109618, geführt als GHSA-w8hw-w9fx-j79w, ist eine Speicherbeschädigung bei der Behandlung von Speichermangel. PHP setzt memory_limit über longjmp() durch, das eine Anfrage unterbrechen kann, während interne Anfragedaten erst teilweise initialisiert sind. Ein Multipart-Datei-Upload ist das Beispiel im Advisory. Der Aufräumpfad behandelt dann ungültige Daten als gültig und gibt Speicher frei, der nie initialisiert wurde, Speicher, der noch angreifergesteuerte Bytes aus früheren Allokationen enthalten kann. Ergebnis: eine Speicherbeschädigung, die ein Angreifer bis zur Codeausführung lenken kann.

CVE-2026-109619, GHSA-6wmf-4rv5-p3rp, ist veralteter globaler Zustand. Interner Zustand, der zu einer Anfrage gehört, kann überleben, nachdem der ihn tragende Speicher freigegeben wurde, wobei ein fataler Fehler als eine der Routen genannt wird. Eine spätere Anfrage, die derselbe Worker bearbeitet, kann diesen veralteten Zustand lesen, bevor die normale Initialisierung ihn überschreibt. Der Worker muss dafür nicht abstürzen.

Diese Abhängigkeit von der Wiederverwendung von Workern erklärt, warum die Empfehlungen zur Abmilderung immer wieder auf Neustarts zurückkommen. Eine Einstellung in php.ini zu ändern, erreicht einen Worker nicht, der bereits mit der alten Konfiguration läuft, und das Binary darunter auszutauschen ebenso wenig. Der Pool muss recycelt werden, bevor eine der beiden Änderungen wirkt.

Beide Fehler sind mit 9.2 bewertet, und beide wurden dem PHP-Projekt vor der Veröffentlichung gemeldet, weshalb Distributionspakete und Anbieter mit Langzeit-Support am ersten Tag Patches bereithielten. Das PHP-Team veröffentlichte außerdem minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1, eine Übergangslösung für Zweige, die keinen offiziellen Support mehr erhalten.

Welche Server-Setups das Risiko tragen

Jede PHP-Installation, die Webanfragen bedient, ist betroffen. Das PHP-Projekt nennt PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed und stuft mod_php als die riskanteste der fünf Konfigurationen ein. Der Warnung lagen keine Ausnutzungsdaten je Konfiguration bei, die Einstufung ist also eine Einschätzung des Anbieters und keine gemessene Ausnutzungsrate.

Gewicht bekommt die Einstufung durch die Verbreitung. W3Techs, zitiert von The Verge, beziffert PHP auf 69,3 Prozent aller Websites, deren serverseitige Sprache sich identifizieren lässt, eine Gruppe, zu der Wikipedia und WordPress gehören. Der Scanner von VirusTotal erfasst rund 3,8 Millionen Websites mit PHP und mindestens einem offenen Port. Die Cortex-Xpanse-Telemetrie von Unit 42 ergab eine größere Zahl: über 22,6 Millionen exponierte Instanzen, potenziell verwundbar.

Keine der beiden Zahlen zählt bestätigt ausnutzbare Hosts. „Potenziell verwundbar“ umfasst jede Adresse mit einer PHP-Version, die älter ist als der Fix, einschließlich Installationen hinter einem Proxy, der die relevante Anfrageform blockiert, und Shared Hosts, die den Interpreter vielleicht schon gepatcht haben, ohne ihre Kunden zu informieren.

The Verge nannte 4chan, DeviantArt, Wikipedia und den Blog einer lokalen Bar unter den betroffenen Seiten. Kotaku berichtete, dass Pokémon Home und Pokémon Champions offline genommen wurden. Einige niederländische und finnische Behörden nahmen Seiten vorsorglich vom Netz, und Unit 42 sagte, mindestens eine europäische Regierung habe dasselbe getan. Cloudflares Technikchef John Graham-Cumming sagte The Verge, das Unternehmen „sehe erste Angriffe aufkommen“.

Ein 20 Jahre alter Fehler, den KI praktikabel gemacht hat

Wiz Research, das die Schwachstellen gemeinsam mit dem PHP-Projekt entdeckte und meldete, sagt, der zugrunde liegende Defekt sei seit rund 20 Jahren in PHP.

Die Ausnutzung des Fehlers „erforderte eine außergewöhnlich komplexe Kette von Schritten, am Rand dessen, was menschliche Forscher praktisch erreichen konnten“. — Wiz Research

Ein Fehler kann zwei Jahrzehnte in einer Codebasis schlummern, ohne zum Massenphänomen zu werden, solange die Kosten für einen funktionierenden Exploit über dem liegen, was die meisten Angreifer zu zahlen bereit sind. Wiz führt den Wandel auf KI-Modelle zurück, die es viel einfacher gemacht hätten, aus einem obskuren Speicherverwaltungsdefekt eine funktionierende Kette zu bauen. Google, dem Wiz gehört, veröffentlichte am 21. Oktober seine Darstellung. OpenAI erklärte separat, eine KI-Sicherheitsgruppe namens Calif habe mit GPT-5.6 Sol eine kritische PHP-Lücke identifiziert.

Zwei Organisationen, die mit KI-Unterstützung forschten, stießen auf denselben Defekt auf Interpreter-Ebene, und das PHP-Projekt und Wiz veröffentlichten gemeinsam. Das ist ein Fall, und ein Fall entscheidet nicht, wie stark KI das Gleichgewicht zwischen Angreifern und Verteidigern verschiebt.

Was das Patchen über die Versionsnummer hinaus bedeutet

Für die meisten Seiten besteht die Arbeit aus einem Interpreter-Update plus einem Neustart, und beim Neustart wird es im Shared Hosting unangenehm. Langlebige PHP-FPM-Worker bedienen weiter mit dem alten Binary, bis jeder einzelne recycelt ist. Container, die auf einem alten Basis-Image gebaut wurden, bleiben verwundbar, bis das Image neu gebaut und erneut ausgerollt ist. Ein Control Panel, das PHP 8.3 meldet, beweist nicht, dass der Pool die korrigierte 8.3.36 ausführt.

GoDaddy sagt, jede Seite mit PHP solle annehmen, betroffen zu sein, und das gelte für WordPress-, Drupal-, Joomla- und Magento-Installationen gleichermaßen, weil keine dieser Plattformen einen eigenen Interpreter mitbringt. Ein Plugin- oder Theme-Update ändert Dateien im Anwendungsverzeichnis. Es berührt nicht das Binary, das die Anfrage parst.

Zwei Lücken beim Support vergrößern den Rückstand. PHP 8.1 und älter sind End-of-Life und bekommen keinen offiziellen Build, wer also noch auf 8.0 oder 7.4 ist, muss upgraden oder einen Backport des Anbieters nehmen. Und das remi-Repository, eine verbreitete Quelle für neuere PHP-Pakete auf Red-Hat-Systemen, hätte am Release-Tag keine Updates gehabt. Der Rat des PHP-Teams war, auf Distributionspakete zu wechseln oder aus dem Quellcode zu bauen.

Was zu tun ist, solange der Rebuild in der Warteschlange steht

Die Warnung 2026-018 von CERT-EU benennt die Priorität klar: „CERT-EU rät Organisationen, betroffene Systeme sofort zu patchen.“ Ist ein Patch nicht machbar, sollen internetzugewandte Anwendungen von öffentlichen Netzen isoliert werden, bis ein Fix eingespielt und überprüft ist. Der NSA-Cybersecurity-Account auf X und das britische NCSC gaben ähnliche Ratschläge: Systeme offline nehmen, wenn ein sofortiges Update nicht möglich ist.

Für Organisationen, die nicht so schnell sein können, listet CERT-EU vorübergehende Maßnahmen. Sie verringern die Exposition, schließen die Lücke aber nicht.

• Für CVE-2026-109618: memory_limit=-1 so setzen, dass Anwendungen es nicht überschreiben können, etwa über php_admin_value in der FPM-Pool- oder Apache-Konfiguration. post_max_size auf 8M ohne Uploads und 32M mit Uploads senken. Grenzen für Anfragegröße, Felder und Multipart-Teile am Proxy durchsetzen und ein Speicherlimit für Container oder cgroups verwenden.
• Für CVE-2026-109619: session.upload_progress.enabled=0 setzen und jeden Worker neu starten. Unter PHP 8.5 fatal_error_backtraces=0 setzen und neu starten. Ungültige Einstellungen pro Anfrage entfernen, die vor der Initialisierung Diagnosen ausgeben, und fatale Fehler sowie Timeouts beheben, die von außen erreichbar sind.
• Für beide: patchen, dann neu starten. Ein aktualisiertes Binary auf der Platte, während die Worker noch das alte ausführen, ist kein Fix.

Was die Zahlen nicht beweisen

Die 22,6 Millionen und die 3,8 Millionen sind Expositionsschätzungen aus Anbieter-Telemetrie und einer Erhebung. Keine der beiden ist eine Zählung von Hosts, die Code ausführen, den ein Angreifer erreichen kann.

Nicht jede PHP-basierte Seite ist mit derselben Technik ausnutzbar. Die Fehler stecken in unterschiedlichen Subsystemen, und die Anfrageform, die den einen auslöst, funktioniert womöglich nicht gegen eine bestimmte SAPI oder eine bestimmte Optionskombination.

Zum Zeitpunkt des Schreibens war keine bestätigte Massenkompromittierung und keine Angreiferzuordnung veröffentlicht. Berichte über offline genommene Seiten beschreiben Vorsichtsmaßnahmen ebenso wie Vorfälle, und beides ist in dieser Phase leicht zu verwechseln. Das Fehlen einer veröffentlichten Massenkompromittierung ist kein Beweis, dass keine stattgefunden hat, sondern nur, dass am 21. Oktober kein solcher Befund öffentlich war.

Worauf zu achten ist

Das erste Signal ist, ob der Proof-of-Concept-Code zur Massenware wird. Eine funktionierende Kette in öffentlicher Hand senkt die Fähigkeiten, die für ihre Nutzung nötig sind, und die Verbreitung von PHP bietet jedem, der scannt, eine ungewöhnlich große Zahl von Zielen. Unit 42 sagte, erster Proof-of-Concept-Code zirkuliere und eine Ausnutzung sei wahrscheinlich.

Das zweite ist die End-of-Life-Frage. PHP 8.1 erhält keine offiziellen Fixes mehr, 7.4 und 8.0 liegen weiter zurück. Jede Seite, die noch auf diesen Zweigen läuft, ist darauf angewiesen, dass ein Distributions-Maintainer oder ein Hosting-Unternehmen einen Fix für Speicherbeschädigung zurückportiert, und ob das passiert, hängt vom Anbieter ab.

Dann ist da die Forschungsseite. Wenn KI-gestützte Arbeit weiterhin Fehler auf Interpreter-Ebene in diesem Tempo produziert, wird die Lücke zwischen der Veröffentlichung eines Fixes durch ein Projekt und der langen Kette ungepatchter Server, die ihn einspielen, zur entscheidenden Zahl, nicht der CVSS-Score.

Vorerst ist die Reihenfolge kurz. Den Interpreter patchen, jeden Worker neu starten, die laufende Version bestätigen und die Expositionsschätzungen als Grund zur Eile behandeln, nicht als Messwert. Seiten, die das heute nicht schaffen, sollten vom öffentlichen Internet genommen werden, was mehrere Betreiber bereits gewählt haben.

Titelbild: „Custom-software-developement-php-net“ von Ron23545, CC BY-SA 4.0, via Wikimedia Commons.