PHP2Shell: Zwei kritische Lücken im PHP-Kern erlauben Codeausführung ohne Anmeldung

PHP-Team liefert Patches für zwei Kernlücken mit CVSS 9,2

Im PHP-Kern stecken zwei kritische Sicherheitslücken: CVE-2026-109618 und CVE-2026-109619. Nach CVSS v4.0 bewertet das PHP-Team beide mit 9,2. In der Berichterstattung laufen sie unter dem Namen „PHP2Shell“. Laut PHP-Sicherheitsteam ermöglichen die Fehler Remote Code Execution ohne Anmeldung. Ein Angreifer muss also nur einen PHP-Endpunkt über HTTP erreichen.

Wichtig ist die Einordnung: Die Fehler liegen laut den Belegen im PHP-Interpreter selbst, nicht in einem Framework oder Plugin. Sie betreffen damit alles, was PHP zur Auslieferung von Webseiten nutzt: Shops, Content-Management-Systeme und eigene Software. Eine Sekundärquelle berichtet, Calif habe unauthentifizierte Codeausführung unter anderem gegen Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony und WHMCS gezeigt. Shops sind demnach auch dann exponiert, wenn ihr eigener Code sauber ist. Ob eine Anwendung gefährdet ist, hängt deshalb nicht davon ab, wie sorgfältig sie programmiert wurde, sondern davon, welche PHP-Version auf dem Server läuft.

Am 21. Oktober 2026 um 14:00 UTC erschienen die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Alle früheren Releases sind betroffen. Die Advisories tragen laut redeyesecurity die Kennungen GHSA-w8hw-w9fx-j79w (CVE-2026-109618, Codeausführung über Speicherbeschädigung bei Speichermangel) und GHSA-6wmf-4rv5-p3rp (CVE-2026-109619, Codeausführung über veralteten globalen Zustand).

Zur Quellenlage: Die Primär-Advisories des PHP-Teams haben wir nicht direkt eingesehen. Alle Angaben in diesem Beitrag stammen aus Sekundärquellen, die sie zitieren.

Beschädigter Speicher nach abnormalem Request-Ende, mod_php am stärksten gefährdet

Beiden Lücken liegt dasselbe Grundproblem zugrunde: PHP kann seinen Speicher in einem beschädigten Zustand zurücklassen, wenn ein Request abnormal endet. Das beschreibt Bleeping Computer unter Berufung auf das PHP-Team. Warum daraus Codeausführung wird, lässt sich anhand der Beschreibungen erklären. Die technischen Details stammen allerdings nur aus Sekundärquellen, nicht aus den Advisories selbst.

CVE-2026-109618. Laut einer CVE-Beschreibung beendet PHP ein Skript bei Speichermangel (Out-of-Memory) über einen Sprung der C-Bibliothek, `longjmp`. Er bricht die laufende Verarbeitung mitten im Ablauf ab. In bestimmten Parsing- oder Ausgabesituationen kann der Sprung erfolgen, bevor der Request-Speicher vollständig zurückgesetzt ist. Die anschließende Aufräumroutine geht davon aus, dass alles sauber abgeschlossen wurde. Stattdessen liest sie veraltete, nicht initialisierte Daten oder verzweigt auf ihrer Grundlage. Wer diese Daten durch gezielt präparierte Requests beeinflussen kann, kann den Programmfluss umlenken. Genau das macht aus einem Speicherfehler Codeausführung. Ein Beleg nennt als Beispiel für einen Auslöser das Parsen von Multipart-Uploads in Verbindung mit dem Speicherlimit `memory_limit`. Diese Angabe ist unbestätigt.

CVE-2026-109619. Hier bleibt globaler Zustand zwischen Requests im selben Worker erhalten („stale global state“). Ein Worker ist ein PHP-Prozess, der nacheinander viele Anfragen bearbeitet. Bleibt nach einem abnormalen Ende ein Verweis auf Speicher zurück, kann der nächste Request ihm folgen. Der Speicher dahinter wurde inzwischen freigegeben und anderweitig genutzt. Das ist ein Use-after-free. Laut Bleeping Computer ermöglicht diese Lücke neben Codeausführung auch eine Speicherauslese, über die Daten aus dem Prozessspeicher abfließen können.

Was „Rechte des Web-Worker-Accounts“ heißt. Der Angreifer-Code läuft unter dem Benutzerkonto, mit dem der Webserver PHP ausführt. Er erbt dessen Zugriffe, in der Praxis also alles, was dieses Konto lesen, schreiben und ausführen darf. Dazu gehören üblicherweise die Dateien der gehosteten Anwendungen. Das ist eine Schlussfolgerung aus der Rechtebeschreibung und nicht einzeln belegt.

Betroffene Setups. Betroffen sind PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten sieht das PHP-Team das Risiko bei mod_php. Dort wurde ein Exploit gezeigt, bei dem ein unauthentifizierter Request den Angriff auslöst, bevor irgendein Anwendungscode läuft. Bei mod_php läuft PHP direkt im Apache-Prozess. Nach Angaben von Sansec sind die Lücken erreichbar, bevor Anwendungscode oder eine Schutzschicht auf Anwendungsebene greift. Solche Schutzmaßnahmen kommen dann schlicht zu spät.

Ältere Versionen. PHP 8.1 und älter erhalten keine offiziellen Releases. Für 7.4, 8.0 und 8.1 veröffentlichte das Team nur minimale Quell-Backports. Distributionen und LTS-Anbieter können eigene Backports ausliefern.

Ein veralteter Eintrag? Der OpenCVE-Eintrag nennt keine betroffenen Versionen und vermerkt, ein offizieller Patch stehe noch aus. Seit dem 21. Oktober stimmt das nicht mehr. Vermutlich wurde der Eintrag vor der Veröffentlichung der Advisories angelegt und danach nicht aktualisiert. Belegt ist das nicht.

Drei Entdecker, durchgesickerte Details und ein vorgezogenes Release

Entdeckt haben die Lücken Calif, OpenAI und Wiz. Laut einer japanischen Zusammenfassung meldeten sie die Fehler im August getrennt voneinander dem PHP-Team. Vorgesehen war das übliche Vorgehen der koordinierten Offenlegung: Die Entdecker informieren zunächst nur die Entwickler, damit diese in Ruhe einen Fix bauen können. Die Veröffentlichung war für den 22. Oktober geplant.

Dann sickerten Details vor dem Embargo durch. Die japanische Zusammenfassung nennt den 20. Oktober und ein Internetforum als Ort. Das PHP-Team kündigte am selben Tag auf php.net die Sicherheitsupdates für den 21. Oktober um 14:00 UTC an und lieferte dann auch an diesem Tag, einen Tag früher als geplant. Bei der Ankündigung hatte sich das Team ausdrücklich vorbehalten, früher zu veröffentlichen, falls Details einer der Lücken öffentlich würden oder Hinweise auf aktive Ausnutzung auftauchten. Das berichtet Bleeping Computer. Genau dieser Fall trat ein: Die Details waren bekannt, das Embargo war gebrochen, und ein längeres Warten hätte Angreifern nur Vorsprung verschafft. Laut einer Sekundärquelle meldete Cloudflare erste Angriffe schon um 07:43 UTC am 21. Oktober, also vor dem Release.

Wiz bezeichnet die Funde als „among the most severe vulnerabilities discovered in PHP, and arguably in software history“. Das Unternehmen erklärt außerdem, die zugrunde liegenden Fehler seien seit Jahrzehnten vorhanden gewesen. Ihre Ausnutzbarkeit zu zeigen, habe aber eine außergewöhnlich komplexe Kette von Schritten erfordert, an der Grenze dessen, was menschliche Forscher praktisch leisten können. Moderne KI-Modelle hätten diese Hürde deutlich gesenkt. All das sind Angaben des Herstellers der Entdeckung, die zugleich ein Eigeninteresse an der Bedeutung der Funde hat. Die Rolle der KI bestätigt laut der japanischen Zusammenfassung kein Dritter. Unabhängig prüfen ließe sich das nur anhand der Advisories des PHP-Teams und unabhängiger technischer Analysen, die uns nicht vorliegen.

Zwei Zahlen aus der Berichterstattung brauchen Einordnung:

• „70 Prozent aller Websites“: Wiz schreibt, PHP treibe 70 Prozent aller Websites an. Laut der japanischen Zusammenfassung ist das der PHP-Marktanteil unter Seiten mit erkennbarer serverseitiger Sprache. Es ist keine Aussage darüber, wie viele Installationen verwundbar sind.
• „10 von 10“: Manche Medien nennen diese Wertung. Das stimmt nicht. Das PHP-Team vergab 9,2.

Update muss auf den Server, Hoster sind für viele Kunden der einzige Weg

Die Lücken lassen sich nicht im Anwendungscode schließen. Der Fehler liegt in der Engine, die den Code ausführt, und tritt auf, bevor oder während Anwendungscode verarbeitet wird. Ein Fix in einem Shop, einem CMS oder einer eigenen Anwendung kann ihn deshalb nicht beheben. Nötig ist ein PHP-Update auf dem Server. Wer keinen eigenen Server betreibt, muss den Hoster bitten, das Update einzuspielen. Für viele Kunden ist das der einzige Weg.

Betreiber von PHP 8.1 und älter bekommen keinen offiziellen Fix. Sie sind auf Backports ihrer Distribution oder eines LTS-Anbieters angewiesen. Die Alternative bleibt der Umstieg auf eine unterstützte Version.