PHP2Shell: Die PHP-Sicherheitslücke, gegen die kein Shop-Update hilft, und was Du als Händler jetzt prüfst

Seit dem 21. Oktober 2026 warnt das BSI vor zwei kritischen Lücken in PHP, die unter dem Namen PHP2Shell laufen. PHP ist die Programmiersprache unter WordPress, WooCommerce, Shopware, Magento, JTL-Shop und den meisten anderen Shopsystemen, die auf einem eigenen oder gemieteten Server laufen. Das Besondere an dieser Lücke ist, dass sie nicht in einem Plugin oder im Shopsystem steckt, sondern im PHP-Interpreter selbst. Die übliche Routine, also Update einspielen und fertig, greift deshalb diesmal eben nicht.

In diesem Beitrag steht, was PHP2Shell ist, welche Shops betroffen sind, wie Du in fünf Minuten Deine PHP-Version prüfst und was Du heute tun solltest, wenn Dein Shop auf PHP läuft. Danach geht es um die Frage, warum Shopify-Händler diesmal nichts tun müssen, und ob so eine Lücke ein Grund für einen Systemwechsel ist. Ich betreibe selbst keine PHP-Shops für Kunden. Die Angaben zu Versionen, Fristen und Maßnahmen kommen deshalb aus den Quellen, die ich jeweils nenne, vor allem php.net, Sansec, Datadog, CybelAngel und die Hinweise von CERT-EU und CISA.

1Was PHP2Shell ist und warum ein Shop-Update diesmal nicht reicht

PHP2Shell ist der Name für zwei Schwachstellen, die das PHP-Projekt am 21. Oktober 2026 um 16 Uhr deutscher Zeit mit einem außerplanmäßigen Sicherheitsupdate geschlossen hat. Beide sind mit 9,2 von 10 Punkten nach CVSS v4.0 bewertet, beide erlauben Remote Code Execution, also das Ausführen fremden Codes auf dem Server, und beide brauchen dafür keinen Login. Die erste Lücke (CVE-2026-109618) entsteht, wenn PHP mitten in einer Anfrage der Speicher ausgeht und die Aufräumroutine danach halb aufgebaute Daten für gültig hält. Die zweite (CVE-2026-109619) nutzt Reste einer früheren Anfrage, die im selben Arbeitsprozess liegen bleiben.

Der Punkt, der diese Lücke von den üblichen Plugin-Lücken unterscheidet, steht bei Datadog und Sansec gleichlautend: PHP verarbeitet die schädliche Anfrage, bevor der Code des Shops überhaupt läuft. Ein Login-Schutz, ein Sicherheitsplugin, der Wartungsmodus von Shopware oder WordPress, ein frisches WooCommerce-Update, all das sitzt eine Ebene zu hoch. Nach Angaben von Sansec stammt der betroffene Code aus PHP 5.4 von 2012, betroffen sind also praktisch alle PHP-Versionen der letzten 14 Jahre, mit Apache und mod_php genauso wie mit PHP-FPM.

Dazu kommt ein zweiter Effekt, den Sansec beschreibt. Über den Upload-Fortschritt von PHP kann die erste Lücke Inhalte aus dem Arbeitsspeicher an den Angreifer zurückgeben, und zwar im Session-Cookie. In diesem Speicher können Passwörter, Session-Tokens, API-Schlüssel und sogar TLS-Schlüssel aus anderen Anfragen liegen. Deshalb gehört nach dem Update auch das Erneuern von Zugangsdaten auf die Liste, mehr dazu in Abschnitt 4.

PHP2Shell: Vom ersten Fund bis zum Eintrag bei CISA

1. 1. August 2026

   Die Sicherheitsfirma Calif findet mehrere Wege, über PHP fremden Code auszuführen, und meldet den ersten Fehler am 11. August an das PHP-Projekt.

2. 20. Oktober 2026

   Details sickern vor dem geplanten Termin durch, watchTowr bestätigt öffentlich, dass die Lücke echt ist. Das PHP-Projekt zieht das Update um einen Tag vor.

3. 21. Oktober 2026

   PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Cloudflare meldet am Morgen erste Angriffsversuche, das BSI warnt am selben Tag.

4. 26. Oktober 2026

   CISA nimmt beide CVEs in den Katalog der aktiv ausgenutzten Schwachstellen auf, US-Behörden müssen bis zum 29. Oktober patchen.

2Welche Shopsysteme betroffen sind

Die kurze Antwort lautet: jedes System, das auf einem Server mit PHP läuft, den Du oder Dein Hoster betreibt. Ob der Shop-Code aktuell ist, spielt dabei keine Rolle. Sansec formuliert das für Magento, Shopware und WooCommerce ausdrücklich so, und PrestaShop hat laut onlinemarktplatz.de seine Händler darauf hingewiesen, dass weder ein Shop-Update noch ein Modul-Update das PHP-Update ersetzt. Nicht betroffen sind gehostete Systeme, bei denen der Anbieter die Server betreibt und Du keine PHP-Version auswählst.

Zwei Dinge gehen dabei schon mal unter. Erstens zählt jede PHP-Anwendung auf demselben Server, nicht nur der Shop. Ein WordPress-Blog neben dem Shopware-Shop, ein altes Staging-System, ein Kontaktformular, eine selbst gebaute Schnittstelle zur Warenwirtschaft, alles davon ist ein Einstieg. Zweitens ist der Patch je nach Setup an mehreren Stellen fällig. Wer einen eigenen Server betreibt, aktualisiert PHP selbst. Wer ein Shared Hosting oder ein Managed Hosting hat, wählt die PHP-Version meist im Kundenmenü aus oder verlässt sich darauf, dass der Hoster die Updates einspielt. Einige Hoster haben das noch in der Nacht nach der Veröffentlichung erledigt und zusätzlich die Upload-Fortschritt-Funktion von PHP für alle Kunden abgeschaltet. Verlassen würde ich mich darauf aber nicht, lieber einmal nachsehen.

3So prüfst Du Deine PHP-Version in fünf Minuten

Du brauchst eigentlich nur zwei Informationen, nämlich welcher PHP-Zweig auf dem Server läuft und ob die Patch-Version schon drauf ist. Bei WooCommerce findest Du beides im WordPress-Admin unter WooCommerce, Status, Abschnitt Serverumgebung, dort steht die PHP-Version. Bei Shopware, Magento und den anderen Systemen steht sie im Kundenmenü Deines Hosters, meist unter PHP-Einstellungen oder PHP-Version. Wenn Du keinen Zugang hast, kann Dein Entwickler sie in einer Minute auslesen. CybelAngel weist auf eine Falle hin: Die Version, die ein Server auf der Kommandozeile meldet, ist nicht immer die, mit der die Website ausgeliefert wird. Es zählt die Version, die der Shop beim Aufruf einer Seite benutzt.

Wenn in Deinem Hosting noch PHP 8.1 oder älter steht, gibt es die Patch-Version für Dich gar nicht. Dann bleibt der Wechsel auf PHP 8.3 oder 8.4, und das ist bei einem älteren Shop keine Kleinigkeit. Shopware 5 wird seit Mitte 2024 nicht mehr gepflegt und läuft auf vielen Servern noch mit PHP 7.4 oder 8.0. Ältere Shopware-6-Versionen unterstützen die neuen PHP-Zweige ebenfalls nicht alle, dasselbe gilt für alte Plugins bei WooCommerce. In dem Fall hängt das PHP-Update am Shop-Update, und das ist dann eben ein Projekt und kein Klick. Was ein Umstieg von Shopware 5 bedeutet, steht in einem eigenen Beitrag.

Wie groß das Problem ist, zeigt eine Auswertung von CybelAngel auf Basis von Shodan-Zahlen vom 20. Oktober 2026. Rund 2,24 Millionen Server im Internet geben sich als PHP-Server zu erkennen. Von den etwa 1,5 Millionen, die ihre Version verraten, laufen 59 % auf einem Zweig, für den es kein offizielles Update gibt. Weitere 740.000 verstecken ihre Version, und hinter einer Adresse im Shared Hosting stecken oft viele Websites. Für WordPress nennt CybelAngel unter Berufung auf wordpress.org rund 35 % aller Installationen auf einem PHP-Zweig ohne Updates, allein 16 % auf PHP 7.4.

4Was Du heute tun solltest, in dieser Reihenfolge

Das PHP-Update ist die einzige Maßnahme, die die Lücke schließt, deshalb steht es ganz oben. Alles andere gewinnt Zeit oder räumt hinterher auf. Wenn Du das Update selbst nicht einspielen kannst, ist Schritt 1 ein Anruf oder Ticket beim Hoster, der Rest bleibt gleich.

Sieben Schritte für einen Shop auf PHP

1. Backup ziehen, dann PHP aktualisieren

   Erst ein frisches Backup von Dateien und Datenbank, dann das Update auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Danach Webserver oder PHP-FPM neu starten, sonst läuft der alte Interpreter weiter.

2. Testbestellung durchspielen

   Startseite, Produktseite, Warenkorb, Checkout bis zur Bestellbestätigung. Ein PHP-Update bricht gelegentlich ein altes Plugin, und das merkst Du lieber selbst als Deine Kunden.

3. Übergangslösung nur, wenn das Update noch nicht geht

   Calif nennt zwei Einstellungen, session.upload_progress.enabled auf 0 und memory_limit auf -1. Laut einer PHP-Entwicklerin reicht das allein nicht, es muss mit dem Sperren von Datei-Uploads am Webserver kombiniert werden. Das legt Bild-Uploads im Admin lahm und kann Formulare im Checkout treffen. Das ist ein Pflaster und kein Ersatz für das Update.

4. Hoster schriftlich bestätigen lassen

   Frag konkret, ob beide CVEs in der PHP-Umgebung Deiner Domain gepatcht sind und ob die Prozesse neu gestartet wurden. Eine Mail mit Datum reicht, aber die sollte es geben.

5. Auf Spuren prüfen, rückwirkend bis Juni

   Unbekannte oder veränderte PHP-Dateien im Webroot, neue Admin-Konten im Shop und in WordPress, ungewöhnliche ausgehende Verbindungen vom Server, Logeinträge mit User-Agents wie php2shell-scan. CybelAngel empfiehlt, dabei mindestens bis Juni 2026 zurückzuschauen.

6. Zugangsdaten rotieren

   Weil die erste Lücke Speicherinhalte preisgeben kann, gehören Admin-Passwörter, API-Schlüssel zu Zahlungsanbietern, Versanddiensten und Warenwirtschaft sowie Datenbank-Zugänge auf die Liste. Das gilt besonders, wenn der Server zwischen dem 20. und dem Patch-Datum ungeschützt am Netz war.

7. Bei Verdacht: Meldepflicht prüfen

   Findest Du Spuren eines Zugriffs auf Kundendaten, läuft nach Artikel 33 DSGVO eine Frist von 72 Stunden für die Meldung an die Aufsichtsbehörde. Spätestens dann solltest Du jemanden mit Erfahrung in solchen Vorfällen dazuholen.

5Warum Shopify-Händler nichts tun müssen, und was trotzdem Deine Sache bleibt

Shopify läuft nicht auf PHP, und Du betreibst bei Shopify keinen eigenen Server. Die Plattform, der Checkout, die Zahlungsabwicklung und die Server dahinter gehören Shopify, und Shopify spielt Sicherheitsupdates ein, ohne dass Du davon etwas mitbekommst. Das ist einfach die Logik eines gehosteten Systems. Eine ganze Kategorie von Aufgaben fällt beim Händler weg, also Server-Updates, PHP-Versionen, Backups der Plattform und die PCI-Zertifizierung des Zahlungswegs.

Was nicht wegfällt, ist alles, was oberhalb der Plattform liegt und Dir gehört. Drei Punkte würde ich bei einem Shopify-Shop ruhig in derselben Woche prüfen, in der WooCommerce-Händler PHP patchen:

• Admin-Zugänge mit Zwei-Faktor-Authentifizierung, für jeden Mitarbeiter ein eigenes Konto mit den Rechten, die er für seine Arbeit braucht. Ausgeschiedene Mitarbeiter und alte Agenturzugänge raus.
• Prüf die installierten Apps und ihre Berechtigungen. Jede App mit Zugriff auf Bestellungen und Kundendaten ist ein eigener Anbieter mit eigener Sicherheitslage. Apps, die niemand mehr nutzt, deinstallieren. Welche Apps ein Shop wirklich braucht, steht in einem eigenen Beitrag.
• Schau auf eigenen Code im Theme und auf Skripte von Drittanbietern. Shopify hat am 20. Oktober 2026 einen Schutz vor unerwarteten Weiterleitungen auf fremde Seiten im Storefront eingeführt, aber was Du selbst ins Theme einbaust, prüft niemand für Dich.

Dazu kommt Phishing, und zwar in beide Richtungen. Händler bekommen gefälschte Mails im Namen von Shopify, und Kunden bekommen gefälschte Mails im Namen des Shops. Dagegen hilft keine Plattform. Was hilft, ist Aufmerksamkeit im Team und, bei den Mails an Kunden, eine sauber eingerichtete Absenderdomain mit SPF, DKIM und DMARC.

6Wer wofür zuständig ist: eigener Server gegen gehostetes System

Der Unterschied zwischen WooCommerce oder Shopware auf einem gemieteten Server und einem gehosteten System wie Shopify ist in dieser Woche sehr sichtbar geworden. Es geht dabei gar nicht um die Qualität des Shopsystems, sondern um die Frage, wer nachts um zwei das Update einspielt. Die Tabelle zeigt, welche Aufgaben bei wem liegen. Auch die rechte Spalte hat Einträge, es sind nur weniger.

Wer die linke Spalte im Team abdeckt oder einen Dienstleister dafür hat, fährt mit einem PHP-Shop gut und hat diese Woche eben ein Update eingespielt. Wer die linke Spalte seit Jahren auf Zuruf erledigt und beim Wort PHP-Version erstmal nachschauen musste, hat eigentlich ein anderes Problem als diese eine Lücke. Das war auch vor PHP2Shell schon so, in meinem Beitrag zu WooCommerce vs. Shopify steht dazu die Zahl von Patchstack: 11.334 neue Schwachstellen im WordPress-Umfeld allein im Jahr 2025, 91 % davon in Plugins.

7Ist die Lücke ein Grund, zu Shopify zu wechseln?

Nein, jedenfalls nicht als Reaktion auf diese Woche. Eine Migration dauert Wochen, und ein ungepatchter Server bleibt in dieser Zeit ungepatcht. Erst wird also gepatcht, dann in Ruhe entschieden. Die Frage danach ist eigentlich nicht, ob Shopify sicherer ist. Die Frage ist, ob Du die linke Spalte der Tabelle oben in Zukunft selbst tragen willst. Für manche Händler ist die Antwort ja, weil sie einen Dienstleister dafür haben oder Produktlogik brauchen, die Shopify nicht abbildet. Oder weil sie den Zahlungsanbieter frei wählen wollen, ohne dass Shopify je nach Tarif 2 %, 1 % oder 0,6 % auf jede Bestellung legt. Für andere ist die Antwort nein, weil niemand im Haus die Updates macht und der Hoster nur für den Server zuständig ist, nicht für den Shop darauf.

Was Shopify kostet, steht komplett im Beitrag zu den Shopify Kosten 2026, der Tarif beginnt bei 27 € im Monat bei jährlicher Zahlung, dazu Apps und Zahlungsgebühren. Was ein Umzug an Vorbereitung braucht, steht im Beitrag zu Kosten und Dauer einer Migration. Und wann Shopware die bessere Wahl bleibt, habe ich im Vergleich Shopware vs. Shopify aufgeschrieben, denn das gibt es ja auch.