PHP2Shell Sicherheitslücke: Fehler in PHP selbst

Wir haben PHP2Shell schon zweimal aufgegriffen: in unserem Beitrag vom 21. Oktober und in unseren Top 5 vom 23. Oktober. Eine Woche nach den Notfall-Patches werfen wir einen genaueren Blick auf die PHP2Shell Sicherheitslücke: was sie ist, was sich als wichtig erwiesen hat und was diese Woche noch zu prüfen ist.

Zwei kritische Schwachstellen im PHP-Kern, zusammen als PHP2Shell bekannt, erlauben es Angreifern, unter bestimmten Bedingungen ohne Anmeldung Code auf Webservern auszuführen. Die PHP2Shell Sicherheitslücke umfasst CVE-2026-109618 und CVE-2026-109619, beide mit 9,2 nach CVSS v4.0 bewertet. Betroffen ist jede PHP-Installation, die Webanfragen bedient, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

Der Fehler steckt in PHP selbst, nicht in einem Plugin, Theme, Framework oder einer Eigenentwicklung. Es reicht deshalb nicht, WordPress, Drupal, Joomla oder eine andere PHP-Anwendung zu aktualisieren. Aktualisiert werden muss die PHP-Laufzeitumgebung, oder Sie installieren ein gepatchtes Paket Ihres Betriebssystem-Herstellers, Hosting-Anbieters oder Appliance-Lieferanten. Dieser Beitrag beschreibt den Stand vom 27. Oktober 2026.

Was ist die PHP2Shell Sicherheitslücke?

PHP2Shell ist der Name für zwei verwandte Speicherfehler im PHP-Interpreter. Beide können zur Codeausführung mit den Rechten des PHP-Worker-Prozesses führen. Forschende beschreiben außerdem die Möglichkeit, Speicherinhalte auszulesen, die sensible Daten aus dem Webserver-Prozess enthalten können.

Beide Fehler entstehen, wenn eine Anfrage ungewöhnlich endet, etwa bei zu wenig Arbeitsspeicher oder einem schweren Fehler. PHP kann dann interne Anfragedaten halb initialisiert zurücklassen oder Zeiger behalten, die auf bereits freigegebenen Speicher zeigen. Eine spätere Anfrage, die derselbe PHP-Worker bearbeitet, trifft dann auf diesen beschädigten oder veralteten Zustand. Angreifer brauchen weder Zugangsdaten noch eine Sitzung. Gezielt präparierte Anfragen können genügen, um den Speicherzustand von PHP zu verfälschen und am Ende beliebigen Code auf dem Server auszuführen.

CVE-2026-109618 ist eine Codeausführung durch Speicherbeschädigung bei Speichermangel. Wird PHP unterbrochen, während interne Anfragedaten erst teilweise initialisiert sind, kann die Aufräumroutine ungültige Daten für gültig halten. Angreifer können das nutzen, um Speicher zu manipulieren und Code auszuführen.

CVE-2026-109619 ist eine Codeausführung durch veralteten globalen Zustand. Unterbricht ein schwerer Fehler PHP bei der Serialisierung oder Deserialisierung, können interne Kontextdaten weiter auf Speicher zeigen, der am Ende der Anfrage freigegeben wird. PHP-Worker laufen oft weiter, um spätere Anfragen zu bedienen, sodass die nächste Anfrage auf diesen freigegebenen Speicher zugreifen kann. Mögliche Folgen sind Informationsabfluss oder Codeausführung. Beiden Lücken liegt dasselbe Muster zugrunde: PHP behält nach einem abnormalen Ende einer Anfrage Speicherzustand bei oder deutet ihn falsch. Sie unterscheiden sich im Weg, auf dem dieser Zustand entsteht und missbraucht wird.

Wer ist von der PHP2Shell Sicherheitslücke betroffen?

Das PHP-Projekt erklärt, dass alle Installationen betroffen sind, die Webanfragen bedienen. Das gilt für die üblichen Betriebsarten: PHP-FPM hinter NGINX oder Apache, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Websites und Anwendungen auf PHP-Basis sind gefährdet, wenn die darunterliegende Laufzeitumgebung nicht gepatcht ist. Das betrifft WordPress, Drupal, Joomla und viele Eigenentwicklungen. Ob ein bestimmter Angriffsweg erreichbar ist, hängt zudem von der Konfiguration ab. CrowdStrike weist darauf hin, dass die Standardwerte von PHP den von ihr gezeigten Weg über Speichermangel nicht zulassen, auf Uploads abgestimmte Setups ihn aber ermöglichen können. Behandeln Sie deshalb jedes ungepatchte System als gefährdet.

Das PHP-Sicherheitsteam stuft Apache mit mod_php als Konfiguration mit dem höchsten Risiko ein. Das Modul bettet PHP direkt in den Apache-Prozess ein, sodass Interpreter und Webserver denselben Prozesskontext teilen. Forschende zeigten, dass in dieser Konfiguration eine einzige unauthentifizierte Anfrage den Fehler auslösen kann, noch bevor Anwendungscode läuft. Wer mod_php einsetzt, sollte das Patchen an erste Stelle setzen und prüfen, ob PHP-FPM besser zur eigenen Umgebung passt. Der Wechsel zu PHP-FPM ersetzt den Patch nicht, denn auch PHP-FPM ist betroffen. Er bietet in vielen Hosting-Umgebungen aber bessere Prozessisolation.

Gepatchte Versionen und Sofortmaßnahmen

Das PHP-Projekt hat am 21. Oktober 2026 Notfall-Patches für die PHP2Shell Sicherheitslücke veröffentlicht, nachdem Details der Lücken einen Tag zuvor im Netz aufgetaucht waren. Aktualisieren Sie auf eine dieser Versionen oder installieren Sie das gleichwertige gepatchte Paket Ihrer Linux-Distribution, Ihres Hosting-Anbieters oder Appliance-Herstellers:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

In den meisten Umgebungen werden PHP-Updates nicht automatisch eingespielt. Erfassen Sie jeden Server, Container, jede Staging-Umgebung und Appliance, auf der PHP läuft, ermitteln Sie die Version, die tatsächlich Webanfragen bedient, und beginnen Sie mit den aus dem Internet erreichbaren Systemen. Die PHP-Version in der Kommandozeile kann von der abweichen, die PHP-FPM oder Apache ausführt, prüfen Sie also die Version der Webanwendung. Starten Sie die PHP-Worker nach dem Update neu und bauen Sie Container-Images neu, damit der Fix überall greift.

PHP 8.1 und älter erhalten vom PHP-Projekt keine Updates mehr. Wer sie noch einsetzt, nutzt ein gepatchtes Paket der Distribution oder des Langzeit-Support-Anbieters oder wechselt auf eine unterstützte Version. Das PHP-Sicherheitsteam hat zudem minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1 veröffentlicht, für alle, die selbst bauen. Die Migration ist dringend, und PHP 8.2 erreicht am 31. Dezember 2026 das Support-Ende. Konfigurationsänderungen ersetzen das Update nicht. Das PHP-Projekt stellt klar, dass es keine vollständigen Mitigationen gibt und das Update die einzig sichere Wahl ist.

Eine Woche später: Was über die Angriffe bekannt ist

Stand 27. Oktober beschreiben öffentliche Berichte Angriffsversuche auf die PHP2Shell Sicherheitslücke, und die Lage hat sich bewegt. Amazon Threat Intelligence erfasste den ersten Versuch gegen einen ihrer Honeypots am 17. Oktober, vier Tage vor den Patches, und erklärte, es sei unklar, woher der Angreifer während der Sperrfrist Exploit-Informationen hatte. Die technischen Details tauchten am 20. Oktober im Netz auf. Am Tag der Veröffentlichung sah Amazon mehrere Proof-of-Concept-Exploits und beschrieb nach der Veröffentlichung breite Ausnutzungsversuche in freier Wildbahn. watchTowr gab an, sein Honeypot-Netzwerk habe am 21. Oktober Ausnutzung beider Lücken beobachtet. Zscaler erfasste in den ersten 48 Stunden nach der Veröffentlichung 1.156 Angriffsversuche von 156 verschiedenen IP-Adressen gegen 70 Organisationen, mit mehreren unterschiedlichen Werkzeugen.

Das britische National Cyber Security Centre rief Organisationen auf, sofort zu aktualisieren und Systeme notfalls vom Netz zu nehmen, wenn das nicht rechtzeitig möglich ist. Am 26. Oktober nahm die US-Behörde CISA beide CVEs in ihren Katalog bekannter ausgenutzter Schwachstellen (KEV) auf und setzte US-Bundesbehörden eine Frist bis zum 29. Oktober. Zum Zeitpunkt des Schreibens ist öffentlich nicht geklärt, wie viele Systeme tatsächlich kompromittiert wurden, und das kann sich ändern.

Die Lücken sind in der Praxis nachgewiesen. Wiz Research, das sie gemeinsam mit OpenAI Codex Security und Calif entdeckt hat, zeigte unautorisierte Codeausführung gegen aktuelle WordPress-, Drupal- und Joomla-Container-Images. CrowdStrike reproduzierte in eigenen Tests funktionierende Proof-of-Concept-Exploits und beschreibt den Angriff als leise: Der Worker stürzt nicht ab, der Server antwortet mit HTTP 200, und Anwendungs-Logs zeigen nichts Auffälliges. Frühere Einschätzungen waren vorsichtiger. Das BSI erklärte am 22. Oktober, ihm sei keine erfolgreiche Ausnutzung in der Breite bekannt, und CrowdStrike schrieb in seiner Analyse vom 23. Oktober, Angreifer müssten öffentlichen Proof-of-Concept-Code an die genaue PHP-Version, die Bibliotheken, die Server-API und die Anwendung anpassen; man habe nur Tests, Sondierungen und erfolglose Versuche gesehen. CrowdStrike erwartete außerdem, dass fähige Akteure die Lücken gegen lohnende Ziele ausprobieren und viele weitere folgen, sobald ein öffentlicher Exploit für ein weit verbreitetes Setup funktioniert. Mit dem CISA-Eintrag sind diese Einschätzungen eine Momentaufnahme und kein Grund zu warten.

Was KMU jetzt gegen die PHP2Shell Sicherheitslücke tun sollten

Beginnen Sie mit dem Update. Listen Sie alle Systeme auf, die PHP-Webanfragen bedienen: Produktivserver, Staging-Umgebungen, Entwicklungsrechner, Container und gemanagtes Hosting. Heben Sie dann jedes auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 an oder spielen Sie den Patch des Herstellers ein. Schreibt eine Anwendung oder ein Plugin eine PHP-Version vor, testen Sie die neue Laufzeit zuerst in der Staging-Umgebung. Bei einer so schwerwiegenden Lücke sollte dieser Test kurz und zielgerichtet bleiben. Er ist kein Grund, den Fix aufzuschieben.

Bevor Sie ein exponiertes System aktualisieren, sichern Sie die PHP- und Webserver-Logs und suchen Sie nach neuen Web Shells, unerwarteten Cronjobs und unbekannten Konten. Beide Lücken werden durch Fehler innerhalb einer Anfrage ausgelöst. Auffällig sind deshalb POST-Anfragen mit PHP_SESSION_UPLOAD_PROGRESS, ungewöhnlich große oder tief verschachtelte Multipart-Anfragen, PHP-Speicherlimit-Fehler im Fehlerlog des Webservers, die auf „in Unknown on line 0“ enden (ein Zeichen, dass noch kein PHP-Skript lief), Dateien im Web-Root und ausgehende Verbindungen von PHP-Prozessen, die Sie sich nicht erklären können. Da die Ausnutzung stattfinden kann, bevor Anwendungscode läuft, zeigen Anwendungs-Logs allein womöglich nichts. Amazon rät, eine Untersuchung ab dem 17. Oktober zu beginnen, dem frühesten bekannten Versuch, und nicht erst ab dem Veröffentlichungsdatum.

Lässt sich ein System nicht sofort aktualisieren, setzen Sie die vorläufigen Maßnahmen aus dem PHP-Advisory um. Sie senken das Risiko für einzelne Angriffswege, machen eine Installation aber nicht sicher. Dauert auch das zu lange, rät das NCSC, das System bis zur Absicherung vom Netz zu nehmen. Prüfen Sie außerdem, ob Ihre Erkennung und Reaktion die Webschicht abdeckt. Führen Sie Endpoint-, Server- und Netzwerk-Telemetrie zusammen, damit auffälliges Verhalten von PHP-Workern, unerwartete Befehlsausführung oder Aktivität nach einem Einbruch schnell auffällt.

Fazit

Die Laufzeitumgebung unter Ihrer Website gehört zur Angriffsfläche, auch wenn kaum jemand sie im Blick hat. Der Fix ist verfügbar. Zeit kostet etwas anderes: zu wissen, wo PHP läuft, wem welches System gehört und ob es wirklich gepatcht ist.

Eine Besonderheit der PHP2Shell Sicherheitslücke verdient in den Wochen nach dem Patchen Aufmerksamkeit: Der Angriff gilt als leise. Der Worker stürzt nicht ab, der Server antwortet mit HTTP 200, und die Anwendungs-Logs zeigen nichts Auffälliges. Sichtbar wird erst das Danach, etwa ein Webserver-Prozess, der eine Shell startet, oder eine neue Datei im Web-Root. Auf genau solche Aktivität ist Managed Detection & Response auf Basis von NovaMDR ausgelegt, rund um die Uhr über Endpoints, Netzwerke, Cloud-Dienste und Firewalls hinweg. Es ergänzt das Patchen und ersetzt es nicht.

Und wer wissen möchte, ob die eigene PHP-Landschaft so gut gepatcht ist, wie die Inventarliste behauptet, findet es mit einem Penetrationstest der aus dem Internet erreichbaren Systeme heraus: Er zeigt, was ein Angreifer tatsächlich erreicht. Ein Patch-Vermerk ist eine Behauptung, ein Test ist ein Beleg. Ob Sie die Sicherheit selbst betreiben, gezielte Unterstützung dazunehmen oder sie ganz abgeben: Wir passen die Hilfe an Ihr Team an.

Quellen: PHP security advisory, CISA Known Exploited Vulnerabilities catalog, UK NCSC: critical security issue affecting PHP. Berichte: AWS Security Blog: PHP2Shell exploitation prior to public disclosure, Zscaler ThreatLabz: CVE-2026-109618 and CVE-2026-109619.

Kontaktieren Sie uns für weitere Informationen.

Dieser Beitrag kann KI-generierte Bilder, Grafiken und/oder Fotos enthalten.