php2shell: Kritische Sicherheitslücken in PHP – was jetzt zu tun ist

Kurz gesagt: Aktualisieren Sie PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. auf die gepatchten Pakete Ihres Distributors, und starten Sie danach alle PHP-Prozesse neu. Konfigurationsänderungen verringern das Risiko nur für einzelne Angriffswege. Prüfen Sie außerdem Appliances und eingekaufte Produkte, die PHP mitbringen. Stand der Angaben: 26. Oktober 2026 – wir aktualisieren den Beitrag, sobald sich die Lage ändert.

Was ist php2shell?

php2shell (auch PHP2Shell) ist der Sammelname für zwei Schwachstellen in der Laufzeitumgebung von PHP selbst, nicht in einer bestimmten Anwendung: CVE-2026-109618 und CVE-2026-109619. Das PHP-Projekt hat beide CVE-Einträge am 21. Oktober 2026 veröffentlicht und nach CVSS 4.0 mit 9,2 von 10 Punkten als kritisch eingestuft (CVE-2026-109618, CVE-2026-109619). Beide können zu einer Remote Code Execution führen: Ein Angreifer führt über das Netz eigenen Code auf dem Server aus, ohne sich anzumelden – mit den Rechten des Webserver-Prozesses.

Gemeldet wurden die Lücken laut den CVE-Einträgen von Wiz, Calif.io und OpenAI. Wiz Research beschreibt, dass KI-Modelle entscheidend dazu beitrugen, die seit mehr als einem Jahrzehnt im Code vorhandenen Fehler zu finden und in funktionierende Exploits zu überführen. Nach Angaben von Wiz ist jede PHP-Version der letzten zehn Jahre, zurück bis PHP 5.4, von mindestens einer der Lücken betroffen (Wiz Research, 21.10.2026).

Der zeitliche Ablauf:

• 20. Oktober 2026: Das PHP-Projekt kündigt eine Sicherheitsversion für zwei kritische Schwachstellen an.
• 21. Oktober 2026, 13:30 Uhr UTC: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erscheinen, zusammen mit einer Sicherheitswarnung und zwei ausführlichen Advisories (PHP-Sicherheitswarnung vom 21.10.2026).
• 23. Oktober 2026: PHP rät in einem Zusatzhinweis, die Funktion session.upload_progress bis zum nächsten regulären Bugfix-Release abzuschalten, um sich vor einem weiteren, als unwahrscheinlich eingestuften Angriffsweg zu schützen (PHP-Hinweis vom 23.10.2026). CERT-EU führt diese dritte Lücke als CVE-2026-115560 (CERT-EU Security Advisory 2026-018). Ein öffentlicher CVE-Eintrag dazu lag am 26. Oktober 2026 noch nicht vor.

Welche Versionen und Systeme sind betroffen?

Laut PHP sind alle Installationen gefährdet, die Webanfragen verarbeiten – ob über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Die Korrekturen enthalten diese Versionen:

• PHP 8.5: ab 8.5.12
• PHP 8.4: ab 8.4.27
• PHP 8.3: ab 8.3.36
• PHP 8.2: ab 8.2.35
• PHP 8.6 (Vorabversion): ab 8.6.0 RC4 – nicht für den Produktivbetrieb gedacht
• PHP 8.1 und älter: keine Updates mehr vom PHP-Projekt. Einige Distributionen und Anbieter von Langzeit-Support liefern zurückportierte Korrekturen. Für PHP 7.4, 8.0 und 8.1 hat das PHP-Sicherheitsteam ausnahmsweise minimale Quellcode-Backports bereitgestellt.

Die Linux-Distributionen haben die Patches vorab erhalten. Ein Paket kann deshalb auch mit einer älteren Versionsnummer bereits abgesichert sein; maßgeblich ist der Sicherheitshinweis Ihres Distributors (PHP-Sicherheitswarnung).

Wie gefährdet ein System ist, hängt von der Betriebsart ab:

• Apache mit mod_php: höchstes Risiko. Der nachgewiesene Angriff funktioniert mit einer nicht authentifizierten Anfrage, noch bevor Anwendungscode läuft.
• PHP-FPM: Für CVE-2026-109619 ist ein Angriffsweg über die Funktion Session-Upload-Progress bestätigt, der allerdings eine geeignete Stelle in der Anwendung voraussetzt. Für CVE-2026-109618 hält PHP FPM nach Quellcodeanalyse für anfällig; einen vollständigen Exploit nennt das Advisory nicht.
• FrankenPHP: laut Advisory vermutlich anfällig für Angriffe, die von der Anwendung unabhängig sind.
• LiteSpeed (LSAPI): Angriffe sind abhängig von der jeweiligen Anwendung wahrscheinlich, aber nicht nachgewiesen.

Die Einordnung stammt aus den beiden Advisories des PHP-Projekts (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).

Zwei Punkte werden leicht übersehen. Erstens genügt es nicht, WordPress, Drupal, Joomla oder eine andere Anwendung zu aktualisieren, denn die Lücke steckt in der darunterliegenden PHP-Laufzeit (CIRCL TR-102). Zweitens steckt PHP auch in Appliances, Netzwerkgeräten, Verwaltungsoberflächen und anderen Herstellerprodukten, in denen Sie PHP nicht selbst aktualisieren können. So meldet Siemens die Plattform RUGGEDCOM APE1808 als betroffen (Siemens-Eintrag im CVE-Datensatz). Das niederländische NCSC pflegt eine laufend aktualisierte Liste betroffener und nicht betroffener Produkte (NCSC-NL php2shell).

So funktionieren die Schwachstellen

Beide Lücken entstehen dort, wo PHP eine Anfrage wegen eines schweren Fehlers abbricht – vor allem dann, wenn der zulässige Arbeitsspeicher (memory_limit) ausgeschöpft ist.

CVE-2026-109618 – Speicherbeschädigung beim Abbruch wegen Speichermangels: PHP verlässt bei einem Out-of-Memory-Fehler den laufenden Ablauf per longjmp(). Geschieht das, während interne Anfragedaten erst teilweise initialisiert sind, behandelt die anschließende Aufräumroutine ungültige Daten als gültig. Den Speichermangel kann ein Angreifer laut Advisory gezielt mit präparierten Multipart-Anfragen auslösen, also mit manipulierten Formular-Uploads: etwa ohne verwertbare Längenangabe, mit sehr vielen Headern pro Teil oder mit verschachtelten, leeren Datei-Feldern. Bei mod_php geschieht das vollständig, bevor die Anwendung überhaupt startet (GHSA-w8hw-w9fx-j79w).

CVE-2026-109619 – veralteter globaler Zustand: Ein PHP-Worker hält globale Zustände, etwa zu Fehlern, Sessions oder Erweiterungen, die auf den Speicher einer einzelnen Anfrage zeigen. Bricht eine Anfrage ab, werden sie nicht immer zurückgesetzt. Eine spätere Anfrage an denselben Worker kann den bereits freigegebenen Speicher dann weiterverwenden (Use-after-free). Bestätigt sind ein Weg über die standardmäßig aktive Funktion session.upload_progress – ein Aufruf von session_start() in der Anwendung ist dafür nicht nötig – sowie unter PHP 8.5 ein Weg über die Einstellung fatal_error_backtraces (GHSA-6wmf-4rv5-p3rp).

Wiz hat die Lücken nach eigenen Angaben zu einem Exploit verkettet und damit ohne Anmeldung Code auf den damals aktuellen Container-Images von WordPress, Drupal und Joomla ausgeführt. Zusätzlich ließ sich Speicher des PHP-Prozesses auslesen, der Passwörter, Tokens, API-Schlüssel oder Zertifikate anderer Anfragen enthalten kann; Wiz vergleicht das mit Heartbleed (Wiz Research). Für die Nachsorge ist das wichtig: Ein ungepatchter Server kann Geheimnisse preisgegeben haben, auch ohne dass Code ausgeführt wurde.

Wird php2shell bereits ausgenutzt?

Die US-Behörde CISA bewertete am 21. Oktober 2026 in ihrer Einordnung zum CVE-Datensatz, dass keine Ausnutzung bekannt sei. Im Katalog der aktiv ausgenutzten Schwachstellen (KEV) war php2shell mit Stand vom 23. Oktober 2026 nicht gelistet (CISA KEV). Gleichzeitig weist CERT-EU darauf hin, dass technische Details öffentlich diskutiert werden und erste Proof-of-Concept-Exploits kursieren. Das erhöhe die Wahrscheinlichkeit, dass Angreifer die Lücken bereits nutzen (CERT-EU). Inzwischen sind zahlreiche Exploit- und Scanner-Projekte öffentlich verfügbar (eigene Recherche, Stand 26. Oktober 2026). Gehen Sie deshalb davon aus, dass aus dem Internet erreichbare PHP-Server gezielt gesucht und angegriffen werden.

Sofortmaßnahmen: Updates zuerst

Das PHP-Projekt und CERT-EU sind sich einig: Nur ein Update schließt die Lücken vollständig. Gehen Sie in dieser Reihenfolge vor:

1. Bestand erfassen: Ermitteln Sie alle PHP-Laufzeiten – auf eigenen Servern, in Containern und Images, bei Hostern und in Produkten von Drittanbietern. Beginnen Sie mit Systemen, die aus dem Internet erreichbar sind. Die Version zeigt php -v auf der Kommandozeile. Der Header X-Powered-By verrät sie nur, wenn er nicht ausgeblendet ist, und sagt nichts über zurückportierte Patches aus.
2. Aktualisieren: Installieren Sie PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. die gepatchten Pakete Ihrer Distribution. Starten Sie anschließend alle PHP-Worker neu, also PHP-FPM-Pools und Apache – erst dann läuft der korrigierte Code.
3. Hoster und Hersteller fragen: Bei Shared Hosting, verwalteten Servern und Appliances liegt das Update beim Anbieter. Fragen Sie nach, ob und wann die Systeme gepatcht werden, und verfolgen Sie die Herstellerhinweise, etwa über die Übersicht des NCSC-NL.
4. Veraltete Versionen ablösen: PHP 8.1 und älter erhalten vom PHP-Projekt keine Updates mehr. Steigen Sie auf einen unterstützten Zweig um, oder nutzen Sie einen geprüften Backport Ihres Distributors oder LTS-Anbieters.
5. Isolieren, wenn Patchen nicht möglich ist: CERT-EU empfiehlt, betroffene Anwendungen notfalls vom Internet zu trennen, bis das Update eingespielt und geprüft ist.

Können Sie nicht sofort aktualisieren, verringern diese Übergangsmaßnahmen das Risiko für bestimmte Angriffswege. Eine Installation machen sie ausdrücklich nicht sicher (PHP-Sicherheitswarnung):

• Session-Upload-Progress abschalten: session.upload_progress.enabled=0 in der php.ini, im FPM-Pool oder in der Serverkonfiguration setzen und alle Worker neu starten – nicht per ini_set() oder .user.ini. Das blockiert die bestätigten Session-Wege und laut Hinweis vom 23. Oktober auch den dritten Angriffsweg. Wer die selten genutzte Funktion nicht braucht, lässt sie laut Advisory am besten auch nach dem Update abgeschaltet.
• Speichergrenze entfernen: memory_limit=-1 so setzen, dass Anwendungen es nicht überschreiben können, etwa per php_admin_value. Das nimmt dem bestätigten Exploit die steuerbare Speichergrenze. Ohne Grenze kann ein einzelner Prozess allerdings beliebig viel Speicher belegen. Begrenzen Sie ihn deshalb über Container oder cgroups, möglichst so, dass nur der betroffene Worker beendet wird. RLIMIT_AS oder RLIMIT_DATA sind kein Ersatz, denn sie lösen den verwundbaren Pfad gerade aus.
• Anfragen begrenzen: post_max_size niedrig halten – 8M für Anwendungen ohne Datei-Upload, 32M mit Upload –, upload_max_filesize bleibt darunter. Begrenzen Sie zusätzlich am Webserver oder Proxy Anfragegröße, Anzahl der Felder, Multipart-Teile, Header und Verschachtelungstiefe, auch für Anfragen ohne Content-Length. Nutzt eine Anwendung keine Multipart-Formulare, blockieren Sie diese vor PHP.
• PHP 8.5: fatal_error_backtraces=0 setzen und alle Worker neu starten.
• Warnungen vor dem Start vermeiden: Ungültige oder veraltete INI-Einstellungen entfernen, die pro Anfrage gesetzt werden und Warnungen erzeugen, etwa per php_value in einer .htaccess. Warnungen mit error_reporting, display_errors oder @ auszublenden, hilft nicht.
• Fehlerquellen schließen: Fatale Fehler und Zeitüberschreitungen beheben, die ein Angreifer gezielt auslösen kann – auch in Upload-, Import- und Aufräumroutinen.

Mehrere Anbieter, darunter Cloudflare, Fastly und Google Cloud, haben für ihre Kunden Schutzmaßnahmen und Hinweise vorbereitet (Wiz Research). Eine Web Application Firewall verschafft Zeit, ersetzt das Update aber nicht.

Anzeichen eines Angriffs erkennen

Die Angriffe laufen unterhalb der Anwendung ab, Anwendungslogs enthalten deshalb oft wenig. Wiz nennt als Hinweise, denen Sie nachgehen sollten:

• ungewöhnliche Multipart-Anfragen, auf die Fehler wegen Speicherüberschreitung oder wiederholte HTTP-500-Antworten folgen
• unerwartet große oder fehlerhafte PHPSESSID-Cookies in Serverantworten
• PHP-Worker, die ohne erkennbaren Grund häufig neu gestartet werden

Für eine gezielte Prüfung empfiehlt das PHP-Projekt, in einer isolierten Umgebung log_errors=On, ein funktionierendes error_log und error_reporting=E_ALL zu aktivieren. Die Logs von Apache, PHP-FPM und Reverse Proxy durchsuchen Sie dann auf wiederholte Warnungen, fatale Fehler und Maximum execution time exceeded. Fehlende Einträge beweisen allerdings nicht, dass kein Angriff stattfand (GHSA-6wmf-4rv5-p3rp).

Lief ein aus dem Internet erreichbarer Server vor dem Update mit einer betroffenen Version, prüfen Sie nach dem Patchen, ob Zugangsdaten, Tokens und Schlüssel, die der Server verarbeitet, erneuert werden müssen – wegen der möglichen Speicherauslese auch ohne Hinweis auf Codeausführung. Bei konkretem Verdacht klärt ein Compromise Assessment, ob Angreifer Spuren wie Webshells oder neue Konten hinterlassen haben. Ist ein Angriff bereits erkennbar, melden Sie den Notfall direkt bei unserem Team.

Sie wissen nicht genau, wo in Ihrer Umgebung PHP läuft? Eine Schwachstellenanalyse erfasst Ihre aus dem Internet erreichbaren Systeme samt Versionen und priorisiert die Funde. Ob Ihre Webanwendungen über php2shell hinaus angreifbar sind, zeigt ein Penetrationstest für Webanwendungen.

Checkliste: php2shell abarbeiten

• Alle PHP-Laufzeiten sind erfasst, auch in Containern, bei Hostern und in Appliances
• Systeme mit Internetzugang laufen mit PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder einem bestätigten Backport
• Alle PHP-Worker wurden nach dem Update neu gestartet
• Systeme mit PHP 8.1 und älter sind abgelöst oder durch einen gepflegten Backport abgesichert
• session.upload_progress.enabled=0 ist gesetzt, solange die Funktion nicht gebraucht wird
• Hinweise von Herstellern und Hostern zu eingesetzten Produkten sind geprüft
• Logs wurden auf die genannten Auffälligkeiten durchgesehen
• Zugangsdaten und Schlüssel exponierter Systeme sind bewertet und bei Bedarf erneuert

Fazit: Patchen, neu starten, nachsehen

php2shell betrifft nicht eine einzelne Anwendung, sondern die Plattform, auf der ein großer Teil des Webs läuft – laut Wiz rund 70 Prozent aller Websites. Entscheidend ist jetzt, die PHP-Laufzeit überall dort zu aktualisieren, wo sie Anfragen aus dem Netz verarbeitet, alle Worker neu zu starten und Systeme, die Sie nicht selbst patchen können, beim Hersteller nachzuverfolgen. Übergangsmaßnahmen helfen nur gegen einzelne Angriffswege. Wer ungepatchte Server im Internet betrieben hat, sollte sie anschließend auf Spuren prüfen und Geheimnisse erneuern.

Quellen

Alle Quellen abgerufen am 26. Oktober 2026.

• PHP-Projekt: Security advisory: Critical remote code execution vulnerabilities, update now, 21.10.2026
• PHP-Projekt: Informational advisory: Session upload progress, 23.10.2026
• PHP-Projekt: GHSA-w8hw-w9fx-j79w – RCE via OOM corruption (CVE-2026-109618), 21.10.2026
• PHP-Projekt: GHSA-6wmf-4rv5-p3rp – RCE via stale global state (CVE-2026-109619), 21.10.2026
• CVE-Programm: CVE-2026-109618 und CVE-2026-109619, mit Einordnung der CISA und Herstellereinträgen
• CERT-EU: Security Advisory 2026-018 – Critical Vulnerabilities in PHP, Version 1.2 vom 23.10.2026
• NCSC-NL: Operational information regarding the 2026 php2shell vulnerabilities
• CIRCL: TR-102 Critical Remote Code Execution Vulnerabilities in PHP
• Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, 21.10.2026
• CISA: Known Exploited Vulnerabilities Catalog, Stand 23.10.2026
• CSIRTs Network: Übersicht der Warnungen europäischer CSIRTs (CNW-2026-04)