PHP2Shell: die zwei kritischen PHP-Lücken vom 21. Oktober 2026 erklärt

Am 21. Oktober 2026 hat das PHP-Team vier Notfall-Versionen veröffentlicht: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie schließen zwei Lücken in der Engine selbst, genannt PHP2Shell, bewertet mit 9,2 von 10 (CVSS v4). Ein Angreifer ohne Konto kann damit Code auf dem Server ausführen, mit den Rechten des Webprozesses, und zwar manchmal noch bevor der Code der Website läuft.

Die Lücke steckt weder in WordPress noch in einem Plugin, sondern in PHP. Jede Website mit PHP ist betroffen, egal welche Software sie nutzt (WordPress, Drupal, Joomla, PrestaShop, Eigenentwicklung).

	CVE-2026-109618	CVE-2026-109619
Art	Speicherbeschädigung, wenn PHP der Speicher ausgeht	Freigegebener Speicher wird von Anfrage zu Anfrage weiterverwendet
Auslöser	Eine präparierte Formular-Anfrage (Multipart)	Ein fataler Fehler oder Timeout, der das Aufräumen unterbricht
Bestätigte Übernahme	Apache mit mod_php, Standardeinstellungen	mod_php, und PHP-FPM über den Upload-Fortschritt

CVE-2026-109618: Speichermangel im falschen Moment

PHP begrenzt den Speicher jeder Anfrage (memory_limit, standardmäßig 128 MB). Überschreitet eine Speicheranforderung diese Grenze, löst PHP einen fatalen Fehler aus und verlässt die laufende Funktion mit longjmp(): ein Sprung, der die Arbeit genau dort abbricht, wo sie gerade steht, ohne sie zu beenden.

Das Problem ist die Reihenfolge. An manchen Stellen erklärt PHP Daten für bereit, bevor sie vollständig angelegt sind. Die Analyse von Datadog nennt ein Beispiel: Beim Einfügen in eine Hashtabelle, die Struktur hinter $_POST, erhöht PHP zuerst den Elementzähler und reserviert erst danach den Schlüssel. Scheitert diese Reservierung, zählt die Tabelle einen Eintrag, dessen Inhalt das ist, was zufällig im Speicher lag.

Am Ende der Anfrage zerstört PHP $_POST und durchläuft alle gezählten Einträge. Es liest diese Bytes also als PHP-Werte. Konnte der Angreifer dort gewählte Bytes platzieren, führt die Bereinigung seinen Code aus.

Der Speichermangel ist nicht das Ziel, sondern das Mittel, eine halb aufgebaute Struktur zu hinterlassen.

Bleibt, den Speicher zu erschöpfen, ohne PHPs Größengrenzen zu überschreiten. Der offizielle Sicherheitshinweis beschreibt, wie eine Multipart-Anfrage (ein Formular mit Datei-Upload) das schafft:

• ohne verwertbare Längenangabe passiert die Anfrage die erste Prüfung von post_max_size;
• jeder Teil darf beliebig viele Header tragen, die in PHP weit mehr Speicher kosten als auf der Leitung;
• leere Dateifelder zählen nicht zu max_file_uploads, erzeugen aber trotzdem Metadaten-Arrays;
• verschachtelte Namen (a[b][c]…) vervielfachen diesen Aufwand.

Warum mod_php am stärksten gefährdet ist. Mit Apache und mod_php liest PHP den Inhalt der Anfrage gleich beim Start und führt die abschließende Bereinigung auch dann aus, wenn dieser Start scheitert. Der Angriff gelingt also vor jedem Anwendungscode, mit den Standardgrenzen. PHP-FPM beendet den Prozess, wenn der Start scheitert: Ein vollständiger Angriff wurde nicht gezeigt, doch die Lücke bleibt erreichbar, wenn die Anwendung selbst später einen Speichermangel verursacht.

CVE-2026-109619: ein vergessener Zeiger zwischen zwei Anfragen

Ein PHP-Prozess (ein „Worker“) bedient viele Anfragen nacheinander. Einige globale Variablen des Prozesses zeigen auf Speicher, der zur aktuellen Anfrage gehört. Am Ende der Anfrage wird dieser Speicher freigegeben; wird die Variable nicht zurückgesetzt, liest die nächste Anfrage einen bereits freigegebenen und womöglich neu belegten Bereich. Das ist ein Use-after-free.

Das passiert, wenn ein fataler Fehler oder ein Timeout das Zurücksetzen unterbricht. Zwei Wege sind bestätigt:

Weg	Betroffene Einstellung	Wo der Angriff bestätigt ist
Fortschrittsanzeige für Datei-Uploads	session.upload_progress.enabled, standardmäßig aktiv	mod_php und PHP-FPM
Backtraces fataler Fehler	fatal_error_backtraces (PHP 8.5)	mod_php

Die Anfragen des Angreifers müssen beim selben Worker landen. Ein Server mit vielen Workern erfordert mehr Versuche: Ein Schutz ist das nicht.

Was die Korrektur ändert

• Kein longjmp() mehr bei Speichermangel. Eine „weiche“ Grenze meldet den Fehler am nächsten sicheren Punkt der Ausführung; eine höhere „harte“ Grenze beendet den Prozess sofort, ohne riskante Bereinigung.
• Zustand, der eine Anfrage überlebt (Fehler-Backtraces, Session, Fehlerzustand, OPcache), wird am Ende jeder Anfrage zurückgesetzt.

Wer betroffen ist, und welche Version nötig ist

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.1, 8.0, 7.4	keine neue Version: minimale Korrekturen als Quellcode, für Distributionen

Alle Betriebsarten, die Seiten ausliefern, sind betroffen: Apache mit mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed. Red Hat stuft das Risiko etwas niedriger ein, weil der Angriff einen sehr genauen Speichermangel voraussetzt. Während der Untersuchung wurde ein funktionierender Exploit gebaut, die Information wurde einen Tag vor der Veröffentlichung bekannt, und Forscher melden Angriffsversuche. Vorsicht auch vor gefälschtem Exploit-Code auf GitHub: nicht ausführen.

Was jetzt zu tun ist

1. Aktualisieren auf die korrigierte Version Ihres Zweigs, danach alle PHP-Prozesse neu starten (Apache, PHP-FPM) und Docker-Images neu bauen. Nur das schützt vollständig.

2. Die Version prüfen, die die Website tatsächlich nutzt, nicht die der Kommandozeile, die abweichen kann. Beim Shared Hosting wählt man die Version im Kundenbereich des Hosters: Prüfen Sie, dass sie die korrigierte Nummer trägt.

3. Wenn das Update warten muss, diese Einstellungen in php.ini oder der Pool-Konfiguration setzen und die Prozesse neu starten (ini_set() und .user.ini greifen zu spät):

   • session.upload_progress.enabled = 0;
   • fatal_error_backtraces = 0 unter PHP 8.5;
   • memory_limit = -1, vom Administrator erzwungen, zusammen mit einer Größengrenze für Anfragen am Webserver oder Proxy: Ohne sie ist der Server nicht mehr gegen Speichererschöpfung geschützt;
   • Multipart-Anfragen am Proxy sperren, wenn die Website keine Datei-Uploads annimmt.

   Diese Maßnahmen sind unvollständig: Sie schließen die bekannten Wege, nicht die Ursache.

4. Überwachen: Speicherfehler ganz am Anfang einer Anfrage („Allowed memory size exhausted“, „Unknown on line 0“), Formulare mit riesigen Feldnamen (mehrere Megabyte), abstürzende PHP-Prozesse und vor allem ein Webprozess, der eine Shell startet. Ein erfolgreicher Angriff kann normal antworten (Status 200), ohne dass etwas abstürzt.

Und Websites ohne PHP?

Eine statische Website oder eine Anwendung in Node.js oder Python ist von diesen zwei Lücken nicht betroffen: Sie stecken in der PHP-Engine. Jede Plattform hat ihre eigenen. Was wirklich schützt, ist eine Version, die von ihren Entwicklern noch gepflegt wird, und Updates, die in den Tagen nach ihrer Veröffentlichung eingespielt werden.

Quellen: offizieller PHP-Sicherheitshinweis (GHSA-w8hw-w9fx-j79w), Rapid7, Datadog Security Labs, JFrog und Red Hat, abgerufen am 22. Oktober 2026.