php2shell: Zwei kritische Schwachstellen zur Remotecodeausführung in PHP ohne Authentifizierung

Zusammenfassung: Das britische National Cyber Security Centre (NCSC) hat am 21. Oktober eine Warnung zu einem kritischen Problem veröffentlicht, das PHP betrifft. Das Problem besteht eigentlich aus zwei getrennten Schwachstellen: Die eine entsteht dadurch, dass eine Anfrage abgebrochen wird, wenn der Speicher nicht ausreicht; die andere dadurch, dass ein Zustand aus einer Anfrage in der nächsten Anfrage im selben Worker-Prozess weiterverwendet wird. Beide können ohne Authentifizierung bis zur Ausführung von Code mit dem Benutzerkonto des Webservers führen. PHP hat mit den Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 eine Korrektur veröffentlicht und erklärt, dass die einzige vollständige Lösung das Update ist. In diesem Artikel habe ich zusammengestellt, was in den offiziellen Mitteilungen steht, wo sich die Risiken häufen, welche vorläufigen Maßnahmen ergriffen werden können, wenn das Update nicht sofort möglich ist, und welche noch nicht bestätigten Behauptungen es gibt – jeweils getrennt.

Was ist php2shell und wen betrifft es?

Kurze Antwort: php2shell ist der gemeinsame Name für zwei kritische Schwachstellen im PHP-Kern (CVE-2026-109618 und CVE-2026-109619). Betroffen sind alle PHP-Installationen, die Webanfragen verarbeiten; das höchste Risiko besteht auf Servern mit Apache mod_php. Die Lösung besteht darin, PHP auf Version 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 zu aktualisieren und alle PHP-Worker neu zu starten.

Frage	Antwort
Schwachstellen	CVE-2026-109618, CVE-2026-109619
Schweregrad	Kritisch, CVSS-4.0-Wert 9,2
Ist eine Authentifizierung erforderlich?	Nein
Datum der Mitteilung	21. Oktober 2026
Korrigierte Versionen	8.2.35, 8.3.36, 8.4.27, 8.5.12
Riskanteste Installation	Apache `mod_php`
Vollständige Lösung	Update; Einstellungsänderungen verringern nur das Risiko

Was ist passiert?

Das PHP-Projekt kündigte am 20. Oktober im Voraus eine kritische Sicherheitsversion an und veröffentlichte am 21. Oktober gleichzeitig in vier Zweigen Sicherheitsversionen. Am selben Tag veröffentlichten das NCSC, das Canadian Centre for Cyber Security und das niederländische NCSC (NCSC-NL) Warnungen. In Sicherheitskreisen werden die beiden Schwachstellen zusammen als php2shell bezeichnet. Diese Bezeichnung wird nicht in der eigenen Mitteilung von PHP verwendet; sie wird im Tracking-Repository des NCSC-NL und von verschiedenen Sicherheitsfirmen verwendet.

Die Warnung des NCSC ist kurz und allgemein gehalten. Sie weist darauf hin, dass jeder Webserver, auf dem PHP läuft, betroffen sein könnte, und fordert Organisationen auf, ihre PHP-Installationen zu finden und zu aktualisieren, beginnend mit den Systemen, die aus dem Internet erreichbar sind. Die Versionsnummern und technischen Details habe ich den Sicherheitsmitteilungen von PHP auf GitHub und von php.net entnommen.

Was machen die beiden Schwachstellen kaputt?

1. CVE-2026-109618: eine Anfrage, die bei unzureichendem Speicher unvollendet bleibt

Wenn eine Anfrage das memory_limit-Limit überschreitet, bricht PHP die Anfrage mit longjmp() ab. Wenn der Abbruch erfolgt, während einige interne Daten der Anfrage noch unvollständig vorbereitet sind, kann die Abschlussphase der Anfrage diese unvollständigen Daten so lesen, als wären sie gültig. Die Folge ist eine Speicherbeschädigung.

Laut der Mitteilung von PHP kann ein Angreifer mit mehrteiligen Formulardaten (multipart/form-data) die Speichernutzung erhöhen, während er scheinbar innerhalb der Grenzen bleibt. Auf Apache mod_php wurde bestätigt, dass mit Standardeinstellungen über HTTP ohne Authentifizierung aus der Ferne Code ausgeführt werden kann. In der Mitteilung heißt es, dass laut Quellcodeanalyse auch PHP-FPM, FrankenPHP und LiteSpeed betroffen sein könnten; für FPM wurde jedoch kein vollständiger Exploit gezeigt.

Die Korrektur entfernt die Verwendung von longjmp() bei unzureichendem Speicher vollständig. An ihre Stelle tritt eine zweistufige Struktur: zuerst eine weiche Grenze, die die Anfrage an einem sicheren Punkt stoppt, und bei einer höheren Schwelle eine harte Grenze, die den Prozess sofort beendet.

2. CVE-2026-109619: alter Zustand, der in die nächste Anfrage übernommen wird

Bei Installationen mit dauerhaften Worker-Prozessen wie PHP-FPM oder mod_php bedient derselbe Prozess nacheinander viele Anfragen. Einige der Fehler-, Sitzungs-, Objekt- und Erweiterungszustände von PHP können auch nach der Freigabe des Speichers der Anfrage im Worker verbleiben. Wenn die nächste Anfrage darauf zugreift, bevor die normale Initialisierung diesen Zustand zurücksetzt, wird freigegebener Speicher wiederverwendet. Diese Fehlerart wird im Englischen als use-after-free bezeichnet.

Für die Ausnutzung sind zwei Schritte im selben Worker erforderlich: eine Anfrage, die den Zustand beschädigt zurücklässt, und ein Vorgang, der ihn später liest. PHP hat zwei Wege bestätigt:

Die Kombination der fatal_error_backtraces-Funktion in PHP 8.5 mit INI-Warnungen, die vor der Initialisierung ausgegeben werden (bestätigt auf mod_php).
Der Weg über den durch Speichermangel beschädigten Fortschritt des Sitzungsladens (session.upload_progress) (bestätigt auf mod_php und PHP-FPM).

Die Auswirkung der Schwachstelle ist das Auslaufen von Speicherinhalten und die Ausführung von Code mit den Rechten des Web-Workers.

3. Schweregrad

	CVE-2026-109618	CVE-2026-109619
Englischer Titel in der Mitteilung	RCE via OOM corruption	RCE via stale global state
Schweregrad	Kritisch, CVSS-4.0-Wert 9,2	Kritisch, CVSS-4.0-Wert 9,2
Authentifizierung	Nicht erforderlich	Nicht erforderlich
Angriffskomplexität	Hoch, Voraussetzung vorhanden	Hoch, Voraussetzung vorhanden
Bestätigte Umgebung	Apache `mod_php`	Apache `mod_php`, PHP-FPM

Der Vektor ist bei beiden gleich: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Dass die Komplexität „hoch“ ist, bedeutet nicht, dass die Schwachstelle nicht ausgenutzt werden kann; es zeigt, dass der Erfolg der Ausnutzung von Kompilierungsoptionen, Erweiterungen und der Speicheranordnung abhängt.

Welche Versionen sind betroffen?

Zweig	Betroffen	Behobene Version	Hinweis
8.5	vor 8.5.12	8.5.12
8.4	vor 8.4.27	8.4.27
8.3	vor 8.3.36	8.3.36
8.2	vor 8.2.35	8.2.35	Der Support endet am 31. Dezember 2026
8.1, 8.0, 7.4	Betroffen	Keine offizielle Version	PHP hat nur minimale Patches für diejenigen veröffentlicht, die aus dem Quellcode kompilieren

Alle Installationen, die Webanfragen über PHP verarbeiten, sind betroffen: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Das Risiko ist bei Installationen mit mod_php am höchsten, denn der gezeigte Exploit wird während der Verarbeitung der Anfrage ausgelöst, ohne dass Anwendungscode ausgeführt wird. Ob die Website also WordPress, Laravel oder eine handgeschriebene Anwendung ist, macht allein keinen Unterschied.

Die vierte Release-Candidate-Version (RC4) der Testversion 8.6.0 enthält die Korrekturen, ist aber nicht für den Produktiveinsatz gedacht. Distributionen und Firmen mit Langzeit-Support haben die Patches vorab erhalten; einige wie AlmaLinux haben noch am selben Tag Pakete veröffentlicht. PHP hat außerdem angekündigt, dass das Repository rpms.remirepo.net am 21. Oktober keine aktuellen Pakete bereitstellen kann.

1. Wie finde ich heraus, was ich auf meinem eigenen Server verwende?

Die Version auf der Kommandozeile und die vom Webserver verwendete Version können unterschiedlich sein. Zuerst müssen beide geprüft werden:

# Komut satırı sürümü
php -v

# PHP-FPM kuruluysa (paket adı dağıtıma göre değişir, ör. php8.3-fpm)
php-fpm8.3 -v

# Debian/Ubuntu: yüklü PHP paketleri ve sürümleri
dpkg -l | grep -E '^ii\s+(php|libapache2-mod-php)'

# RHEL/AlmaLinux/Rocky
rpm -qa | grep -E '^php'

Um zu sehen, mit welcher Server-Schnittstelle (SAPI) PHP auf der Webseite läuft, kann man in der Ausgabe von phpinfo() die Zeile Server API ansehen; steht dort „Apache 2.0 Handler“, wird mod_php verwendet. Diese Seite muss man vorübergehend öffnen und nach getaner Arbeit löschen.

Wer Shared Hosting nutzt, sieht die Version meist im Panel, und die Aktualisierung übernimmt der Hosting-Anbieter. Zu prüfen, ob der Anbieter eine Erklärung abgegeben hat, und gegebenenfalls nachzufragen, ist in diesem Fall der richtige Schritt.

2. Aktualisierung

Die einzige vollständige Lösung ist die Aktualisierung. Wer Distributionspakete verwendet, richtet sich nach der Version in der Sicherheitsmeldung der Distribution; wer aus dem Quellcode kompiliert, nach der Version in der obigen Tabelle. Nach der Aktualisierung müssen alle PHP-Worker neu gestartet werden; das bloße Installieren des Pakets ändert die laufenden Prozesse nicht:

# Örnek: Debian/Ubuntu, PHP-FPM ve Apache
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

Das NCSC weist insbesondere darauf hin: Netzwerkgeräte, Verwaltungsoberflächen, fertige Anwendungen und Container-Images, die PHP in sich tragen, werden nicht über den Paketmanager des Servers aktualisiert. Für diese muss man auf den Patch des Herstellers warten. Das NCSC-NL führt auf GitHub eine Liste der möglicherweise betroffenen Produkte.

3. Wenn das Update nicht sofort möglich ist

Die von PHP empfohlenen vorübergehenden Maßnahmen stehen unten. Nach eigener Aussage von PHP verengen diese bestimmte Angriffswege, machen die Installation aber nicht sicher. Die Einstellungen müssen in php.ini, im FPM-Pool oder in der Serverkonfiguration gesetzt und anschließend alle Worker neu gestartet werden; Einstellungen über ini_set() oder .user.ini sollte man nicht vertrauen.

Für CVE-2026-109619:

; Oturum yükleme ilerlemesi gerekmiyorsa kapalı tutulmalı (yamadan sonra da)
session.upload_progress.enabled = 0

; Yalnızca PHP 8.5
fatal_error_backtraces = 0

Außerdem sollten ungültige oder veraltete Einstellungen, die pro Anfrage gesetzt werden und beim Start eine Warnung erzeugen (etwa php_value-Zeilen in .htaccess), bereinigt werden. Die Warnung mit error_reporting, display_errors oder @ zu verbergen, hilft nicht.

Für CVE-2026-109618:

; Dosya yükleme gerekmiyorsa 8M, gerekiyorsa 32M
post_max_size = 8M
; upload_max_filesize, post_max_size değerinden küçük kalmalı
upload_max_filesize = 6M

PHP empfiehlt außerdem memory_limit=-1 als teilweise Maßnahme. Da diese Einstellung das Speicherlimit aufhebt, muss der Server auf einem anderen Weg geschützt werden, etwa durch ein Container- oder cgroup-Limit memory.max. RLIMIT_AS und RLIMIT_DATA sollten nicht verwendet werden; diese können genau zu dem Speicherzuweisungsfehler führen, der die Schwachstelle auslöst. Auf der Ebene des Webservers oder des Reverse-Proxys sollten Limits für die Anfragegröße, die Anzahl der Felder, die Anzahl der Teile von Multipart-Formularen und die Anzahl der Header gesetzt werden. Wenn die Anwendung keine Multipart-Formulare verwendet, können diese Anfragen in der vorgelagerten Ebene blockiert werden.

Das NCSC empfiehlt, falls nichts davon möglich ist, das System bis zum Patchen offline zu nehmen. Bei Systemen, bei denen der Patch verzögert werden muss, gehört zu den Empfehlungen auch, die Webserver-Logs, unerwartete Prozesse, Dateien und ausgehende Verbindungen zu prüfen.

Unbestätigte Behauptungen

Was in diesem Abschnitt steht, findet sich nicht in offiziellen Mitteilungen oder widerspricht sich:

Aktive Ausnutzung: watchTowr schreibt, in seinem eigenen Honeypot-Netzwerk bis zum 21. Oktober eine Ausnutzung gesehen zu haben. Auch Patchstack und Aikido meldeten eine Ausnutzung; laut einer Notiz von SOCRadar veröffentlichten beide jedoch keine technischen Details. Datadog berichtet unter Berufung auf AWS, dass Ausnutzungsversuche vier Tage vor der öffentlichen Bekanntgabe der Schwachstellen am 17. Oktober begannen; Sansec wiederum schreibt unter Berufung auf einen Social-Media-Beitrag, Cloudflare habe am Morgen des 21. Oktober, bevor die Korrekturen erschienen, Angriffe gesehen. Nichts davon konnte ich aus erster Hand bestätigen. Andererseits erklärt das Canadian Centre for Cyber Security am selben Tag, keine aktive Ausnutzung festgestellt zu haben, die Lage könne sich aber schnell ändern; auch Rapid7 meldet keine bestätigte Ausnutzung, sondern schreibt, sie werde erwartet. Laut SOCRadar standen die beiden Schwachstellen zum 21. Oktober nicht im Katalog der ausgenutzten Schwachstellen (KEV) der CISA.
Öffentlicher Proof of Concept (PoC): Das Canadian Centre for Cyber Security schreibt, öffentlichen Berichten zufolge existiere ein Proof of Concept. Auf GitHub gibt es unter diesem Namen veröffentlichte Repositories; ob sie funktionieren, habe ich nicht ausprobiert, und ich verlinke sie nicht.
Reichweite bis PHP 5: Einige Artikel behaupten, die Schwachstellen beträfen alle Versionen ab PHP 5. PHP gibt in seiner Ankündigung an, Mindest-Patches für 7.4, 8.0 und 8.1 veröffentlicht zu haben; zu älteren Versionen schreibt es nichts Eindeutiges. Auch die Formulierung des NCSC „jede Version von PHP“ lässt sich in diese Richtung lesen, nennt aber keinen Versionsbereich.

Häufig gestellte Fragen

Bin ich betroffen, wenn meine Website WordPress ist?

Wahrscheinlich ja. Die Schwachstellen liegen nicht in WordPress, sondern in PHP selbst. Unabhängig davon, mit welcher Anwendung die Website erstellt wurde, besteht ein Risiko, wenn die PHP-Version auf dem Server älter als die korrigierten Versionen ist. Ein Update von Plugins oder Themes löst dieses Problem nicht.

Was sollte ich bei Shared Hosting tun?

Der PHP-Hoster aktualisiert. Es genügt, im Panel die PHP-Version zu prüfen, zu kontrollieren, ob der Anbieter eine Stellungnahme zu php2shell abgegeben hat, und andernfalls nachzufragen. Wenn das Panel es erlaubt, ist der Wechsel zum neuesten unterstützten PHP-Zweig ebenfalls ein guter Schritt.

Ich verwende PHP nur auf der Kommandozeile, besteht ein Risiko?

Die offiziellen Ankündigungen richten sich an Installationen, die Webanfragen verarbeiten; die Nutzung auf der Kommandozeile (CLI) wird nicht gesondert erwähnt. Läuft auf derselben Maschine jedoch auch ein Webserver, sollte die Aktualisierung nicht aufgeschoben werden.

Reichen vorübergehende Einstellungen aus?

Nein. PHP schreibt ausdrücklich, dass Einstellungen wie session.upload_progress.enabled=0, fatal_error_backtraces=0 und memory_limit bestimmte Angriffswege einschränken, die Installation aber nicht sicher machen.

Ich verwende PHP 8.1 oder älter, was passiert?

Das PHP-Projekt veröffentlicht für diese Zweige keine neuen Versionen. Für diejenigen, die aus dem Quellcode kompilieren, wurden minimale Patches für 7.4, 8.0 und 8.1 veröffentlicht; Distributionen und Anbieter mit Langzeitunterstützung können ebenfalls eigene Patches bereitstellen. Die dauerhafte Lösung ist der Wechsel zu einem unterstützten Zweig.

Meine Einschätzung

Sicher ist: Es gibt zwei separate, kritische Schwachstellen, die keine Authentifizierung erfordern; die Korrekturen kamen mit 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Am stärksten gefährdet sind Installationen mit Apache mod_php.
Konfiguration allein ist keine Lösung: PHP schreibt ausdrücklich, dass keine der vorübergehenden Maßnahmen die Installation sicher macht. Einstellungen zu ändern und die Aktualisierung aufzuschieben, verringert das Risiko nur.
Die eigentliche Last liegt außerhalb des Servers: Den eigenen Server zu aktualisieren ist relativ einfach. Schwierig sind Geräte, Panels und Container-Images, die PHP in sich tragen; wann diese gepatcht werden, hängt vom Hersteller ab.
Versionen ohne Support: Systeme, die bei 8.1 und älter bleiben, erhielten diesmal keine offizielle Version. Bedenkt man, dass auch 8.2 am 31. Dezember 2026 aus dem Support fällt, erscheint es sinnvoll, die Aktualisierung zusammen mit dem Wechsel zum nächsten Zweig zu planen.
Vorsicht bei Ausnutzungsmeldungen: Behauptungen über aktive Ausnutzung stammen von einigen Sicherheitsfirmen, wurden aber von offiziellen Stellen noch nicht bestätigt. Ich betrachte sie nicht als gesichert; sehe sie aber auch nicht als Grund, mit der Aktualisierung zu warten. Sollten neue offizielle Informationen eintreffen, werde ich den Artikel aktualisieren.

Quellen

Offizielle Ankündigungen

Einschätzungen von Sicherheitsfirmen