PHP2Shell: Zwei kritische PHP-Schwachstellen, die aus einem Webserver ein Einfallstor machen können

PHP2Shell ist derzeit ein Thema, das jeder Betreiber eines PHP-basierten Webservers ernst nehmen sollte. Hinter dem Namen verbergen sich zwei kritische Sicherheitslücken in der PHP-Laufzeitumgebung. Sie können unter bestimmten Voraussetzungen dazu führen, dass ein Angreifer ohne Anmeldung eigenen Code auf einem verwundbaren Server ausführt. Betroffen sind nicht nur selbst entwickelte PHP-Anwendungen, sondern auch weitverbreitete Systeme wie WordPress, Drupal und Joomla.

Besonders unangenehm an dieser Schwachstelle: Das Problem liegt nicht zwingend in der eigentlichen Webanwendung. Ein sauber programmierter Webauftritt, aktuelle Plugins und eine vernünftige Zugriffskontrolle reichen deshalb nicht aus, um sich vor PHP2Shell zu schützen.

Die gute Nachricht ist, dass korrigierte PHP-Versionen bereits veröffentlicht wurden. Die schlechte Nachricht ist, dass die Zeit zwischen der öffentlichen Bekanntgabe und ersten konkreten Angriffsversuchen inzwischen sehr kurz ist. Wer einen betroffenen Server betreibt, sollte daher nicht erst das nächste reguläre Wartungsfenster abwarten.

PHP2Shell auf einen Blick

Die offiziellen Sicherheitsmeldungen beschreiben zwei unterschiedliche Ursachen: Speicherbeschädigung bei einem Speichererschöpfungsfehler und die Verwendung veralteter interner Zustände nach der Freigabe von Speicher. Beide können unter geeigneten Bedingungen zur Ausführung beliebigen Codes führen.

Quellen: PHP-Sicherheitsmeldung zu CVE-2026-109618 und PHP-Sicherheitsmeldung zu CVE-2026-109619.

Was ist PHP2Shell überhaupt?

PHP ist eine der etablierten Programmiersprachen für serverseitige Webanwendungen. Viele Websites, Content-Management-Systeme, Onlineshops und individuelle Webdienste verwenden PHP, um Inhalte zu erzeugen, Formulare zu verarbeiten oder mit Datenbanken zu kommunizieren.

Dabei wird PHP normalerweise nicht einfach als isoliertes Programm gestartet, das unabhängig vom Webserver arbeitet. Stattdessen verarbeitet die PHP-Laufzeit eingehende HTTP-Anfragen über eine Schnittstelle, die als SAPI bezeichnet wird. Dazu gehören beispielsweise Apache mit dem Modul mod_php, PHP-FPM in Kombination mit einem Webserver oder andere PHP-fähige Laufzeitumgebungen.

Genau an dieser Stelle liegt das Problem.

PHP2Shell ist keine klassische Schwachstelle, bei der ein Entwickler versehentlich eine unsichere Funktion in seinem eigenen Quellcode verwendet hat. Die beiden Fehler liegen tiefer in der Verarbeitung von Anfragen durch PHP selbst.

Ein Angreifer muss deshalb nicht zwangsläufig einen Fehler in der Anmeldeseite, eine verwundbare Erweiterung oder einen unsicheren API-Endpunkt finden. Je nach PHP-Konfiguration kann bereits eine entsprechend präparierte HTTP-Anfrage ausreichen, um einen Fehler im PHP-Prozess auszulösen.

Das macht PHP2Shell besonders relevant für Betreiber öffentlich erreichbarer Server. Eine Anwendung kann noch so ordentlich entwickelt sein: Wenn die darunterliegende Laufzeitumgebung verwundbar ist, bleibt ein erhebliches Risiko bestehen.

Der Name PHP2Shell beschreibt dabei die möglichen Auswirkungen. Eine erfolgreiche Remote Code Execution, kurz RCE, kann einem Angreifer die Möglichkeit geben, Befehle auf dem Server auszuführen. Daraus kann beispielsweise eine Shell entstehen, über die weitere Aktionen möglich sind.

Wichtig ist allerdings die Unterscheidung zwischen einer Schwachstelle und einer erfolgreichen Übernahme: Eine verwundbare Installation ist ein Risiko. Ob ein konkreter Angriff tatsächlich gelingt und welchen Schaden er anrichtet, hängt unter anderem von der verwendeten PHP-SAPI, der Konfiguration und den Rechten des PHP-Prozesses ab.

Die beiden Schwachstellen im technischen Detail

PHP2Shell besteht aus zwei eigenständigen Sicherheitslücken. Beide betreffen die Speicherverwaltung und interne Zustände der PHP-Laufzeit, verfolgen aber unterschiedliche Fehlerpfade.

CVE-2026-109618: Speicherbeschädigung bei Out-of-Memory-Fehlern

Die erste Schwachstelle betrifft die Behandlung von Situationen, in denen PHP nicht mehr genügend Speicher für eine angeforderte Operation bereitstellen kann.

Solche Situationen werden als Out of Memory, kurz OOM, bezeichnet.

Dass eine Anwendung bei Speicherknappheit einen Fehler ausgibt oder eine Anfrage abbricht, ist zunächst nichts Ungewöhnliches. Eine robuste Laufzeitumgebung muss dabei allerdings sicherstellen, dass alle internen Datenstrukturen weiterhin in einem gültigen Zustand bleiben.

Genau das funktioniert bei bestimmten Abläufen in den betroffenen PHP-Versionen nicht zuverlässig.

PHP verwendet intern unter anderem longjmp(), um die Verarbeitung nach bestimmten Fehlern vorzeitig abzubrechen. Einige Codepfade berücksichtigen diesen vorzeitigen Abbruch nicht ausreichend. Dadurch können interne Request-Daten in einem unvollständigen oder ungültigen Zustand zurückbleiben.

Das Problem zeigt sich insbesondere bei der anschließenden Aufräumarbeit. Nachdem eine Anfrage abgebrochen wurde, muss PHP deren Ressourcen freigeben und den internen Zustand bereinigen. Wenn diese Bereinigung auf Daten zugreift, die noch gar nicht korrekt initialisiert wurden, kann es zu Speicherbeschädigung kommen.

Unter geeigneten Bedingungen lässt sich dieser Ablauf so beeinflussen, dass daraus eine Möglichkeit zur Ausführung eigenen Codes entsteht.

Die Verarbeitung von HTTP-Anfragen mit multipart/form-data spielt bei den beschriebenen Angriffsmöglichkeiten eine wichtige Rolle. Solche Anfragen werden beispielsweise verwendet, wenn ein Formular Dateien hochlädt. Bestimmte Konstellationen bei der Verarbeitung der Formularfelder und ihrer Metadaten können mehr internen Speicher benötigen, als es die äußere Größe der Anfrage zunächst vermuten lässt.

Das bedeutet nicht, dass jeder Datei-Upload gefährlich ist. Der entscheidende Punkt ist vielmehr, dass ein Angreifer die Verarbeitung so beeinflussen kann, dass ein ungünstiger interner Speicherzustand entsteht.

Die offizielle PHP-Sicherheitsmeldung beschreibt den Fehler als Remote Code Execution über Speicherbeschädigung bei Out-of-Memory-Situationen.

Was bedeutet das in der Praxis?

Ein Angreifer könnte versuchen, eine öffentlich erreichbare PHP-Anwendung durch speziell aufgebaute HTTP-Anfragen in den problematischen Fehlerpfad zu bringen. Gelingt die Ausnutzung, kann PHP unter Umständen nicht mehr nur die Anfrage fehlerhaft beenden, sondern auch Code des Angreifers ausführen.

Für Administratoren ist besonders wichtig, dass die Anwendung selbst dabei nicht zwingend beteiligt sein muss. Bei Apache mit mod_php wurde ein anwendungunabhängiger Angriffspfad beschrieben, der bereits während der Vorbereitung einer Anfrage greifen kann, bevor der eigentliche Anwendungscode ausgeführt wird.

Quelle: GHSA-w8hw-w9fx-j79w – RCE via OOM corruption.

CVE-2026-109619: Veralteter globaler Zustand und Use-after-free

Die zweite Schwachstelle ist etwas schwieriger zu verstehen, aber für die Bewertung mindestens genauso wichtig.

PHP verwaltet intern verschiedene Zustände, beispielsweise Informationen zu Fehlern, Sessions, Objekten und Erweiterungen. Ein Teil dieser Informationen kann während der Verarbeitung einer Anfrage in internen, länger bestehenden Datenstrukturen referenziert werden.

Dabei muss PHP strikt zwischen Speicher unterscheiden, der nur für eine einzelne Anfrage benötigt wird, und Zuständen, die über die aktuelle Anfrage hinaus bestehen bleiben.

Wenn eine Anfrage beendet wird, muss PHP den zugehörigen Speicher freigeben und sicherstellen, dass keine internen Verweise mehr auf diesen Speicher zeigen.

Bei bestimmten Abläufen gelingt diese Bereinigung nicht vollständig. Ein interner Zustand kann auf Speicher verweisen, der bereits freigegeben wurde. Wird ein solcher Verweis später erneut verwendet, spricht man von einem Use-after-free.

Ein einfaches Gedankenmodell hilft dabei:

Stell dir vor, ein Mitarbeiter erhält für einen Auftrag eine bestimmte Akte. Nach Abschluss des Auftrags wird die Akte vernichtet. In einer anderen internen Liste steht jedoch weiterhin der alte Ablageort. Beim nächsten Auftrag greift jemand auf diesen Eintrag zurück, obwohl die Akte dort nicht mehr existiert oder inzwischen etwas völlig anderes abgelegt wurde.

In einem Programm ist das wesentlich gefährlicher als ein bloßer Verweis auf eine nicht mehr vorhandene Datei. Der Speicher kann inzwischen anderweitig verwendet werden. Ein späterer Zugriff kann dadurch falsche Daten lesen, einen ungültigen Zustand auslösen oder – bei gezielt beeinflussbarer Speicherbelegung – die Ausführung von Code ermöglichen.

Bei PHP2Shell entsteht dieser Zustand beispielsweise dann, wenn ein Fehler die reguläre Bereinigung unterbricht oder ein interner Fehlerzustand nach einer vermeintlichen Bereinigung erneut gesetzt wird. Das Problem kann anschließend bei einer weiteren Anfrage sichtbar werden, die von demselben persistenten PHP-Worker bearbeitet wird.

Entscheidend ist dabei die Reihenfolge der internen Abläufe. Eine spätere Operation kann auf den alten Zustand zugreifen, bevor PHP diesen im regulären Initialisierungspfad durch einen gültigen Zustand ersetzt.

Auch bei dieser Schwachstelle beschreibt das offizielle Advisory die Möglichkeit zur vollständigen Remote Code Execution.

Warum ist das für Serverbetreiber relevant?

Weil der Fehler nicht einfach durch das Deaktivieren eines einzelnen fehlerhaften Formulars zuverlässig ausgeschlossen wird. Die konkreten Voraussetzungen hängen vom internen Zustand ab, der zurückbleibt, sowie davon, welche weiteren PHP-Operationen ihn später verwenden.

Der Angriffsweg kann sich also je nach Umgebung unterscheiden. Das ist ein weiterer Grund, weshalb einfache Regeln auf einem Web Application Firewall (WAF) keine vollständige Lösung darstellen.

Quelle: GHSA-6wmf-4rv5-p3rp – RCE via stale global state.

Warum zwei unterschiedliche Fehler ein gemeinsames Sicherheitsproblem ergeben

Beide Schwachstellen verdeutlichen, wie kritisch Fehler bei der Speicherverwaltung in einer Laufzeitumgebung sein können.

Bei CVE-2026-109618 geht es um einen ungültigen oder unvollständig initialisierten Zustand nach einem Speichererschöpfungsfehler.

Bei CVE-2026-109619 geht es um einen internen Zustand, der nach der Freigabe des zugehörigen Speichers weiterhin verwendet werden kann.

Der gemeinsame Nenner ist die Verarbeitung von HTTP-Anfragen in der PHP-Laufzeit. In beiden Fällen können interne Abläufe aus dem vorgesehenen Kontrollfluss geraten. Die Auswirkungen reichen von Fehlern im Prozess bis zur Möglichkeit, fremden Code auszuführen.

Das ist auch der Grund, warum die beiden Probleme nicht mit einer einfachen Änderung im Anwendungscode erledigt werden können. Die Korrektur muss an der Stelle erfolgen, an der PHP diese internen Zustände verwaltet.

Mit den Sicherheitsupdates wurde die Fehlerbehandlung angepasst. Beim ersten Problem wurde der problematische unmittelbare Abbruch bei Speicherknappheit verändert. Beim zweiten Problem wurden die betroffenen Abläufe so korrigiert, dass veraltete Zustände nicht auf diese Weise weiterverwendet werden sollen.

Die technischen Details sind in den jeweiligen offiziellen Advisories dokumentiert. Für den Betrieb zählt zunächst eine andere Information: Es gibt korrigierte Versionen, und die Installation dieser Korrekturen ist die wichtigste Maßnahme.

Welche Systeme sind betroffen?

Die Sicherheitsmeldungen betreffen PHP selbst und damit unterschiedliche Webserver- und Deployment-Varianten.

In der Praxis sollte jeder Betreiber prüfen, ob ein öffentlich erreichbarer Dienst eine betroffene PHP-Version verwendet.

Apache mit mod_php

Diese Konstellation gilt als besonders kritisch. PHP wird dabei unmittelbar als Modul innerhalb der Apache-Prozesse ausgeführt.

Der für CVE-2026-109618 beschriebene Angriffspfad kann hier bereits während des Anfragestarts greifen, bevor der Anwendungscode ausgeführt wird. Die Schwachstelle ist deshalb nicht zwingend von WordPress, Joomla, Drupal oder einer individuellen PHP-Anwendung abhängig.

PHP-FPM

Viele moderne Webserver-Installationen verwenden PHP-FPM als separaten Prozessdienst, etwa hinter Nginx oder Apache.

PHP-FPM bietet eine gewisse Trennung zwischen Webserver und PHP-Prozess. Das bedeutet jedoch nicht, dass die Runtime-Schwachstelle damit erledigt wäre.

Die Analyse des PHP-Quellcodes beschreibt auch PHP-FPM als betroffen. Ein vollständiger, öffentlich demonstrierter Exploit für genau diese SAPI war laut dem PHP-Advisory zu CVE-2026-109618 zum Veröffentlichungszeitpunkt allerdings nicht nachgewiesen. Das ist keine Entwarnung und kein Grund, Updates aufzuschieben.

php-cgi, FrankenPHP und weitere Umgebungen

Auch andere Laufzeitumgebungen müssen anhand der offiziellen Sicherheitsmeldungen und der Hinweise des jeweiligen Herstellers geprüft werden.

Das gilt beispielsweise für php-cgi, FrankenPHP und LiteSpeed. Die konkrete Ausnutzbarkeit und einzelne Schutzmechanismen können sich unterscheiden. Maßgeblich sind nicht allein der Produktname oder die Architektur, sondern die tatsächlich eingesetzte PHP-Version und die dazugehörigen Sicherheitskorrekturen.

WordPress, Joomla und Drupal

Besonders relevant ist PHP2Shell für weitverbreitete Content-Management-Systeme.

WordPress, Joomla und Drupal werden häufig auf öffentlich erreichbaren Servern betrieben. Sie verwenden PHP und sind daher von den Sicherheitsproblemen ihrer Laufzeitumgebung betroffen, wenn diese ungepatcht ist.

Es ist dabei wichtig, zwischen der Anwendung und der Laufzeitumgebung zu unterscheiden.

Ein aktuelles WordPress-Release beseitigt keine Sicherheitslücke in einem verwundbaren PHP-Prozess. Gleiches gilt für eine Aktualisierung aller Plugins oder Themes. Diese Updates bleiben sinnvoll, beheben aber nicht automatisch PHP2Shell.

Die britische Gesundheitsorganisation NHS England Digital meldete, dass Sicherheitsforscher erfolgreiche Exploits in Umgebungen mit Produkten wie WordPress, Drupal und Joomla demonstriert haben.

Quelle: NHS England Digital – Critical Vulnerabilities in PHP (PHP2Shell).

Welche Auswirkungen kann eine erfolgreiche Ausnutzung haben?

Eine erfolgreich ausgenutzte Remote-Code-Execution-Schwachstelle gehört zu den schwerwiegenden Problemen, die einen öffentlich erreichbaren Server betreffen können.

Die tatsächlichen Auswirkungen hängen davon ab, mit welchen Rechten PHP ausgeführt wird, welche Dateien zugänglich sind und welche weiteren Sicherheitsmechanismen eingerichtet wurden.

Mögliche Folgen sind:

Ausführung eigener Befehle: Ein Angreifer kann versuchen, Befehle unter dem Benutzerkonto des PHP-Prozesses auszuführen. Wie weit diese Rechte reichen, ist von der Konfiguration abhängig.

Zugriff auf Konfigurationsdateien und Zugangsdaten: PHP-Anwendungen greifen häufig auf Datenbankkennwörter, API-Schlüssel oder weitere Zugangsinformationen zu. Können diese Dateien gelesen werden, können die Daten unter Umständen auch für weiterführende Angriffe verwendet werden.

Manipulation der Website: Angreifer können unter geeigneten Voraussetzungen Dateien verändern, schädliche Skripte ablegen oder legitime Inhalte manipulieren.

Zugriff auf weitere Systeme: Wenn der betroffene Prozess Zugang zu internen Diensten, Datenbanken oder anderen Ressourcen besitzt, kann ein Angreifer versuchen, diese Zugänge für zusätzliche Aktionen zu verwenden.

Missbrauch des Servers: Ein kompromittierter Server kann unter Umständen für weitere Angriffe, unerwünschte Hintergrundprozesse oder die Verteilung schädlicher Inhalte missbraucht werden.

Verlust oder Offenlegung von Daten: Je nach Prozessrechten und verfügbaren Zugangsdaten können auch Datenbanken, Kundendaten oder andere vertrauliche Informationen betroffen sein.

Dabei gilt eine wichtige Einschränkung: Eine erfolgreiche RCE bedeutet nicht automatisch, dass ein Angreifer Root-Rechte erlangt oder den gesamten Host kontrolliert. Genau deshalb sind restriktive Prozessrechte, getrennte Zugangsdaten, minimale Berechtigungen und eine saubere Systemarchitektur weiterhin relevant.

Sie verhindern nicht zuverlässig die Ausnutzung der Schwachstelle, können aber den möglichen Schaden begrenzen.

Wie kritisch ist PHP2Shell wirklich?

Die beiden CVEs sind mit einem CVSS-v4.0-Wert von jeweils 9,2 als kritisch eingestuft.

Ein solcher Wert ist kein Beweis dafür, dass jeder Server unmittelbar kompromittiert wird. Er signalisiert vielmehr, dass die potenziellen Auswirkungen und die Voraussetzungen für die Ausnutzung so schwerwiegend sind, dass eine schnelle Reaktion erforderlich ist.

Hinzu kommt die Entwicklung nach der Bekanntgabe.

Amazon Threat Intelligence berichtete am 21. Oktober 2026 über einen PHP2Shell-Ausnutzungsversuch, der bereits auf den 17. Oktober zurückging. In der Folge wurden weitere Versuche und öffentlich verfügbare Proofs of Concept beobachtet. Bei den frühen Versuchen ist nicht für jeden Fall nachgewiesen, dass ein Angriff auf ein reales Produkt tatsächlich erfolgreich war.

Telekom Security beobachtete seinerseits nach der Veröffentlichung entsprechende Prüfungen und eine Quelle, die exploit-ähnliche Anfragen an Honeypots sendete.

Das zeigt, wie schnell eine kritische Schwachstelle nach ihrer Bekanntgabe von unterschiedlichen Akteuren untersucht wird. Es beweist jedoch nicht, dass jeder verdächtige Request ein erfolgreicher Angriff war.

Quellen: Amazon Threat Intelligence – PHP2Shell exploitation attempts und Telekom Security – Honeypot Observations.

Für die Praxis bedeutet das: Ein Serverbetreiber sollte sich nicht darauf verlassen, dass Angreifer erst nach einigen Tagen oder Wochen aktiv werden. Die Bereitstellung eines Patches und seine tatsächliche Installation sind zwei unterschiedliche Dinge. Dazwischen liegt das Zeitfenster, in dem ein verwundbarer Dienst weiter erreichbar bleibt.

Welche PHP-Versionen sind sicher?

Die PHP-Entwickler haben am 21. Oktober 2026 korrigierte Releases veröffentlicht.

Für die betroffenen Upstream-Zweige gelten folgende Versionen als gepatcht:

Die Tabelle bezieht sich auf die offiziellen PHP-Upstream-Versionen. Bei Paketen von Linux-Distributionen oder Hosting-Anbietern kann die Versionsanzeige abweichen, wenn der Anbieter die Sicherheitskorrektur in ein bestehendes Paket zurückportiert hat.

PHP 8.1 und ältere Zweige erhalten keine regulären Upstream-Korrektur-Releases für diese Schwachstellen. Für solche Installationen ist der Wechsel auf einen unterstützten Zweig der verlässliche Weg. Vorhandene herstellerspezifische Sicherheitsupdates müssen separat anhand der jeweiligen Herstellerhinweise geprüft werden.

Die offizielle Ankündigung ist hier zu finden: PHP 8.5.12 und Sicherheitskorrekturen.

Achtung bei älteren Installationen

Es reicht nicht aus, die Hauptversionsnummer zu betrachten. PHP 8.4 ist nicht automatisch sicher, nur weil es neuer als PHP 8.2 ist. Entscheidend ist, ob die konkrete Installation tatsächlich die Korrektur enthält.

Umgekehrt kann ein Distributionspaket eine Sicherheitskorrektur enthalten, obwohl die angezeigte Versionsnummer nicht exakt mit der offiziellen Upstream-Version übereinstimmt.

Prüfe daher immer auch die Sicherheitsmeldungen deines Betriebssystem- oder Hosting-Anbieters.

PHP2Shell beheben: eine praktische Checkliste

Die wichtigste Maßnahme ist das Aktualisieren auf eine korrigierte PHP-Version. Die folgenden Schritte helfen dabei, die eigene Umgebung systematisch zu prüfen.

1. Alle PHP-Installationen erfassen

Zunächst sollte klar sein, wo PHP überhaupt eingesetzt wird.

Dazu gehören nicht nur die Hauptwebsite, sondern auch Subdomains, Testsysteme, Staging-Umgebungen, ältere Projekte und Dienste, die möglicherweise nicht mehr aktiv gepflegt werden.

Ein Webserver kann beispielsweise für mehrere Domains unterschiedliche PHP-Versionen oder Laufzeitdienste verwenden. Auch Container und separate FPM-Pools sollten in der Bestandsaufnahme berücksichtigt werden.

Eine erste Prüfung auf einem Linux-System kann mit folgendem Befehl erfolgen:

php -v

Wichtig: Dieser Befehl zeigt die PHP-Version des Kommandozeilenprogramms. Er beweist nicht automatisch, dass ein Webserver dieselbe PHP-Version verwendet.

Wer beispielsweise Apache mit mod_php betreibt oder mehrere PHP-FPM-Versionen parallel installiert hat, muss die tatsächlich verwendete Webserver-Laufzeit prüfen.

Das lässt sich über die Konfiguration des Webservers, die aktiven Dienste und – falls erforderlich – eine kurzfristig und zugriffsgeschützt bereitgestellte PHP-Informationsseite überprüfen. Eine öffentlich erreichbare phpinfo()-Seite sollte niemals dauerhaft bestehen bleiben, weil sie interne Konfigurationsinformationen preisgeben kann.

Bei Linux-Distributionen sollte außerdem geprüft werden, ob die installierten Pakete die Sicherheitskorrekturen enthalten. Eine Versionsnummer allein reicht bei möglichen Backports nicht in jedem Fall aus.

2. PHP aktualisieren

Installiere die vom Hersteller bereitgestellte korrigierte Version für den verwendeten PHP-Zweig.

Bei direkt installierten PHP-Paketen sollte der reguläre Paketmanager des Betriebssystems verwendet werden. Prüfe anschließend, ob alle benötigten PHP-Komponenten – beispielsweise FPM, CLI und gemeinsam genutzte Module – auf einem konsistenten und korrigierten Stand sind.

Ein erfolgreiches Update des CLI-Pakets allein genügt nicht, wenn der Webserver weiterhin einen alten PHP-FPM-Dienst verwendet.

Nach der Aktualisierung müssen gegebenenfalls die betroffenen Dienste neu gestartet werden, damit die neuen Binärdateien tatsächlich verwendet werden. Anschließend sollte die laufende Umgebung erneut kontrolliert werden.

3. PHP in Docker aktualisieren

Docker macht Updates nicht überflüssig. Ein PHP-Container enthält eine konkrete Version der Laufzeitumgebung und bleibt verwundbar, wenn er mit einem ungepatchten Image erstellt wurde.

Bei einem Compose-Projekt, das ein fertiges Image verwendet, sieht der grundlegende Ablauf beispielsweise so aus:

docker compose pull
docker compose up -d --force-recreate

Das lädt verfügbare Images und erstellt die betreffenden Container neu. Voraussetzung ist, dass das Image-Tag auf ein tatsächlich aktualisiertes Image verweist und der Anbieter die Sicherheitskorrektur bereits veröffentlicht hat.

Wird PHP dagegen aus einem eigenen Dockerfile gebaut, muss zunächst das Basisimage aktualisiert werden. Anschließend wird das eigene Image neu gebaut und ausgerollt:

docker compose build --pull
docker compose up -d --force-recreate

Die konkreten Befehle können je nach Aufbau der Compose-Datei abweichen. Ein Dienst mit image: und ein Dienst mit build: werden nicht auf identische Weise aktualisiert.

Nach dem Rollout sollte kontrolliert werden, welche Image-Version tatsächlich läuft. Das Aktualisieren eines Images ändert einen bereits laufenden Container nicht automatisch.

Auch wichtig: Ein Neustart des alten Containers allein beseitigt die Schwachstelle nicht, wenn weiterhin dasselbe verwundbare Image verwendet wird.

4. WordPress, Joomla und Drupal separat kontrollieren

Bei einem CMS sollten sowohl die PHP-Laufzeit als auch die Anwendung selbst überprüft werden.

WordPress, Joomla und Drupal können aktuelle Programmversionen verwenden und trotzdem mit einer verwundbaren PHP-Version laufen. Das Gleiche gilt für eigene Erweiterungen und Themes.

Aktualisiere deshalb die Laufzeitumgebung und installiere darüber hinaus die regulären Sicherheitsupdates des CMS sowie seiner Erweiterungen. Beide Maßnahmen sind sinnvoll, ersetzen einander aber nicht.

5. Nach dem Update die Anwendung testen

Ein Sicherheitsupdate sollte nicht nur installiert, sondern auch verifiziert werden.

Prüfe nach dem Neustart unter anderem:

• Wird die korrigierte PHP-Version tatsächlich von der Webanwendung verwendet?

• Starten Apache, Nginx und PHP-FPM fehlerfrei?

• Funktionieren Login, Datenbankzugriff und Datei-Uploads?

• Werden weiterhin unerwartete PHP-Fehler protokolliert?

• Sind alle betroffenen Container und FPM-Pools aktualisiert?

Ein kurzer Funktionstest ist besonders wichtig, wenn auf eine andere PHP-Unterversion gewechselt wurde oder zusätzliche Erweiterungen installiert sind.

Die Sicherheitskorrektur sollte möglichst zeitnah erfolgen. Funktionstests sollten den Patch nicht unnötig verzögern.

Was tun, wenn sich der Patch nicht sofort installieren lässt?

PHP selbst weist darauf hin, dass es keine vollständige Konfigurationsmaßnahme gibt, die beide Sicherheitslücken zuverlässig beseitigt. Die Aktualisierung bleibt die einzige vollständige Abhilfe.

Wenn ein unmittelbares Update aus technischen oder betrieblichen Gründen nicht möglich ist, sollte das betroffene System zunächst als gefährdet betrachtet werden.

Je nach Anwendung kann es sinnvoll sein, die Erreichbarkeit des Dienstes vorübergehend einzuschränken oder ihn offline zu nehmen, bis ein sicheres Update verfügbar ist.

Ein WAF oder Reverse Proxy kann bestimmte verdächtige Anfragen blockieren. Das ist jedoch nur eine zusätzliche Schutzschicht und keine vollständige Lösung für die Runtime-Schwachstellen.

Auch das Abschalten einzelner Funktionen, etwa des Session-Upload-Progress, wird in technischen Analysen als Teilmaßnahme für bestimmte Angriffspfade beschrieben. Solche Änderungen wirken aber nicht pauschal gegen beide CVEs und können Auswirkungen auf Anwendungen haben. Sie sollten deshalb nur anhand der offiziellen Hinweise und nach einer Prüfung der eigenen Umgebung umgesetzt werden.

Besonders problematisch wäre es, die PHP-Speicherverwaltung auf Verdacht so umzubauen, dass neue Betriebs- oder Verfügbarkeitsprobleme entstehen. Wer eine Zwischenmaßnahme benötigt, sollte sie gezielt auswählen, testen und dokumentieren.

Die Priorität bleibt eindeutig: Patch installieren, korrekte Laufzeit verifizieren und anschließend die Umgebung auf mögliche frühere Angriffe überprüfen.

Wie kann man erkennen, ob ein System bereits angegriffen wurde?

Das ist eine der unangenehmsten Fragen bei PHP2Shell. Die Installation eines Patches verhindert neue Angriffe über die behobenen Fehler, sagt aber nicht, ob jemand die Schwachstelle vor dem Update bereits ausgenutzt hat.

Deshalb sollte die Aktualisierung mit einer kurzen Sicherheitsprüfung kombiniert werden.

Webserver- und Proxy-Logs untersuchen

Prüfe die Zugriffs- und Fehlerprotokolle auf ungewöhnliche Anfragen, insbesondere POST-Anfragen mit multipart/form-data, auffällig großen Request-Größen oder Hinweisen auf das Feld PHP_SESSION_UPLOAD_PROGRESS.

Das Feld ist im Zusammenhang mit bestimmten Angriffspfaden relevant, stellt für sich allein aber keinen Beweis für einen Angriff dar. Auch legitime Anwendungen und automatisierte Sicherheitsscanner können auffällige Anfragen erzeugen.

Ebenso sind Fehlermeldungen im Zusammenhang mit Speicherknappheit oder abgestürzten Apache-Worker-Prozessen mögliche Hinweise auf fehlgeschlagene Versuche. Sie beweisen nicht automatisch eine erfolgreiche Kompromittierung.

Umgekehrt gilt: Ein unauffälliges Fehlerprotokoll schließt einen erfolgreichen Angriff nicht aus.

Die Anfragekörper werden in normalen Webserver-Logs häufig nicht vollständig erfasst. Deshalb können auch Request-Größen, ungewöhnliche Muster oder ergänzende WAF-Protokolle bei der Bewertung helfen.

Unerwartete Prozesse untersuchen

Wenn ein Angreifer Code im Kontext eines Webprozesses ausführen kann, können danach Prozesse auftreten, die dort normalerweise nicht hingehören.

Beispiele sind unerwartete Shell-Prozesse als Kindprozesse von Apache, PHP-FPM oder php-cgi, verdächtige ausgehende Netzwerkverbindungen oder neu gestartete Hintergrunddienste.

Solche Beobachtungen sollten im Kontext bewertet werden. Administrationsskripte, Wartungsaufgaben und legitime Anwendungen können ebenfalls Unterprozesse starten.

Dateien und Konfigurationen kontrollieren

Suche nach unerwartet neu angelegten oder geänderten Dateien, besonders in Upload-, Cache-, temporären und öffentlich erreichbaren Verzeichnissen.

Achte auch auf Veränderungen an PHP-Dateien, Webserver-Konfigurationen, geplanten Aufgaben und Startskripten.

Bei einem Verdacht sollte nicht nur die eigentliche Website untersucht werden. Auch Zugangsdaten, Datenbankzugriffe und Systeme, die vom PHP-Prozess erreichbar waren, können betroffen sein.

Den Zeitraum nicht zu eng wählen

Da Amazon Threat Intelligence einen Ausnutzungsversuch bereits für den 17. Oktober 2026 berichtete, sollte eine Untersuchung mindestens diesen Zeitraum berücksichtigen, sofern die entsprechenden Logs verfügbar sind.

Ein Patch, der am 23. Oktober installiert wurde, sagt nichts darüber aus, was auf dem System am 18. oder 20. Oktober passiert ist.

Was tun, wenn eine Kompromittierung möglich erscheint?

Wenn konkrete Hinweise auf eine erfolgreiche Ausnutzung vorliegen, reicht es nicht mehr, lediglich die PHP-Version zu aktualisieren.

In diesem Fall sollte ein geordnetes Incident-Response-Verfahren starten.

Erstens: den betroffenen Dienst eindämmen. Je nach Lage kann es erforderlich sein, die Erreichbarkeit einzuschränken oder das System vom Netz zu nehmen. Dabei sollten Beweise und relevante Protokolle nach Möglichkeit gesichert werden, bevor sie durch einen unüberlegten Neustart oder eine Neuinstallation verloren gehen.

Zweitens: den Umfang des Vorfalls bestimmen. Untersuche nicht nur den Webserver, sondern auch Datenbanken, gemeinsam genutzte Verzeichnisse und weitere Systeme, auf die der PHP-Prozess zugreifen konnte.

Drittens: erreichbare Geheimnisse absichern. Wenn eine Kompromittierung wahrscheinlich ist, sollten Zugangsdaten erneuert werden, die der betroffene Prozess lesen konnte. Dazu können Datenbankkennwörter, API-Schlüssel, Tokens und gegebenenfalls Cloud-Zugangsdaten gehören.

Viertens: die Integrität wiederherstellen. Ein bereits kompromittierter Server sollte nach einem festgelegten Verfahren bereinigt oder aus einer vertrauenswürdigen Basis neu aufgebaut werden. Nur eine Datei zu löschen, die verdächtig aussieht, ist kein belastbarer Nachweis dafür, dass das System wieder sauber ist.

Fünftens: den Vorfall dokumentieren. Halte fest, welche Systeme betroffen waren, welche Daten möglicherweise zugänglich waren, wann erste Hinweise vorlagen und welche Gegenmaßnahmen durchgeführt wurden.

Bei produktiven Systemen mit Kundendaten oder geschäftskritischen Prozessen sollte ein größerer Verdacht durch qualifizierte Incident-Response-Unterstützung begleitet werden.

Warum Docker allein keine Sicherheitslösung ist

Viele Webanwendungen laufen heute in Docker-Containern. Das verbessert die Reproduzierbarkeit von Deployments und ermöglicht eine klare Trennung von Anwendungen. Es macht einen verwundbaren PHP-Prozess jedoch nicht automatisch sicher.

Ein Container, der auf einem ungepatchten PHP-Image basiert, enthält weiterhin die problematische Laufzeitumgebung.

Wie groß der mögliche Schaden ist, hängt unter anderem davon ab, mit welchem Benutzer PHP läuft, welche Verzeichnisse beschreibbar sind, welche Geheimnisse verfügbar sind und welche Ressourcen der Container erreichen kann.

Deshalb sollte man zwei Dinge getrennt betrachten:

Die Schwachstelle beseitigen: Dafür ist ein korrigiertes PHP-Image beziehungsweise ein korrigiertes Paket erforderlich.

Den möglichen Schaden begrenzen: Dafür helfen minimale Prozessrechte, eingeschränkte Dateisystemzugriffe, restriktive Netzwerkregeln, eine sorgfältige Behandlung von Secrets und ein möglichst kleiner Berechtigungsumfang.

Wer beispielsweise einen PHP-Container ohne Root-Rechte betreibt und keine unnötigen Host-Verzeichnisse einbindet, reduziert unter Umständen den Handlungsspielraum eines Angreifers. Das ersetzt aber nicht das notwendige Sicherheitsupdate.

Für Docker-basierte Installationen sollte außerdem die gesamte Image-Kette betrachtet werden. Ein veraltetes Basisimage kann weiterverwendet werden, selbst wenn der Anwendungscode neu gebaut wurde. Entscheidend ist daher, dass die neue Image-Version tatsächlich eine korrigierte PHP-Laufzeit enthält.

Welche langfristigen Lehren lassen sich aus PHP2Shell ziehen?

PHP2Shell ist mehr als eine einzelne Update-Aufgabe. Die Vorfälle zeigen einige Schwachstellen in typischen Betriebsabläufen, die sich mit relativ überschaubarem Aufwand verbessern lassen.

Laufzeitumgebungen gehören ins Schwachstellenmanagement

Viele Organisationen erfassen den Quellcode ihrer Anwendungen und prüfen deren Abhängigkeiten regelmäßig. Die tatsächlich verwendete Laufzeitumgebung wird dagegen nicht immer mit derselben Konsequenz behandelt.

PHP2Shell verdeutlicht, dass eine Schwachstelle im Runtime-Kern zahlreiche voneinander unabhängige Anwendungen betreffen kann.

PHP-Versionen und deren Herkunft sollten deshalb inventarisiert werden. Dazu gehören direkte Paketinstallationen, Webhosting-Umgebungen, Container-Images, CI/CD-Artefakte und gegebenenfalls separat betriebene FPM-Pools.

Patches müssen bis in den laufenden Betrieb gelangen

Ein erfolgreich gebautes Container-Image ist noch kein erfolgreicher Sicherheitsrollout.

Ebenso bedeutet ein Update im Paketmanager nicht automatisch, dass der produktive Webserver bereits die korrigierte Laufzeit verwendet.

Patchmanagement umfasst daher mindestens drei Schritte: die Korrektur bereitstellen, sie auf den betroffenen Systemen aktivieren und anschließend den tatsächlich laufenden Zustand überprüfen.

Backups und Wiederherstellung gehören zur Sicherheitsstrategie

Backups helfen bei der Wiederherstellung nach einem Vorfall. Sie verhindern aber nicht, dass ein verwundbarer Server angegriffen wird.

Ebenso ist es wichtig, regelmäßig zu testen, ob sich ein Dienst aus einer vertrauenswürdigen Basis wieder aufbauen lässt. Ein Backup, das lediglich kompromittierte Dateien oder Konfigurationen reproduziert, ist für einen Sicherheitsvorfall nur begrenzt hilfreich.

Monitoring sollte auf Verhalten achten

Nicht jeder Angriff lässt sich rechtzeitig anhand eines bekannten Musters im HTTP-Traffic erkennen.

Zusätzlich zu Webserver-Logs sind daher Überwachungsmechanismen sinnvoll, die ungewöhnliche Prozessstarts, verdächtige ausgehende Verbindungen, unerwartete Dateiänderungen und Abweichungen vom normalen Serververhalten erfassen.

Solche Signale sind nicht automatisch ein Beweis für PHP2Shell. Sie können aber helfen, eine mögliche Kompromittierung frühzeitig zu erkennen.

Häufige Fragen zu PHP2Shell

Muss ich meine PHP-Anwendung neu schreiben?

Nein. PHP2Shell ist eine Schwachstelle in der PHP-Laufzeitumgebung. Die vorrangige Maßnahme ist die Aktualisierung auf eine korrigierte Version. Ob zusätzlich Anpassungen an der Anwendung notwendig sind, hängt vom individuellen Betrieb und eventuellen weiteren Problemen ab.

Reicht es aus, WordPress und alle Plugins zu aktualisieren?

Nein. Ein aktuelles CMS beseitigt die Schwachstelle im PHP-Kern nicht automatisch. Die PHP-Laufzeit muss separat aktualisiert werden.

Ist PHP-FPM sicherer als mod_php?

PHP-FPM verändert die Architektur und die Prozessgrenzen, beseitigt die beiden Runtime-Schwachstellen aber nicht automatisch. Der offizielle Hinweis zu CVE-2026-109618 beschreibt PHP-FPM ebenfalls als anfällig, wobei die konkret nachgewiesenen Angriffsmöglichkeiten je nach SAPI unterschiedlich sind.

Schützt ein WAF zuverlässig vor PHP2Shell?

Nein. Ein WAF kann bestimmte verdächtige Anfragen blockieren und damit das Risiko möglicherweise reduzieren. Die offiziellen Hinweise empfehlen jedoch keine WAF-Regel als vollständigen Ersatz für das Sicherheitsupdate.

Reicht ein Neustart des Webservers?

Nein. Ein Neustart kann dafür sorgen, dass aktualisierte Programme oder Konfigurationen neu geladen werden. Wenn jedoch weiterhin ein altes, verwundbares PHP-Paket oder Container-Image verwendet wird, besteht das Problem weiter.

Bin ich sicher, wenn bisher keine verdächtigen Einträge im Log stehen?

Das lässt sich daraus nicht ableiten. Protokolle können unvollständig sein und eine erfolgreiche Ausnutzung muss nicht zwingend einen eindeutigen Eintrag erzeugen. Bei öffentlich erreichbaren, ungepatchten Systemen ist ein Update deshalb unabhängig von sichtbaren Angriffsspuren erforderlich.

Was ist mit älteren PHP-Versionen?

Die offiziellen korrigierten Releases betreffen PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Für ältere, nicht mehr unterstützte Zweige sollte geprüft werden, ob der jeweilige Hersteller eigene Sicherheitskorrekturen bereitstellt. Langfristig ist der Wechsel auf einen unterstützten PHP-Zweig der verlässliche Weg.

Fazit: Jetzt aktualisieren und anschließend genauer hinsehen

PHP2Shell zeigt, wie schnell ein Fehler in einer weitverbreiteten Laufzeitumgebung zu einem ernsthaften Sicherheitsproblem werden kann. Die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619 betreffen die interne Verarbeitung von Anfragen durch PHP und können unter geeigneten Bedingungen eine Remote Code Execution ermöglichen.

Die Bewertung als kritisch ist nachvollziehbar: Ein Angreifer benötigt nicht zwangsläufig ein Benutzerkonto oder eine verwundbare Funktion in der Anwendung. Besonders bei öffentlich erreichbaren PHP-Installationen kann das die Angriffsfläche erheblich vergrößern.

Die unmittelbare Aufgabe ist deshalb klar: alle eingesetzten PHP-Versionen erfassen, korrigierte Pakete oder Images einspielen und anschließend überprüfen, ob der Webserver tatsächlich mit einer geschützten Laufzeit arbeitet.

Damit sollte die Arbeit aber nicht enden. Weil bereits Versuche vor der öffentlichen Bekanntgabe beobachtet wurden, sollten Betreiber exponierter Systeme zusätzlich prüfen, ob es Anzeichen für frühere Angriffe gibt.

Und unabhängig von PHP2Shell lohnt es sich, die eigenen Betriebsabläufe zu überprüfen. Regelmäßige Updates, ein aktuelles Softwareinventar, minimale Rechte, verlässliche Backups und eine gute Überwachung lösen nicht jedes Sicherheitsproblem. Sie entscheiden aber häufig darüber, wie groß der Schaden wird, wenn eine kritische Schwachstelle auftaucht.

Meine Empfehlung: PHP2Shell nicht als gewöhnliches Wartungsticket behandeln. Für öffentlich erreichbare Systeme hat die Aktualisierung auf eine korrigierte Version jetzt Priorität. Wer bei der Versionsprüfung, dem Deployment oder den Logs nicht sicher ist, sollte die betroffene Umgebung zeitnah genauer untersuchen.

Quellen und weiterführende Informationen

• PHP: Veröffentlichung von PHP 8.5.12 – offizielle Ankündigung der Sicherheitskorrekturen.

• PHP Security Advisory: CVE-2026-109618 – technische Beschreibung der Speicherbeschädigung bei Out-of-Memory-Fehlern.

• PHP Security Advisory: CVE-2026-109619 – technische Beschreibung des Use-after-free-Fehlers.

• NHS England Digital: Critical Vulnerabilities in PHP (PHP2Shell) – Zusammenfassung der Gefahren und Empfehlungen zur Behebung.

• Amazon Threat Intelligence: PHP2Shell-Ausnutzungsversuche – Beobachtungen zu Angriffen vor und nach der öffentlichen Bekanntgabe.

• Telekom Security: PHP2Shell-Honeypot-Beobachtungen – beobachtete Anfragen und Einordnung verdächtiger Aktivitäten.

• Bitdefender: Technical Advisory zu PHP2Shell – technische Hintergründe, Erkennungshinweise und Maßnahmen für Administratoren.

Redaktionsstand: 23. Oktober 2026. Sicherheitsinformationen und Herstellerhinweise können sich weiterentwickeln. Vor produktiven Änderungen sollten daher immer die aktuellen PHP- und Distributions-Advisories geprüft werden.

Reviewed by Marco Oderkerk