Am Dienstagabend, 20. Oktober 2026, kündigt das PHP Security Team für den nächsten Tag ein kritisches Update an. Es gibt keine Details, nur zwei Kennungen und eine Bewertung von 9.2 nach CVSS v4.0. Am Mittwoch um 14 Uhr UTC erscheint das Release. Kurz darauf hat die Lücke einen Namen: PHP2Shell. Writeups sind online, ein Exploit Tool ist öffentlich, und Sicherheitsforscher melden erste Angriffe.
Zwischen Ankündigung und öffentlichem Exploit lag kaum mehr als ein Tag. Dieser Beitrag erklärt, was hinter PHP2Shell steckt, warum die Lücke so ernst ist und worauf es beim PHP Update ankommt.
Ihr wollt PHP2Shell schnell vom Tisch haben?
Wir helfen beim Patchen eurer PHP Projekte, sichern das Update mit Tests ab und finden einen Weg für alte Versionen, für die es keinen offiziellen Fix gibt.
Was hinter PHP2Shell steckt
PHP2Shell steht für zwei Lücken im Speichermanagement von PHP, CVE-2026-109618 und CVE-2026-109619. Jede für sich ist schon ernst. Kombiniert ergeben sie einen Angriff, der ohne Login funktioniert und am Ende Befehle auf dem Server ausführt. Daher der Name.
Ein Vergleich mit einem Hotel macht das greifbar. Die erste Lücke ist ein Zimmer, das mitten in der Vorbereitung verlassen wird. Das Bett ist halb bezogen, an der Tür hängt aber schon das Schild „fertig“. So verhält sich PHP, wenn ein Request den Speicher ausreizt. Die Verarbeitung bricht ab, und beim Aufräumen behandelt PHP die halb aufgebauten Daten als gültig.
Die zweite Lücke ist ein Zimmer, das zwischen zwei Gästen nicht richtig geräumt wird. Daten eines Requests bleiben im Worker zurück, obwohl ihr Speicher schon freigegeben ist. Der nächste Request im selben Worker greift darauf zu. Wer beide Fehler verbindet, bringt PHP dazu, fremden Code auszuführen. Die technischen Details stehen im offiziellen Security Advisory des PHP Teams.
Warum der PHP2Shell Exploit so gefährlich ist
Die meisten Sicherheitslücken stecken in einem Plugin, einer Bibliothek oder einem Framework. PHP2Shell sitzt eine Ebene tiefer, im Interpreter selbst. Ob WordPress, Shopware, Symfony oder Laravel darauf läuft, spielt keine Rolle. Die Forscher von Sansec berichten von Angriffen auf eine lange Liste verbreiteter Systeme, darunter WordPress, Magento, Drupal, Nextcloud und phpMyAdmin.
Das höchste Risiko sieht das PHP Team bei Apache mit mod_php. Dort startet der Angriff, bevor der Anwendungscode überhaupt geladen ist. Validierung oder Firewall Regeln im Framework kommen gar nicht erst zum Zug. PHP-FPM ist dadurch nicht automatisch sicher. Laut Rapid7 gelang die Code Ausführung in der Forschung auch dort, über einen anderen Weg.
Zwei weitere Eigenschaften machen PHP2Shell besonders heikel. Ein erfolgreicher Angriff bleibt oft unbemerkt, weil der Worker dabei nicht abstürzt. Außerdem beschreibt Sansec, dass über die Lücke Speicherreste anderer Requests im Session Cookie zurückkommen können. Darin können Passwörter, Session Tokens und API Keys stecken. Laut watchTowr wurden erste Angriffe bereits am Tag des Releases in ihrem Honeypot Netzwerk beobachtet.
Typische Stolpersteine beim PHP Update
Die Lösung ist das Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Das PHP Team stellt klar, dass es keine vollständige Absicherung ohne Update gibt. In der Praxis läuft das nicht überall glatt.
Ein häufiger Stolperstein steckt im Dockerfile. Viele Projekte nutzen bewegliche Tags wie php:8.2-apache. Die offiziellen Images werden aber pro Plattform nacheinander gebaut. Ist das neue Image für die eigene Architektur noch nicht da, baut die Pipeline ohne Fehler die alte, verwundbare Version. Ein fester Tag wie php:8.2.35-apache verhindert das. Fehlt das Image noch, bricht der Build mit einer klaren Meldung ab, und ein späterer Neustart reicht.
Auch PHP Extensions können Probleme machen. Mit dem neuen Base Image wird jede Extension neu kompiliert. Scheitert dabei pecl install, etwa bei imagick, hilft der Docker PHP Extension Installer. Zusätzlich lieferte der PECL Server in Builds zeitweise HTTP 500 Fehler. Die komplette Anleitung mit Befehlen, Notfall Einstellungen und Lösungen für PHP 8.1 und älter steht in unserem Beitrag zur PHP Sicherheitslücke Oktober 2026.
Am schwierigsten sind alte Projekte. PHP 8.1 und älter bekommen vom PHP Projekt kein Update mehr, nur Quellcode Backports und Fixes einzelner LTS Anbieter. Hier zeigt sich, was technische Schulden kosten. Wer jetzt ein PHP Update plant, prüft vorher mit PHPCompatibility, was im Code bricht.
Was PHP2Shell für eure Update Strategie bedeutet
PHP2Shell zeigt vor allem eins: Geschwindigkeit entscheidet. Liegen zwischen Release und ersten Angriffen nur Stunden, reicht ein Prozess mit Ticket, Freigabe und Wartungsfenster in der nächsten Woche nicht aus. Tools wie Renovate schlagen neue PHP Versionen und Docker Images automatisch vor. Laufen danach PHPUnit, PHPStan und E2E Tests in der Pipeline, wird ein Sicherheitsupdate zum normalen Merge.
Genauso wichtig ist das Danach. Ein Update schließt die Lücke, entfernt aber keine Hintertür, die vorher eingebaut wurde. Lief ein öffentliches System ungepatcht, gehören ein Blick in Logs und Webroot sowie neue Passwörter, API Keys und App Secrets dazu. Auffällig sind sehr große POST Requests, Fatal Errors ohne zugehöriges Skript und PHP Dateien, die niemand bewusst angelegt hat.
Sicherheit entsteht dabei nie durch ein einzelnes Werkzeug. Die OWASP Top 10 geben den Rahmen vor, Composer Audit prüft die Abhängigkeiten, und eine Pipeline mit Tests macht Updates zur Routine. PHP2Shell wird nicht die letzte Lücke dieser Art sein. Entscheidend ist, wie schnell ein Team beim nächsten Mal reagieren kann.
Beim nächsten Sicherheitsupdate entspannt bleiben
Wir bringen eure PHP Projekte auf eine Version mit Support und bauen eine Pipeline, die Sicherheitsupdates schnell und abgesichert ausrollt. Auch für alten Code, den keiner mehr anfassen will.
Das Kennenlernen ist kostenlos. Danach schätzen wir den Aufwand und rechnen transparent nach Minuten ab.
