PHP2Shell: Kritische PHP-Lücken, was Magento-Shops jetzt tun müssen

Am 21. Oktober 2026 um 14:00 UTC hat das PHP-Projekt außerplanmäßige Sicherheitsupdates für alle unterstützten Versionen veröffentlicht: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie schließen zwei kritische Lücken, über die Angreifer ohne Login eigenen Code auf dem Server ausführen können. Das PHP-Projekt schreibt dazu selbst: Alle PHP-Nutzer sollen sofort updaten.

Für Magento-Shops ist das unangenehm, weil die Lücken nicht in Magento stecken, sondern eine Ebene darunter, im PHP-Kern. Ein sauber gepatchter Shop auf Magento 2.4.9 ist genauso angreifbar wie ein veralteter. Laut Sansec wurde eine Remote Code Execution ohne Login gegen Magento 2.4.9 bereits bestätigt.

Unser Stand: Alle von CopeX betreuten Server haben wir noch am 21. Oktober abgesichert, indem wir die Regeln unserer Web Application Firewall (WAF) aktualisiert haben. Damit werden die bekannten Angriffsmuster abgefangen, bevor sie PHP erreichen. Die WAF ist aber, wie weiter unten beschrieben, eine Überbrückung. Der eigentliche Fix ist das PHP-Update.

Was passiert ist

Name	PHP2Shell
CVEs	CVE-2026-109618 (RCE via OOM corruption), CVE-2026-109619 (RCE via stale global state)
Schweregrad	Critical, CVSS v4.0 9.2 je Lücke
Angriff	Über das Netzwerk, ohne Login, ohne Zutun eines Nutzers
Betroffen	Alle PHP-Versionen vor 8.2.35, 8.3.36, 8.4.27 und 8.5.12; laut Sansec reicht der betroffene Code bis PHP 5.4 zurück
Gefixt in	PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
Advisories	GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp

Die beiden Lücken in einfachen Worten:

• CVE-2026-109618, Speicherfehler beim Out-of-Memory: Geht PHP mitten in der Verarbeitung eines Requests der Speicher aus, bricht PHP ab, während interne Daten erst halb aufgebaut sind. Beim Aufräumen behandelt PHP diese kaputten Daten dann als gültig. Angreifer können den Speichermangel gezielt auslösen, etwa über präparierte Multipart-Requests, die im PHP-Inneren viel mehr Speicher belegen als auf dem Weg übers Netz.
• CVE-2026-109619, Altlasten zwischen zwei Requests: Ein PHP-Worker bearbeitet nacheinander viele Requests. Unter bestimmten Bedingungen bleibt nach einem fehlgeschlagenen Request ein Verweis auf bereits freigegebenen Speicher zurück. Der nächste Request auf demselben Worker greift darauf zu, bevor PHP alles neu initialisiert hat.

Beide Wege führen zu sogenannten Use-after-free-Fehlern, und beide lassen sich zu einer Codeausführung auf dem Server ausbauen.

Wer ist betroffen?

Laut PHP-Projekt jede PHP-Installation, die Web-Requests beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Unterschiede gibt es beim Risiko:

• Apache mit mod_php: höchstes Risiko. Hier wurde ein Angriff gezeigt, der ausgelöst wird, bevor überhaupt Anwendungscode läuft, mit Standard-Einstellungen.
• PHP-FPM: Das typische Magento-Setup ist ebenfalls betroffen, wenn auch auf anderen Wegen. Sansec beschreibt, dass ein schwerer Fehler nach einem erfolgreichen Request-Start, etwa in unserialize() oder session_start(), einen beschädigten Zustand in einem weiterlaufenden Worker hinterlässt.
• PHP 8.1 und älter: Diese Versionen bekommen vom PHP-Projekt keinen offiziellen Fix mehr. Für 7.4, 8.0 und 8.1 hat das PHP-Security-Team zwar minimale Quellcode-Backports bereitgestellt, die muss man aber selbst kompilieren.

Die Lage hat sich schnell verschärft. Details sind schon am 20. Oktober vorzeitig durchgesickert, Cloudflare hat am 21. Oktober um 07:43 UTC erste Angriffe gemeldet, also Stunden vor dem offiziellen Release. Mit PHP2Shell kursiert inzwischen auch ein öffentliches Exploit-Werkzeug, das beide Lücken zu einem Angriff ohne Login verkettet. Sansec rechnet mit massenhafter Ausnutzung.

Schritt 1: PHP-Version prüfen und updaten

Versionslinie	Sichere Version	Hinweis
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35	End of Life am 31. Dezember 2026, Upgrade planen
PHP 8.1 und älter	kein offizieller Fix	Backport vom LTS-Anbieter oder Upgrade

Prüfe die Version, mit der dein Webserver PHP ausführt, nicht nur die auf der Kommandozeile. Auf vielen Servern sind beide unterschiedlich:

# Version der Kommandozeile
php -v

# Version von PHP-FPM (Name je nach Distribution, z. B. php-fpm8.3)
php-fpm -v

Wer die Pakete aus einer Linux-Distribution bezieht, bekommt das Update über die üblichen Paketquellen; die Distributionen haben die Patches laut PHP-Projekt vorab erhalten. Ausnahme: Wer auf das ehrenamtlich gepflegte Repository rpms.remirepo.net setzt, bekommt dort am 21. Oktober noch kein Update. Das PHP-Projekt rät in diesem Fall, auf die Pakete der Distribution umzusteigen oder selbst zu kompilieren.

Nach dem Update gilt: alle PHP-Worker neu starten, also PHP-FPM bzw. Apache neu laden. Danach einmal durch den Shop klicken und eine Testbestellung durchführen.

Schritt 2: Überbrücken, wenn das Update noch nicht geht

Kann ein Server nicht sofort aktualisiert werden, nennt das PHP-Projekt Maßnahmen, die einzelne Angriffswege versperren. Es betont aber ausdrücklich: Keine davon macht eine Installation sicher.

Gegen CVE-2026-109619:

• session.upload_progress.enabled=0 setzen und alle Worker neu starten. Der Wert muss in php.ini, der FPM-Pool-Konfiguration oder der Webserver-Konfiguration stehen. ini_set() und .user.ini wirken zu spät.
• Unter PHP 8.5 zusätzlich fatal_error_backtraces=0.

Gegen CVE-2026-109618:

• memory_limit=-1 fest setzen, so dass die Anwendung es nicht überschreiben kann, etwa per php_admin_value im FPM-Pool.
• post_max_size niedrig halten und Limits für Request-Größe, Anzahl der Felder und Multipart-Teile schon am Webserver oder Proxy erzwingen.

Für einen Magento-Server mit PHP-FPM heißt das zum Beispiel in jeder Pool-Datei:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1

Drei Punkte, die bei Magento in der Praxis wichtig sind:

• memory_limit = -1 hat eine Kehrseite. Ein einzelner Request kann dann den gesamten Arbeitsspeicher des Servers belegen. Den Speicherverbrauch also eng beobachten und das Limit nach dem Update wieder zurücksetzen.
• Multipart komplett zu blockieren, bricht Uploads. Davon sind auch die Produktbilder im Magento-Admin betroffen. Laut Sansec schicken manche Shops zudem Warenkorb- oder Checkout-Formulare als Multipart. Wer solche Regeln setzt, muss danach eine Testbestellung machen.
• Der Magento-Wartungsmodus hilft nicht. PHP verarbeitet den Request, bevor Magento den Wartungsmodus prüft. Wer den Shop vom Netz nehmen will, stoppt PHP-FPM und liefert eine statische Seite direkt vom Webserver aus.

Schritt 3: WAF-Regeln aktualisieren

Eine Web Application Firewall sitzt vor dem Shop und prüft Requests, bevor sie PHP erreichen. Bei PHP2Shell ist das besonders wertvoll, weil der Angriff unterhalb von Magento passiert: Kein Magento-Modul und keine Erweiterung kann ihn abfangen, PHP ist zu diesem Zeitpunkt schon getroffen.

Cloudflare hat ab dem 21. Oktober um 03:02 UTC Regeln für alle Kunden ausgerollt, auch im kostenlosen Plan. Gleichzeitig schreibt Cloudflare offen, dass die Regeln laufend nachgeschärft werden, weil Angreifer ihre Payloads verändern, und dass PHP trotzdem aktualisiert werden muss.

Wichtig, falls dein Shop hinter Cloudflare steht: Die Regeln greifen nur, wenn der Server direkt aus dem Internet nicht erreichbar ist. Lässt der Origin-Server Verbindungen von überall zu, umgehen Angreifer die WAF einfach. Sperre HTTP und HTTPS auf dem Server deshalb für alles außer den IP-Bereichen von Cloudflare.

So haben wir es bei CopeX gemacht: Noch am 21. Oktober haben wir die WAF-Regeln auf allen von uns betreuten Servern aktualisiert. Damit sind die Shops gegen die bekannten Angriffsmuster abgesichert, während die PHP-Updates eingespielt werden.

Anzeichen eines Angriffs

Weil der Angriff in PHP selbst läuft, zeigen die Magento-Logs oft wenig. Sansec nennt diese Signale auf Server-Ebene:

• auffällige Multipart-Requests, gefolgt von memory_limit-Fehlern oder wiederholten HTTP-500-Antworten
• ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies in den Antworten
• unerklärliche Neustarts von PHP-Workern
• eine Häufung von PHP-Fatal-Errors rund um memory_limit, vor allem bei Multipart-Requests

Taucht davon etwas in den Logs auf, reicht das Update allein nicht mehr. Dann gilt derselbe Ablauf wie bei jeder Kompromittierung: Server isolieren, prüfen, aus sauberer Quelle neu aufsetzen und alle Zugangsdaten rotieren. Wie das bei Magento konkret aussieht, beschreiben wir in unserem Leitfaden zu StyleSmuggler.

Zeitleiste

Zeitpunkt (UTC)	Ereignis
11.08.2026	Erste Lücke wird an das PHP-Projekt gemeldet
20.10.2026	PHP kündigt das Sicherheitsrelease für den Folgetag an, Details sickern vorzeitig durch
21.10.2026, 03:02	Cloudflare rollt WAF-Regeln für alle Kunden aus
21.10.2026, 07:43	Cloudflare meldet erste Angriffe auf PHP-Seiten
21.10.2026, 14:00	PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35

Was das für Magento-Betreiber heißt

Nach StyleSmuggler und BlockStrap ist PHP2Shell die dritte kritische Lücke innerhalb von sieben Wochen, und die erste, die gar nicht in Magento steckt. Das zeigt, warum Shop-Sicherheit mehr ist als Magento-Patches: PHP, Webserver, WAF und Betriebssystem gehören genauso dazu.

Zwei Dinge entscheiden in so einer Lage, wie schnell du sicher bist. Erstens, ob jemand die Meldung sofort sieht und reagiert. Zweitens, ob dein Server auf einer unterstützten PHP-Version läuft, für die es überhaupt ein Update gibt. Wer noch auf PHP 8.1 oder älter steht, hat heute kein reguläres Update-Ziel. PHP 8.2 folgt am 31. Dezember 2026.

Wenn du nicht sicher bist, welche PHP-Version dein Shop nutzt oder ob dein Server abgesichert ist, melde dich bei uns. Mit unserem Patch-Service übernehmen wir das Monitoring und die Updates für deinen Magento-Shop laufend, auf Wunsch inklusive Hosting.

Quellen: PHP Security Advisory vom 21. Oktober 2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, Sansec: PHP2Shell, Cloudflare: Schutz gegen die PHP-Lücken