PHP2Shell: Updates für kritische PHP-Lücken verfügbar

PHP hat Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht, die eine unauthentifizierte Codeausführung aus der Ferne ermöglichen. Betreiber sollten jetzt auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren.

Aktualisiert am 21. Oktober 2026 um 16:13 Uhr MESZ: Die Patches und technischen Herstellerinformationen sind verfügbar. PHP bezeichnet ein Update als einzige vollständige Lösung.

Die zuvor unter dem Namen „PHP2Shell“ diskutierten Lücken sind nun offiziell als CVE-2026-109618 und CVE-2026-109619 bestätigt. Beide wurden mit 9,2 nach CVSS 4.0 bewertet. Laut der PHP-Sicherheitsmeldung betrifft das Risiko alle PHP-Installationen, die Webanfragen verarbeiten. Dazu gehören PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

Diese PHP-Versionen enthalten die Korrekturen

PHP-Zweig	Korrigierte Version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

PHP 8.2 erreicht am 31. Dezember 2026 sein Supportende. Wer diesen Zweig noch einsetzt, sollte deshalb nicht nur das Sicherheitsupdate installieren, sondern auch den Wechsel auf eine länger unterstützte Version planen.

Linux-Distributionen und LTS-Anbieter haben die Korrekturen vorab erhalten. Ihre Paketnummern können von den Upstream-Versionen abweichen. Entscheidend ist in diesem Fall die Sicherheitsmeldung des jeweiligen Distributors oder Hosting-Anbieters, nicht allein die angezeigte Versionsnummer.

PHP 8.1 und ältere Zweige erhalten keine regulären Updates mehr vom PHP-Projekt. Für PHP 7.4, 8.0 und 8.1 wurden zwar minimale Quellcode-Backports bereitgestellt, damit LTS-Anbieter und Organisationen mit eigenen Builds reagieren können. Für normale Installationen bleiben ein bestätigter Hersteller-Backport oder die Migration auf eine unterstützte Version die belastbaren Optionen.

Was hinter den beiden Schwachstellen steckt

Bei CVE-2026-109618 kann die Behandlung eines Speichererschöpfungsfehlers PHP während einer nur teilweise abgeschlossenen Initialisierung unterbrechen. Die anschließende Bereinigung kann ungültige interne Anfragedaten wie gültige Daten behandeln. Das kann zur Ausführung von Code mit den Rechten des Webserver-Prozesses führen.

Der Herstellerhinweis zu CVE-2026-109618 bestätigt eine vollständige Ausnutzung über HTTP gegen Apache mod_php. Der Angriff kann dort bereits während der Verarbeitung einer Anfrage stattfinden, bevor anwendungsspezifischer PHP-Code ausgeführt wird. PHP-FPM und weitere SAPIs gelten ebenfalls als betroffen, auch wenn der konkrete Angriffspfad je nach Betriebsart und Anwendung abweichen kann.

CVE-2026-109619 betrifft internen globalen Zustand, der einen Request überleben kann, obwohl der zugehörige Speicher bereits freigegeben wurde. Eine spätere Anfrage desselben Workers kann diesen veralteten Zustand vor der normalen Neuinitialisierung verwenden. PHP bestätigt dadurch mögliche Speicherinhalte-Offenlegung, Use-after-free und Remote Code Execution.

Der Herstellerhinweis zu CVE-2026-109619 beschreibt bestätigte Angriffspfade gegen mod_php und PHP-FPM. Damit ist die Lücke nicht auf eine einzelne Serverkonfiguration beschränkt.

WordPress- und Shop-Updates reichen nicht

PHP bildet die Laufzeit unter zahlreichen Websites, Shops, Administrationsoberflächen und Geschäftsanwendungen. Dazu gehören Installationen mit WordPress, Drupal, Joomla, Magento, Shopware oder selbst entwickelten Anwendungen.

Ein Update des CMS, Frameworks oder eines Plugins aktualisiert die serverseitige PHP-Laufzeit nicht. Bei selbst betriebenen Servern muss das PHP-Paket oder Container-Image aktualisiert werden. Bei Managed Hosting muss der Anbieter bestätigen, wann und auf welche korrigierte Version die Systeme umgestellt wurden.

Auch Appliances, Control Panels, Windows-Software und Container können eigene PHP-Versionen mitbringen. Eine Prüfung nur der bekannten Website-Server greift deshalb zu kurz.

Jetzt aktualisieren und die wirksame Version prüfen

Internetfähige Systeme sollten zuerst aktualisiert werden. Ein belastbarer Ablauf umfasst:

PHP-Pakete und Container-Images aktualisieren. Die neue Version muss aus einer vertrauenswürdigen Quelle stammen und die jeweilige Sicherheitskorrektur nachweislich enthalten.
Alle PHP-Worker neu starten. PHP-FPM, Webserver, Container und weitere betroffene Dienste dürfen nicht mit bereits geladenem altem Code weiterlaufen.
Die tatsächlich verwendete Laufzeit kontrollieren. Eine aktualisierte Kommandozeile beweist nicht, dass der Webserver dieselbe PHP-Version nutzt. PHP-FPM-Pools, Apache-Module und parallele Installationen müssen separat geprüft werden.
Anwendungsfunktionen testen. Login, Formulare, Datei-Uploads, Hintergrundjobs, Shops und Schnittstellen gehören in einen kurzen Funktions- oder E2E-Test.
Alle Fundstellen aus dem Inventar abhaken. Entwicklungsumgebungen, Appliances, Control Panels, gebündelte Windows-Komponenten und vergessene Altanwendungen dürfen nicht offenbleiben.

Wenn ein sofortiges Update nicht möglich ist

PHP stellt ausdrücklich klar, dass nur das Update vollständig schützt. Konfigurationsänderungen können einzelne bestätigte Angriffspfade erschweren, machen ein System aber nicht sicher.

Für CVE-2026-109618 nennt PHP unter anderem einen administrativ erzwungenen Wert memory_limit=-1, konservative Grenzen für post_max_size und zusätzliche Request-Limits am Webserver oder Reverse Proxy. Weil ein unbegrenztes PHP-Speicherlimit eigene Verfügbarkeitsrisiken erzeugt, sollte eine separate Container- oder cgroup-Grenze den betroffenen Worker begrenzen. Auch diese Kombination ist kein vollständiger Schutz.

Für CVE-2026-109619 kann session.upload_progress.enabled=0 mit anschließendem Neustart aller Worker den bestätigten Session-Angriffspfad blockieren. Bei PHP 8.5 kann zusätzlich fatal_error_backtraces=0 einen weiteren bestätigten Pfad schließen. Andere Varianten bleiben dennoch möglich.

Wenn diese Änderungen notwendig sind, müssen sie in php.ini, der FPM-Pool-Konfiguration oder der Serverkonfiguration vor der Anfrageverarbeitung erzwungen werden. ini_set() innerhalb der Anwendung greift dafür zu spät.

Wo weder Patch noch bestätigter Backport sofort verfügbar sind, sollte die öffentliche Erreichbarkeit so weit wie möglich eingeschränkt werden. Firewall, VPN, Zugriffskontrollen und eine temporäre Abschaltung nicht zwingend benötigter Dienste reduzieren das Risiko, ersetzen das Update aber ebenfalls nicht.

Nach Hinweisen auf eine Kompromittierung suchen

Die PHP-Meldung nennt bislang keine spezifischen Indicators of Compromise und bestätigt keine aktive Ausnutzung. Verhaltensbasierte Überwachung bleibt trotzdem wichtig.

Wenn Prozesse wie php-fpm, php-cgi, httpd oder apache2 unerwartet Shells, Kommandointerpreter oder Download-Werkzeuge starten, ist das ein hochwertiges Untersuchungssignal. Es sollte mit HTTP-Anfragen, Prozessbäumen, Dateiänderungen, neu angelegten Webshells, geplanten Tasks und ausgehenden Netzwerkverbindungen korreliert werden.

Solche Ereignisse beweisen keinen Angriff über diese beiden CVEs. Sie können aber auf eine erfolgreiche Codeausführung über PHP oder eine Webanwendung hinweisen und sollten nicht ignoriert werden.

Der Patch ist jetzt die Priorität

Die Unsicherheit der Vorabmeldung ist beendet: CVE-Nummern, technische Ursachen, betroffene Betriebsarten und korrigierte Versionen sind offiziell dokumentiert. PHP bestätigt für beide Schwachstellen unauthentifizierte Remote Code Execution und bewertet nur das Update als vollständige Lösung.

Betreiber sollten daher nicht auf zusätzliche Exploitberichte warten. Öffentlich erreichbare Systeme gehören jetzt aktualisiert, neu gestartet und auf die tatsächlich geladene PHP-Version kontrolliert.