php2shell: Wie Shopbetreiber jetzt reagieren sollten

Was am 21. Oktober passiert ist

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, CVE-2026-109618 und CVE-2026-109619, beide mit der Bewertung 9,2 von 10. In der Szene läuft das Paar unter dem Namen php2shell. Die Kurzfassung: Über eine präparierte Anfrage kann ein Angreifer ohne Anmeldung Code auf dem Server ausführen. Die Details waren schon am Vortag durchgesickert, deshalb kam das Update einen Tag früher als geplant, und laut heise begannen die ersten Angriffsversuche Stunden vor der Veröffentlichung.

Die Folgen waren in Deutschland sichtbar wie selten: Die Charité nahm ihre Website komplett vom Netz, Teile von berlin.de und die Internetwache der Berliner Polizei waren nicht erreichbar, das BSI empfahl, Webauftritte vorsorglich abzuschalten. Hoster schalteten PHP zeitweise ganz ab. Beim Hosting-Partner maxcluster waren alle Onlineshops ab 14:45 Uhr offline und kamen ab 16:29 Uhr Cluster für Cluster zurück, die letzten gegen halb eins in der Nacht. Das ist der Preis, den ein verantwortungsvoller Hoster an so einem Tag zahlt, und der Grund, warum sich der Beitrag hier nicht mit der Technik befasst. Die steht ausführlich bei siepker.com, von der Suche nach allen PHP-Verbrauchern bis zum Wechsel der Paketquelle. Hier geht es um die Frage, was ein Shopbetreiber daraus mitnehmen sollte.

Warum ein Shopware-Update hier nicht hilft

Die meisten Sicherheitsmeldungen, die einen Shopbetreiber erreichen, betreffen Shopware selbst oder ein Plugin. Dafür gibt es eine eingespielte Routine: Update einspielen, fertig. php2shell ist anders. Die Lücke sitzt in PHP, also in der Laufzeitumgebung unter dem Shop. Der Sicherheitsdienstleister Sansec formuliert es so: Magento, Shopware und WooCommerce sind betroffen, auch wenn der eigene Code sauber ist. Ein Shopware-Update ändert daran nichts, ein Plugin-Update auch nicht. Es hilft nur ein Update von PHP auf dem Server, und das ist bei vielen Shops nicht die Zuständigkeit der Agentur, sondern die des Hosters oder des eigenen Admins.

Behoben ist die Lücke in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Für PHP 8.1 und älter gibt es vom PHP-Projekt keine offiziellen Releases mehr, nur minimale Quelltext-Patches zum Selbstbauen. Einige Paketquellen haben die Korrektur für 7.4, 8.0 und 8.1 zurückportiert, das offizielle Docker-Image dagegen nicht. Wer auf einer dieser Versionen läuft, hängt also davon ab, ob der eigene Hoster einen Backport beschafft hat. Genau hier wird das Thema zum Betreiberthema.

Die Kette: alter Shop, altes PHP

Die Beobachtung aus der Praxis ist unbequem: Viele Shops laufen noch auf alten Shopware-Versionen, und sie tun das nicht aus Bequemlichkeit, sondern weil der Server nur eine alte PHP-Version bietet. Umgekehrt gilt es genauso. Wer die PHP-Version nicht anheben kann, weil das alte Shopware sie nicht verträgt, bleibt auf beidem sitzen. Die Tabelle zeigt, welche PHP-Versionen die Shopware-Versionen laut ihrer jeweils letzten composer.json verlangen:

Drei Dinge fallen auf. Erstens: Ein Shop auf Shopware 6.4 kann maximal PHP 8.2 nutzen, und PHP 8.2 bekommt nur noch bis zum 31. Dezember 2026 Sicherheitsupdates. Wer dort steht, hat zehn Wochen. Zweitens: Shopware 6.5 läuft noch auf PHP 8.1, und viele Shops dieser Generation tun das auch, weil 8.1 beim Aufsetzen die Standardwahl war. Für diese Version gab es am 21. Oktober kein offizielles Update. Drittens: Shopware 5 kommt mit 5.7 zwar bis PHP 8.3, aber jeder, der so einen Shop kennt, weiß, dass die Plugins von 2019 darauf selten fehlerfrei laufen. Das Update der PHP-Version ist dann ein Projekt, kein Klick.

Wie die Termine von Shopware, PHP und Datenbank zusammenhängen, steht ausführlich im Beitrag Shopware, PHP, MySQL: Wann läuft was aus?. php2shell hat diese Tabelle nicht verändert. Es hat nur gezeigt, was passiert, wenn das schwächste Glied der Kette an einem Mittwoch plötzlich zählt.

Was jetzt zu tun ist

Die Liste ist kurz, weil ein Shopbetreiber die meisten Punkte nicht selbst erledigt, sondern einfordert.

1. PHP-Version des Shops prüfen. Sie steht in der Shopware-Administration unter Systeminformationen, bei Shopware 5 im Backend unter Systeminfo. Alles unter 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 ist ungepatcht.
2. Beim Hoster nachfragen, mit Versionsnummer. Die Frage lautet nicht „Ist php2shell gepatcht?", sondern „Welche PHP-Version läuft für meinen Shop, und steht die Korrektur im Changelog?". Bei PHP 8.1 und älter zusätzlich: Woher kommt der Backport, und bis wann wird er gepflegt?
3. Zugangsdaten tauschen, wenn der Shop stundenlang ungepatcht erreichbar war. Datenbankpasswort, APP_SECRET, Schlüssel von Zahlungs- und Versand-Schnittstellen. Das ist eine Vorsichtsmaßnahme, kein Nachweis eines Angriffs. Sansec meldet am 22. Oktober, dass die öffentlichen Angriffswerkzeuge gegen eine Standardinstallation nicht funktionieren und eine Massenausnutzung unwahrscheinlicher ist als am Vortag befürchtet. Das beruhigt, ersetzt aber keine Prüfung.
4. Den Umstieg planen, wenn die Tabelle oben rot zeigt. Shopware 6.4 und Shopware 5 lassen sich nicht auf eine sicher gepflegte PHP-Version bringen, ohne den Shop selbst anzuheben. Das ist das eigentliche Ergebnis dieses Tages: Die alte Version war bisher ein Risiko auf dem Papier, jetzt hat sie einen Termin.

Nachtrag 22. Oktober 2026: Ist der Patch vollständig?

Sicherheitsforscher berichten laut Tweakers und ITdaily von einer dritten Stelle im PHP-Code, die auch in 8.5.12 noch enthalten sei, und von Varianten des Speicherproblems, die der Patch nicht abdecke. Das PHP-Team widerspricht in der Sache: Der gemeldete Fehler habe keinen Zusammenhang mit den beiden Lücken und sei weitaus komplexer auszunutzen. Eine CVE und ein weiteres Release gibt es nicht. Für Betreiber folgt daraus zweierlei: Das Update bleibt Pflicht, und die Einstellung session.upload_progress.enabled = 0 in der php.ini, die am 21. Oktober als Überbrückung diente, kann als zusätzliche Härtung aktiv bleiben. Sie schließt die bestätigten Angriffswege über die Session, kostet im Shop nichts und bleibt wirksam, falls weitere Varianten auftauchen.

Serverwartung gehört zum Shop

Der Tag hat eine Lücke sichtbar gemacht, die mit PHP nur am Rande zu tun hat. Viele Shops haben eine Agentur für das Shopsystem und einen Hoster für den Server, und zwischen beiden liegt eine Zuständigkeit, die niemand ausdrücklich übernommen hat: die Frage, ob die Schichten unter dem Shop noch gepflegt werden. Beim Shopware-Update fällt das nicht auf. Es fällt an Tagen wie dem 21. Oktober auf, wenn der Shop offline ist und beide Seiten auf die jeweils andere zeigen.

Ein gepflegter Shop braucht deshalb drei Dinge, die zusammenpassen: eine Shopware-Version mit Security-Support, eine PHP-Version mit Sicherheitsupdates und jemanden, der beides im Blick behält und rechtzeitig anhebt. Für Shopware-6-Shops ist das der Kern der Wartungspakete, zu denen auch die Prüfung der PHP- und Datenbank-Versionen gehört. Wer noch auf PHP 7 oder 8.1 steht, findet unter PHP-Update mit Analyse den Weg, der mit einer Kompatibilitätsanalyse beginnt statt mit einem Versionswechsel auf gut Glück. Und wer Shopware 5 betreibt, sollte die Migration auf Shopware 6 nicht mehr für 2027 planen, sondern für den nächsten freien Termin.