PHP2Shell: Kritische PHP-Lücken bedrohen fast jede Website – was Betreiber jetzt tun müssen

Am 21. Oktober 2026 hat das PHP-Projekt ein Notfall-Update veröffentlicht. Es schließt zwei kritische Lücken im PHP-Kern, die unter dem Namen PHP2Shell bekannt geworden sind. Angreifer können damit ohne Login eigenen Code auf dem Webserver ausführen. Betroffen ist nicht eine einzelne Software, sondern PHP selbst. Damit trifft es WordPress, TYPO3, Shopware, Magento, Drupal, Joomla und jede eigene PHP-Anwendung gleichermaßen.

Ich fasse hier zusammen, was passiert ist, wer betroffen ist und was Website-Betreiber heute noch erledigen sollten. Der Artikel richtet sich an Unternehmen und Selbstständige, die eine Website oder einen Shop betreiben, nicht nur an Administratoren.

Das Wichtigste in Kürze

• Zwei Lücken: CVE-2026-109618 und CVE-2026-109619, beide vom PHP-Sicherheitsteam mit CVSS 9.2 von 10 bewertet.
• Betroffen: Praktisch jede PHP-Version seit 5.4, also alles aus den letzten zehn Jahren. Standardkonfigurationen sind angreifbar.
• Behoben in: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
• PHP 8.1 und älter: Bekommt vom PHP-Projekt kein Update mehr. Wer darauf läuft, braucht ein Backport des Hosters oder ein Upgrade.
• Angriffe laufen: Cloudflare meldete erste Angriffsversuche bereits am Morgen des 21. Oktober, noch vor dem Patch. Exploit-Code kursiert öffentlich.
• Einzige vollständige Lösung: PHP aktualisieren und alle PHP-Prozesse neu starten. Alle anderen Maßnahmen sind nur Notbehelf.

Was genau ist PHP2Shell?

PHP2Shell ist der Name für eine Angriffskette aus zwei Fehlern in der Speicherverwaltung von PHP. Beide hängen damit zusammen, wie PHP mit schweren Fehlern umgeht, vor allem wenn einem Request der Arbeitsspeicher ausgeht.

Vereinfacht gesagt: Wenn PHP mitten in einem Request wegen Speichermangel abbricht, räumt es nicht sauber auf. Interne Daten bleiben halb fertig liegen oder zeigen auf bereits freigegebenen Speicher. Der nächste Request, den derselbe PHP-Prozess bearbeitet, findet diese Reste vor und verwendet sie weiter. Ein Angreifer kann diesen Zustand gezielt herbeiführen und ausnutzen.

CVE-2026-109618: Speicherleck und Code-Ausführung über Datei-Uploads

Diese Lücke steckt in der Verarbeitung von Multipart-Requests, also dem Format, das Browser für Formulare mit Datei-Upload verwenden, und in der Fortschrittsanzeige für Uploads der Session-Erweiterung. Ein manipulierter Upload bringt PHP in den fehlerhaften Zustand. Ein weiterer Request kann dann Speicherinhalte des Prozesses auslesen, die im PHPSESSID-Cookie der Antwort landen.

Was in diesem Speicher liegt, ist brisant: Passwörter aus vorherigen Logins, Session-Tokens, API-Schlüssel, Datenbank-Zugangsdaten, unter Umständen sogar private TLS-Schlüssel. Das funktioniert laut den Entdeckern auch, wenn die Anwendung Sessions gar nicht nutzt. In Kombination mit dem zweiten Fehler wird daraus eine Code-Ausführung.

CVE-2026-109619: Veralteter Zustand überlebt den Request

Der zweite Fehler betrifft die Fehlerbehandlung des PHP-Interpreters selbst und den OPcache, der kompilierten Code zwischen allen PHP-Prozessen teilt. Nach einem Speicherfehler überlebt interner Zustand den Request, obwohl der zugehörige Speicher schon freigegeben wurde. Der nächste Request desselben Prozesses nutzt diesen Zustand, bevor PHP ihn zurücksetzt. Über den OPcache kann sich die Korruption sogar auf andere Prozesse ausbreiten.

Das PHP-Team schreibt, dass das Risiko bei Apache mit mod_php am höchsten ist. Dort kann ein Angreifer den Fehler auslösen, bevor überhaupt Anwendungscode läuft. PHP-FPM ist aber ebenfalls betroffen.

Wer hat die Lücken gefunden?

Entdeckt hat sie das Forschungsteam von Wiz im August 2026, und zwar mit Hilfe von KI-Modellen, die den PHP-Quellcode systematisch nach Speicherfehlern durchsucht haben. Innerhalb von zwei Tagen hatten die Forscher funktionierende Angriffe gegen aktuelle WordPress- und Drupal-Installationen, später auch gegen Joomla und Magento 2.4.9. Gemeldet wurde das am 24. August an das PHP-Sicherheitsteam.

Die Veröffentlichung war für den 21. Oktober um 16 Uhr deutscher Zeit geplant. Am Tag davor sickerten Details vorzeitig durch, weshalb das PHP-Team die Patches vorgezogen hat. Die Linux-Distributionen hatten die Korrekturen vorab erhalten. Debian, Ubuntu, SUSE und cPanel lieferten noch am selben Tag Pakete aus.

Bemerkenswert ist, dass diese Fehler seit PHP 5.4 im Code stecken, also seit 2012. Gefunden wurden sie erst, als KI-gestützte Werkzeuge gezielt danach gesucht haben. Das ist ein Vorgeschmack darauf, wie sich die Sicherheitsforschung gerade verändert, und zwar auf beiden Seiten.

Bin ich betroffen?

Mit hoher Wahrscheinlichkeit ja, wenn Ihre Website oder Ihr Shop mit PHP läuft. Das gilt für:

• WordPress und WooCommerce
• TYPO3
• Shopware 5 und 6
• Magento und Adobe Commerce
• Drupal, Joomla, Contao, Neos
• Laravel- und Symfony-Anwendungen
• Nextcloud, Matomo, Moodle und andere selbst gehostete PHP-Software

Es spielt keine Rolle, ob Ihre Anwendung selbst fehlerfrei ist oder alle Plugins aktuell sind. Die Lücke liegt unterhalb der Anwendung, in PHP selbst. Einen sauberen Shop auf einem ungepatchten PHP zu betreiben, ist wie eine gesicherte Wohnungstür in einem Haus ohne Haustür.

So prüfen Sie Ihre PHP-Version

Bei einem Hosting-Paket finden Sie die PHP-Version im Kundenmenü des Hosters, meist unter PHP-Einstellungen oder PHP-Version. Auf einem eigenen Server reicht ein Befehl:

Vorsicht: Die Kommandozeile zeigt nicht immer dieselbe Version wie der Webserver. Zuverlässiger ist eine kleine Datei mit folgendem Inhalt, die Sie kurz aufrufen und danach sofort wieder löschen:

Sicher sind nur diese Versionen oder neuer: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Zeigt der Server 8.1 oder älter, bekommen Sie vom PHP-Projekt keinen Patch mehr. Dann gibt es zwei Wege: Entweder Ihr Hoster oder Ihre Distribution liefert ein Backport, oder Sie müssen auf eine unterstützte Version wechseln. Das PHP-Team hat außerdem minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1 veröffentlicht, für alle, die PHP selbst bauen.

Ein Hinweis für Nutzer des Remi-Repositorys unter RHEL, Rocky und Alma: Dort gab es am Patch-Tag noch keine aktualisierten Pakete. Das PHP-Team empfiehlt, auf die Pakete der Distribution zu wechseln oder aus dem Quellcode zu bauen.

Was jetzt zu tun ist

Schritt 1: PHP aktualisieren

Das ist der einzige vollständige Schutz. Alles andere verringert nur das Risiko. Auf Debian und Ubuntu mit den Paketen der Distribution:

Wichtig ist der Neustart aller PHP-Prozesse. Ein laufender Worker verwendet weiter den alten Code, bis er beendet wird. Bei Docker-Setups heißt das: neues Image ziehen und Container neu erstellen. Die offiziellen PHP-Images auf Docker Hub sind aktualisiert.

Bei Shared Hosting übernimmt der Hoster das Update. Die großen deutschen Anbieter haben noch am 21. Oktober mit dem Ausrollen begonnen. Prüfen Sie trotzdem selbst nach, ob Ihre Version schon stimmt, und fragen Sie beim Support nach, wenn nicht.

Schritt 2: Wenn ein sofortiges Update nicht möglich ist

Manchmal geht das Update nicht sofort, etwa weil die Anwendung noch nicht mit einer neueren PHP-Version getestet ist. Dann empfiehlt das PHP-Team Übergangsmaßnahmen. Sie machen die Installation nicht sicher, verringern aber die Angriffsfläche. Alle Einstellungen gehören in die php.ini oder in die FPM-Pool-Konfiguration, nicht in eine .user.ini oder in ini_set(), weil sie vor der Request-Verarbeitung greifen müssen. Danach alle Worker neu starten.

Einige Erläuterungen dazu:

• memory_limit = -1: Entfernt die Speichergrenze, die der Angreifer gezielt auslöst. Das klingt gefährlich, ist aber genau die Empfehlung des PHP-Teams. Setzen Sie stattdessen eine Grenze auf Container- oder cgroup-Ebene, die nur den betroffenen Prozess beendet. Nach dem Patch die alte Grenze wieder einsetzen.
• post_max_size und upload_max_filesize: Klein halten. 8M, wenn keine Uploads gebraucht werden, 32M, wenn doch. Die Upload-Größe muss unter post_max_size liegen.
• session.upload_progress.enabled = 0: Schaltet die Fortschrittsanzeige für Uploads ab, die kaum eine Anwendung nutzt.
• fatal_error_backtraces = 0: Nur für PHP 8.5 relevant.

Zusätzlich hilft es, Multipart-Requests am Webserver oder an der Firewall zu begrenzen oder ganz zu blockieren. Das unterbindet allerdings alle Datei-Uploads, etwa Produktbilder im Shop-Backend. Für eine Nacht bis zum Update ist das in vielen Fällen vertretbar. Wer Cloudflare vor der Website hat, bekommt dort inzwischen auch im kostenlosen Tarif passende WAF-Regeln, allerdings nur für den Verkehr, der tatsächlich über Cloudflare läuft.

Was nicht hilft: Der Wartungsmodus von WordPress, TYPO3 oder Shopware. PHP verarbeitet den Request, bevor die Anwendung überhaupt startet. Wer eine Seite wirklich vom Netz nehmen will, braucht eine statische Wartungsseite direkt vom Webserver.

Schritt 3: Nach dem Update prüfen, ob etwas passiert ist

Da Exploit-Code öffentlich kursiert und erste Angriffe vor dem Patch beobachtet wurden, lohnt ein Blick in die Logs. Hinweise auf Angriffsversuche sind:

• Ungewöhnliche Multipart-Requests, gefolgt von Fehlern wegen Speicherlimit im PHP-Log
• Gehäufte HTTP-500-Antworten in kurzer Zeit
• Unerwartet große oder seltsam aufgebaute PHPSESSID-Cookies in den Antworten
• PHP-Worker, die ohne erkennbaren Grund abstürzen und neu starten

Gibt es solche Spuren, sollten Sie von einem Einbruch ausgehen, bis das Gegenteil bewiesen ist. Dann heißt es: Passwörter, API-Schlüssel und Datenbank-Zugangsdaten tauschen, das Dateisystem auf fremde Dateien prüfen und im Zweifel aus einem sauberen Backup neu aufsetzen. Da CVE-2026-109618 Speicherinhalte preisgibt, können auch Zugangsdaten abgeflossen sein, ohne dass eine Datei verändert wurde.

Was das für WordPress, TYPO3 und Shopware heißt

WordPress: Die Entdecker haben die Code-Ausführung gegen ein aktuelles WordPress ohne Login nachgewiesen. Es gibt kein WordPress-Update, das hilft, weil das Problem nicht in WordPress liegt. Zuständig ist der Hoster beziehungsweise der Server-Administrator.

TYPO3: Gleiches Bild. TYPO3 13 und 14 laufen auf PHP 8.2 bis 8.5, alle vier Zweige haben Patches. Wer noch TYPO3 11 oder 12 auf PHP 8.1 betreibt, hat jetzt einen weiteren handfesten Grund, das Upgrade nicht länger zu verschieben.

Shopware 6: Shopware 6.6 und 6.7 laufen auf PHP 8.2 oder neuer, auch hier reicht das PHP-Update. Shops sind ein besonders lohnendes Ziel, weil im Speicher des PHP-Prozesses Zahlungsdaten und API-Schlüssel zu Zahlungsanbietern liegen können. Nach dem Update sollte man einen Testkauf machen, damit die Checkout-Strecke weiterhin funktioniert, vor allem wenn Multipart-Requests zwischenzeitlich blockiert waren.

Shopware 5 und ältere Magento-Versionen: Laufen oft noch auf PHP 7.4 oder 8.1 und bekommen keinen offiziellen Patch. Hier ist das Risiko am größten.

Ein Blick über den Tag hinaus

PHP 8.2 bekommt nur noch bis zum 31. Dezember 2026 Sicherheitsupdates. Wer heute auf 8.2 patcht, sollte das Upgrade auf 8.3 oder 8.4 gleich mit einplanen. In zwei Monaten steht man sonst wieder vor demselben Problem.

Die größere Lehre aus PHP2Shell ist eine andere: Die Fehler lagen vierzehn Jahre unentdeckt in einer der am meisten genutzten Software-Komponenten der Welt. Gefunden wurden sie mit KI-Werkzeugen, die Quellcode in einem Tempo durchsuchen, das Menschen nicht erreichen. Dieselben Werkzeuge stehen Angreifern zur Verfügung. Es ist damit zu rechnen, dass die Zahl solcher Funde in alten, weit verbreiteten Codebasen zunimmt. Eine Website, die man nach dem Launch jahrelang nicht anfasst, ist deshalb kein tragfähiges Modell mehr.

Für Betreiber heißt das konkret: Einen festen Prozess für Updates haben, wissen, welche PHP-Version wo läuft, und einen Ansprechpartner, der im Ernstfall innerhalb von Stunden reagiert. Wer sich nicht sicher ist, ob die eigene Website schon abgesichert ist, kann mich gern kontaktieren. Ich prüfe das kurz und sage Ihnen, was zu tun ist.

Quellen

• Offizielle Ankündigung des PHP-Projekts: www.php.net/archive/2026.php
• Sicherheitshinweise auf GitHub: GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp
• Analyse der Entdecker: www.wiz.io/blog/php2shell-php-rce
• Einschätzung für Shop-Betreiber: sansec.io/research/php2shell

Stand: 21. Oktober 2026. Die Lage entwickelt sich noch, vor allem beim Patch-Status einzelner Hoster und Distributionen. Ich aktualisiere den Artikel, wenn sich Wesentliches ändert.