PHP-Sicherheitslücke „php2shell“: Was WooCommerce- und Magento-Shops jetzt tun müssenPHP-Sicherheitslücke „php2shell“: Was WooCommerce- und Magento-Shops jetzt tun müssen

Seit dem 21. Oktober 2026 gibt es Notfall-Updates für PHP. Zwei kritische Sicherheitslücken – unter dem Namen „php2shell“ bekannt – erlauben es Angreifern, ohne Login eigenen Code auf einem Webserver auszuführen. Betroffen ist praktisch jede Website und jeder Shop, der auf PHP läuft: WordPress mit WooCommerce, Magento, Shopware, Joomla, Drupal. Hier steht, was passiert ist, wie die Lücken gefunden wurden, was du jetzt tun musst – und warum ein Update von WordPress das Problem nicht löst.

Was ist passiert?

PHP ist die Programmiersprache, auf der ein großer Teil des Internets läuft – unter anderem WordPress und damit WooCommerce, außerdem Magento, Shopware und viele andere Systeme. Ruft jemand eine Seite deines Shops auf, verarbeitet ein PHP-Prozess auf dem Server diese Anfrage.

Genau in diesem PHP-Kern steckten zwei Fehler im Umgang mit dem Arbeitsspeicher (CVE-2026-109618 und CVE-2026-109619). Das PHP-Team bewertet beide mit 9,2 von 10 Punkten. Laut der offiziellen Sicherheitsmitteilung sind alle PHP-Installationen gefährdet, die Webanfragen beantworten – egal ob PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Am höchsten schätzt das PHP-Team das Risiko bei mod_php ein: Dort gibt es einen nachgewiesenen Angriff, der mit einer einzigen Anfrage auskommt und greift, bevor überhaupt Code deines Shops ausgeführt wird.

Die Ursache, einfach erklärt

Überschreitet eine Anfrage das Speicherlimit (memory_limit), bricht PHP sie hart ab. Passiert das in einem ungünstigen Moment – etwa mitten beim Einlesen eines Datei-Uploads –, bleiben Daten halb fertig im Speicher liegen. Beim Aufräumen behandelt PHP diese Reste trotzdem als gültig (CVE-2026-109618). Bei der zweiten Lücke überlebt interner Zustand einer Anfrage, obwohl der zugehörige Speicher schon freigegeben ist. Die nächste Anfrage an denselben PHP-Prozess greift dann auf diese veralteten Daten zu (CVE-2026-109619).

Wer Anfragen gezielt präpariert, kann darüber Speicher auslesen und am Ende eigenen Code ausführen – mit den Rechten des Webservers. Das heißt: Zugriff auf die Dateien des Shops, auf die Zugangsdaten zur Datenbank und damit auf Kunden- und Bestelldaten. Die Sicherheitsforscher von Sansec weisen außerdem darauf hin, dass sich über die erste Lücke – ähnlich wie 2014 bei „Heartbleed“ – Daten anderer Besucher aus dem Speicher lesen lassen: Passwörter, Sitzungs-Cookies, API-Schlüssel.

Wie die Lücken entdeckt wurden

Gefunden hat die Lücken die Sicherheitsfirma Calif. Nach Angaben von Huntress untersuchte Calif ältere Auffälligkeiten rund um PHPs Speicherlimit noch einmal – im Rahmen von „Patch the Planet“, einem Programm von OpenAI, bei dem verbreitete Open-Source-Software mit KI-Unterstützung und menschlicher Prüfung nach Sicherheitslücken durchsucht wird. Laut dem Zeitplan von Sansec stieß Calif Anfang August auf mehrere Wege zur Codeausführung und meldete den ersten Fehler am 11. August vertraulich an das PHP-Team. Am 24. August folgte eine Meldung von Wiz Research.

Danach lief das übliche Verfahren: Die Lücke bleibt geheim, bis Updates fertig sind, und Linux-Distributionen sowie große Anbieter bekommen die Patches vorab. Dieses Mal ging das schief. Am 20. Oktober tauchte auf Hacker News ein Beitrag zu den beiden Lücken auf. Er wurde zwar gelöscht, Screenshots machten aber schnell die Runde. Das PHP-Team zog die Veröffentlichung daraufhin vor und brachte die Updates am Nachmittag des 21. Oktober heraus.

Da wurde bereits angegriffen: Cloudflare hat nach eigenen Angaben am 21. Oktober um 9:43 Uhr deutscher Zeit erste Angriffe beobachtet – Stunden bevor die Updates verfügbar waren. Inzwischen kursieren öffentliche Beispiel-Exploits. Einzelne Hoster und Websites, etwa das niederländische Technikportal Tweakers, sind vorsorglich offline gegangen. Die US-Cybersicherheitsbehörde CISA, CERT-EU und das britische NCSC rufen zum sofortigen Update auf.

Warum ein WordPress-Update nicht hilft

Das ist der wichtigste Punkt für alle, die einen Shop mit WooCommerce, Magento oder Shopware betreiben: Die Lücke steckt nicht in WordPress, nicht in WooCommerce und nicht in einem Plugin, sondern eine Ebene tiefer – in PHP selbst. Du kannst WordPress, WooCommerce und alle Plugins auf dem neuesten Stand haben und bist trotzdem angreifbar.

Umgekehrt schützt dich auch ein sauber programmierter Shop nicht. Wiz hat Angriffe ohne Login auf WordPress, Drupal und Joomla gezeigt, Sansec nennt aktuelle Versionen von Magento, WordPress, Shopware und vielen weiteren Systemen als angreifbar. Geschlossen wird die Lücke nur durch ein Update von PHP auf dem Server.

Diese PHP-Versionen sind sicher

Was du jetzt tun solltest

1. PHP-Version herausfinden

• WordPress und WooCommerce: im Backend unter Werkzeuge → Website-Zustand → Bericht → Server oder unter WooCommerce → Status bei „PHP-Version“.
• Magento und Shopware: in der Verwaltung deines Hosters oder auf dem Server mit php -v. Achtung: Die Kommandozeile nutzt manchmal eine andere Version als der Webserver – entscheidend ist die Version, mit der die Website läuft.
• Im Zweifel: deinen Hoster fragen. Das geht per Mail und ist in diesen Tagen eine ganz normale Frage.

2. Das Update einspielen (lassen)

Bei klassischem Webhosting aktualisiert der Hoster PHP. Viele Anbieter haben das inzwischen getan – verlass dich trotzdem nicht darauf, sondern lass es dir bestätigen. Hast du im Kundenmenü selbst eine alte Version wie PHP 7.4 oder 8.1 ausgewählt, kommt dort in der Regel keine Korrektur an. Dann musst du auf eine neuere Version umstellen.

Läuft dein Shop auf einem eigenen Server oder VPS: PHP-Pakete aktualisieren und danach PHP-FPM bzw. Apache neu starten – erst mit dem Neustart ist die neue Version aktiv. Wer Pakete aus dem verbreiteten Remi-Repository nutzt, sollte genau hinschauen: Laut CERT-EU gab es dort am Veröffentlichungstag noch keine Updates.

Ein Wechsel von PHP 7.4 oder 8.1 auf 8.3 oder 8.4 ist bei WordPress-Shops nicht immer ein Klick: Ältere Plugins und Themes laufen unter neuen PHP-Versionen manchmal nicht mehr. Mach vorher ein Backup und teste danach den Bestellablauf einmal komplett – von der Produktseite bis zur Bestellbestätigung.

3. Wenn das Update nicht sofort geht

Das PHP-Team nennt Einstellungen, die bekannte Angriffswege erschweren – ausdrücklich aber ohne vollständigen Schutz. Die wichtigsten:

• session.upload_progress.enabled = 0 – in der php.ini oder im FPM-Pool, nicht per ini_set() oder .user.ini. Danach alle PHP-Prozesse neu starten.
• Nur bei PHP 8.5 zusätzlich: fatal_error_backtraces = 0.
• post_max_size klein halten: 8M ohne Datei-Uploads, 32M mit Uploads.
• Eine Web Application Firewall, zum Beispiel von Cloudflare, kann bekannte Angriffsmuster abfangen – ersetzt das Update aber nicht.

Weitere Empfehlungen des PHP-Teams betreffen das Speicherlimit und haben Nebenwirkungen auf den ganzen Server. Die gehören in die Hände von jemandem, der den Server kennt.

Läuft eine nicht mehr unterstützte PHP-Version und ist kein Update möglich, empfehlen CISA und CERT-EU, den Server bis dahin vom Internet zu trennen. Wichtig: Der Wartungsmodus von WordPress reicht dafür nicht, denn PHP verarbeitet die Anfragen trotzdem – und der bekannte Angriff greift, bevor WordPress überhaupt startet. Der Shop muss vor PHP abgeschirmt werden, etwa über den Hoster, eine Firewall oder eine statische Wartungsseite.

4. Prüfen, ob schon jemand drin war

Weil schon vor dem Patch angegriffen wurde, ist mit dem Update allein nicht alles erledigt. Prüfe danach:

• Gibt es Administrator-Konten in WordPress, WooCommerce oder Magento, die du nicht kennst?
• Liegen unbekannte PHP-Dateien im Webverzeichnis? Im Upload-Ordner von WordPress sind PHP-Dateien fast immer ein Warnsignal.
• Gibt es neue Cronjobs oder geplante Aufgaben auf dem Server?
• Sicherheitshalber erneuern: Admin-Passwörter, Datenbank-Passwort und API-Schlüssel, etwa von Zahlungsanbietern und Versanddiensten.
• Bei einem Verdacht: Server isolieren, Logs sichern und Hilfe holen, bevor du aufräumst.

Ist WooCommerce angreifbarer als Shopify?

Meine ehrliche Antwort: Im Alltag ja – aber nicht, weil WordPress schlecht programmiert wäre. Der Kern von WordPress gilt als gut gepflegt. Der Unterschied liegt darin, wer für was verantwortlich ist.

Laut dem Sicherheitsanbieter Patchstack wurden 2025 im WordPress-Umfeld 11.334 neue Sicherheitslücken gemeldet, 42 Prozent mehr als im Vorjahr. 91 Prozent davon steckten in Plugins, 9 Prozent in Themes – im WordPress-Kern selbst nur eine Handvoll. Ein WooCommerce-Shop besteht aber selten nur aus WordPress und WooCommerce, sondern aus vielen Plugins für Zahlung, Versand, Rechtstexte, Bewertungen und Marketing. Jedes davon ist eine Tür, die jemand aktuell halten muss.

Bei WooCommerce und Magento liegt die ganze Kette beim Shopbetreiber oder seinem Hoster: Server, PHP-Version, Datenbank, Shopsoftware, Theme und jede Erweiterung. php2shell zeigt, wie das in der Praxis aussieht: Selbst wer in WordPress alles richtig gemacht hat, muss jetzt eine Ebene tiefer handeln – und dafür erst einmal wissen, wo und wie der Shop überhaupt läuft.

Shopify ist eine gemietete Plattform. Server, Software und Updates betreibt Shopify selbst, zertifiziert nach PCI DSS Level 1, dem höchsten Sicherheitsstandard für Zahlungsdaten. Shopify läuft nicht auf PHP, Shopify-Shops sind von php2shell also nicht direkt betroffen. Und hat die Plattform eine Lücke, schließt Shopify sie für alle Shops gleichzeitig – ohne dass du etwas tun musst.

Aber auch Shopify ist nicht unangreifbar

• Apps: Viele Shopify-Apps laufen auf den Servern ihrer Anbieter – manche davon auf PHP. Eine App mit Zugriff auf Bestell- und Kundendaten kann also durchaus betroffen sein. Ungenutzte Apps zu deinstallieren und bei wichtigen Apps nachzufragen lohnt sich gerade jetzt.
• Zugänge: Bei einer gemieteten Plattform ist dein Login die größte Angriffsfläche. Zwei-Faktor-Anmeldung für alle Konten mit Zugriff auf den Shop sollte selbstverständlich sein.
• Eingebundener Code: Tracking-Skripte und Code-Schnipsel von Dritten im Theme sollten nur aus vertrauenswürdigen Quellen stammen.

Unterm Strich: Ein gut gewarteter WooCommerce-Shop kann sicher sein. Aber „gut gewartet“ kostet laufend Zeit oder Geld – und genau daran hapert es bei vielen kleinen Shops. Bei Shopify ist die Sicherheit der Plattform im Preis enthalten. Du kümmerst dich um deine Zugänge und deine Apps, nicht um Server und PHP-Versionen.

Die Gelegenheit für einen Wechsel?

Zuerst das Wichtigste: Ein Wechsel ersetzt das Update nicht. Läuft dein Shop heute auf PHP, muss PHP heute aktualisiert werden. Ein Umzug dauert Wochen, nicht Stunden.

Danach lohnt sich aber die Frage, ob du dich weiter selbst um Server, PHP und Plugins kümmern willst. Vor allem, wenn dein Shop noch auf PHP 7.4 oder 8.1 läuft, weil ein älteres Plugin nichts Neueres verträgt: Dann steht ohnehin ein größerer Umbau mit Tests und Risiko an. Ab da ist der Schritt zu einem anderen System oft kleiner, als er wirkt.

Shopify – für die meisten Shops

Für die meisten kleinen und mittleren Shops ist Shopify der einfachste Weg zu einem Shop, bei dem du dich nicht um die Technik kümmern musst. Als offizieller Shopify Partner ziehe ich Shops von WooCommerce oder Magento um: Produkte, Kunden, Bestellungen und vor allem die Adressen deiner Seiten. Alte URLs leite ich per 301-Weiterleitung um, damit deine Google-Platzierungen erhalten bleiben.

Slate™ – dein eigenes Shopsystem

Wenn du keine Plattform-Gebühren zahlen willst oder Funktionen brauchst, die Shopify nicht hergibt, gibt es mein eigenes Shopsystem Slate™. Es läuft auf moderner Technik (Next.js) – ohne PHP und ohne Plugins von Drittanbietern. Die Daten liegen in deiner eigenen Datenbank, der Admin-Login ist mit Zwei-Faktor-Anmeldung geschützt und gehostet wird in der EU. Updates und Wartung übernehme ich auf Wunsch.

Ehrlicherweise gehört dazu: Auch moderne Technik ist nicht unverwundbar. Ende 2025 traf die Lücke „React2Shell“ Anwendungen auf Basis von React und Next.js. Entscheidend ist, wer sich kümmert und wie schnell. Mit Wartung spiele ich solche Updates für dich ein, statt darauf zu warten, dass du selbst davon erfährst. Mehr zu Slate™: bergisches-digitalwerk.de/slate

Und bei mir?

Kurz in eigener Sache: Meine Website und die Dienste dahinter laufen nicht auf PHP. Ich habe Hosting, Mail, Code-Verwaltung und alle weiteren Dienste geprüft – nichts davon ist von php2shell betroffen. Die Shopify- und Slate™-Shops, die ich betreue, laufen ebenfalls nicht auf PHP.

Du betreibst einen Shop mit WooCommerce, Magento oder Shopware und bist unsicher, ob du betroffen bist oder ob das Update sauber durch ist? Schreib mir über bergisches-digitalwerk.de/kontakt – ich sage dir ehrlich, was zu tun ist.

Marcel WeryShopify Partner · baut Online-Shops und bringt sie mit SEO und Werbung nach vorn. Mehr über mich