PHP2Shell: Was die kritische PHP-Lücke für Shopware-Shops bedeutet

Am 20. Oktober 2026 gelangten Details zu zwei kritischen Schwachstellen im Kern von PHP vorzeitig an die Öffentlichkeit — vor dem geplanten Patch. Das PHP-Projekt hat die Sicherheitsreleases am 21. Oktober um 14:00 UTC (16:00 Uhr deutscher Zeit) nachgezogen.

Die Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619, laufen öffentlich unter dem Namen „PHP2Shell" und sind vom PHP-Security-Team mit CVSS v4.0 9.2 bewertet. Das BSI führt sie in seiner Cybersicherheitswarnung mit Kritikalität 3 von 4 („Orange") — Maßnahmen müssen unverzüglich ergriffen werden.

Für Shopware-Händler ist die wichtigste Nachricht die unbequeme: Die Lücke sitzt nicht in Shopware. Sie sitzt in PHP. Kein composer update, kein Shopware-Release und kein Plugin-Update schließt sie.

Die Lage in Kurzform

• Was: Zwei Remote-Code-Execution-Lücken im PHP-Core. Der öffentlich demonstrierte Angriffsweg ist ein Heap-Use-after-free im Session-Upload-Progress-Mechanismus.
• Wer ist betroffen: Nach Angaben der Sicherheitsforscher von Sansec jeder Webserver mit PHP 5.4 oder neuer — also praktisch jeder Shopware-, Magento- und WooCommerce-Shop sowie WordPress, TYPO3, Joomla! und Drupal.
• Angriffsvoraussetzungen: Laut BSI weder Authentifizierung noch Nutzerinteraktion. Ein Angreifer braucht nur die URL.
• Gepatcht: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 (21. Oktober 2026).
• Nicht gepatcht von php.net: PHP 8.1 und älter. Diese Zweige sind End-of-Life und erhalten keinen Upstream-Fix. Mehrere Distributionen haben den Fix trotzdem zurückportiert — Details im Update weiter unten.
• Zeitdruck: Sansec rechnete mit Massenangriffen innerhalb von 15 Minuten nach dem Release, das BSI mit breiter Ausnutzung innerhalb von Stunden. Zuverlässige Workarounds sind laut BSI nicht bekannt.

Warum das jeden Shopware-Shop betrifft

Shopware ist eine PHP-Anwendung. Der verwundbare Code liegt eine Ebene darunter — im Interpreter, der jeden eingehenden Request verarbeitet, bevor Shopware überhaupt startet.

Drei Konsequenzen daraus werden gerade reihenweise unterschätzt:

Ein Shopware-Update hilft nicht. Die Lücke lässt sich nicht aus dem Shop-Code heraus schließen. Der Fix muss auf Server-, Container- oder Hoster-Ebene passieren.

Der Wartungsmodus hilft nicht. Sansec weist ausdrücklich darauf hin: PHP parst jeden Request, bevor die Anwendung ihr Maintenance-Flag prüft. Ein Shop im Wartungsmodus ist genauso angreifbar wie ein offener.

Ein „kleiner" Nebenshop ist kein kleines Risiko. Jede PHP-Instanz auf derselben Infrastruktur ist ein Einstiegspunkt: der alte Shopware-5-Shop auf der Subdomain, das WordPress mit dem Blog, die Staging-Umgebung, das vergessene Tool unter /tools. Wer nur den Hauptshop patcht, hat die Tür nebenan offen gelassen.

Welche PHP-Version braucht welches Update?

Die exakten Versionsnummern und Release-Daten stehen im PHP-ChangeLog. Wichtig für die Praxis: Distributionen und Hoster liefern die Pakete mit zeitlichem Versatz aus. Die relevante Frage ist nicht „hat PHP gepatcht?", sondern „läuft der Patch auf meinem Server?".

Update vom 22. Oktober 2026: Bis zu welcher PHP-Version es Patches gibt

Einen Tag nach dem Patch-Tag lässt sich die Frage genauer beantworten — und die Antwort ist für alte Shops besser, als sie am 21. Oktober aussah.

Von php.net gibt es Fixes ausschließlich für die vier unterstützten Zweige: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Jede kleinere Version in diesen Zweigen ist verwundbar, PHP 8.1 und älter bekommt vom PHP-Projekt nichts. Wie lange ein Zweig überhaupt noch Sicherheitsfixes erhält, steht in den Supported Versions: PHP 8.2 läuft am 31. Dezember 2026 aus, 8.3 am 31. Dezember 2027, 8.4 Ende 2028 und 8.5 Ende 2029. Wer heute auf 8.2.35 patcht, hat damit zwei Monate gewonnen, nicht zwei Jahre.

Distributionen und Hoster haben deutlich weiter zurück gepatcht — über Backports, bei denen die PHP-Versionsnummer gleich bleibt:

• Ubuntu liefert den Fix für 22.04 LTS (PHP 8.1), 24.04 LTS (8.3) und 26.04 LTS (8.5) im regulären Support aus. Für 20.04 (7.4), 18.04 (7.2), 16.04 (7.0) und 14.04 (5.5) gibt es ihn nur mit Ubuntu Pro bzw. ESM.
• AlmaLinux hat die Module-Streams php:7.2, 7.3, 7.4, 8.0 und 8.2 für EL8 sowie 8.0, 8.1, 8.2 und 8.3 für EL9 aktualisiert — mit dem ausdrücklichen Hinweis, dass für die abgekündigten Streams ein nächstes Mal nicht garantiert ist. Für RHEL und Rocky gilt die jeweils eigene Advisory-Lage.
• Kommerzieller Extended Support (z. B. TuxCare ELS) deckt PHP 8.1, 8.0, 7.0 bis 7.4 und 5.x ab.
• Control Panels sind nachgezogen: cPanel/EA4 und Plesk haben ihre PHP-Pakete inklusive der alten Zweige neu gebaut.

Verlassen sollte sich darauf trotzdem niemand pauschal: Nicht jeder Anbieter backportet, und für einzelne Distributionen stand am Release-Tag für ältere PHP-Zweige „no fix planned". Die Frage an den Hoster bleibt dieselbe — gibt es für genau diese PHP-Version ein gepatchtes Paket, und ist es installiert?

Die praktische Konsequenz: php -v allein beweist nichts. Ein Backport hebt die Versionsnummer nicht an. Ein gepatchtes Ubuntu-PHP meldet weiterhin 8.1.x, ein gepatchtes AlmaLinux-PHP weiterhin 8.1.32. Verifiziert wird deshalb gegen Paketversion und Build-Datum:

dpkg -l | grep -E '^ii +php[0-9.]*-(cli|fpm)'                                    # Debian/Ubuntu
rpm -q php-cli php-fpm --qf '%{NAME} %{VERSION}-%{RELEASE} %{BUILDTIME:date}\n'  # RHEL/AlmaLinux

Nur bei den offiziellen Docker-Images ist die Versionsnummer wieder aussagekräftig — dort heißen die gepatchten Tags 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Der harte Fall: Shops auf nicht mehr unterstütztem PHP

Hier wird aus einem Patch-Tag ein Strategiethema.

Shopware 6.7 unterstützt PHP 8.2 bis 8.4, Shopware 6.6 setzt mindestens PHP 8.2 voraus. Wer dort aktuell ist, bekommt einen Patch und kann ihn einspielen.

Shopware 6.5 lief noch auf PHP 8.1 bis 8.3. Jeder 6.5-Shop, der weiterhin auf PHP 8.1 betrieben wird, steht ohne Upstream-Fix da — ob es überhaupt einen Patch gibt, entscheidet allein die Distribution. Shopware-5-Shops auf PHP 7.x sind noch deutlicher betroffen — Shopware 5 ist seit Juli 2024 End-of-Life und erhält selbst keine Sicherheitsupdates mehr.

Für diese Shops gibt es drei Optionen, und keine davon ist „abwarten":

1. PHP-Upgrade auf einen gepatchten Zweig — technisch der richtige Weg, setzt aber eine Shopware-Version voraus, die das neue PHP unterstützt.
2. Vorübergehende Netztrennung — das BSI nennt die Trennung vom Internet ausdrücklich als Option, wo unmittelbares Patchen nicht möglich ist.
3. Backport über Distribution oder Extended Support — Ubuntu Pro/ESM, die RHEL-kompatiblen Module-Streams und ELS-Anbieter wie TuxCare haben PHP 8.1, 8.0 und 7.x versorgt. Das muss der Hoster belastbar bestätigen, nicht „wahrscheinlich" haben — und es verlängert die Laufzeit des Shops, es löst die EOL-Frage nicht.

Wer jetzt feststellt, dass die eigene PHP-Version zur dritten Zeile dieser Liste gehört, hat kein Security-Problem von heute, sondern ein Migrationsproblem von vorgestern. Ob und wann eine Migration auf Shopware 6 nötig ist, haben wir separat aufgeschrieben.

Vorgehen nach F.O.C.U.S.

Ein Vorfall wie dieser ist genau der Moment, in dem sich zeigt, ob ein Shop betrieben wird oder nur läuft. Wir arbeiten solche Lagen nach unserem F.O.C.U.S.-System ab — nicht weil ein Akronym den Patch schneller macht, sondern weil die Reihenfolge verhindert, dass im Stress das Wichtigste vergessen wird.

Facts — Bestandsaufnahme vor Aktion

Die erste Frage ist nicht „wie patchen wir?", sondern „wo läuft überhaupt PHP?". Zu erfassen sind:

• PHP-Version pro Dienst: php -v (CLI) und php-fpm -v getrennt prüfen — auf vielen Servern laufen unterschiedliche Stände.
• alle Umgebungen: Produktion, Staging, Preview, Entwicklungsserver.
• alle Instanzen: Hauptshop, Nebenshops, Subdomains, Blog, Admin-Tools, Cron- und Worker-Container.
• der Auslieferungsweg: Distributionspaket, Docker-Image, Hoster-Panel, PaaS.

php -v
php-fpm -v
php -i | grep -i 'session.upload_progress'

Ohne diese Liste patcht man nicht, man rät.

Objectives — Zielgröße statt Absicht

„Wir kümmern uns drum" ist kein Ziel. Belastbar ist: Alle internetexponierten PHP-Instanzen laufen bis heute 22:00 Uhr auf einer gepatchten Version — verifiziert, nicht angenommen. Dazu kommt ein zweites Ziel: eine dokumentierte Entscheidung für jede Instanz, die das nicht erreichen kann.

Constraints — die Grenzen offen auf den Tisch

Typische Blocker, die jetzt sichtbar werden:

• Shops auf PHP 8.1 oder 7.x ohne Upgrade-Pfad.
• Plugins, die auf einer neueren PHP-Version nicht getestet sind.
• kein Staging, auf dem der Patch vorab geprüft werden kann.
• Hoster ohne definierte Reaktionszeit.
• niemand mit Deploy-Rechten erreichbar.

Jeder dieser Punkte ist eine Entscheidung, die jemand treffen muss — meist eine Abwägung zwischen Ausfallrisiko und Kompromittierungsrisiko. Beim PHP2Shell-Risikoprofil gewinnt in der Regel das Patchen.

Execution — patchen, neu starten, verifizieren

Der Schritt, der am häufigsten halb erledigt wird:

1. PHP-Pakete aktualisieren bzw. Container-Image neu bauen (docker compose build --pull --no-cache und anschließend neu starten).
2. PHP-FPM neu starten oder reloaden. Ohne Neustart läuft der alte Interpreter im Speicher weiter — das Paket ist aktuell, der Prozess nicht.
3. Version gegen den laufenden Prozess verifizieren, nicht gegen die Paketliste — und bei Distro-Backports gegen Paketversion und Build-Datum, weil die PHP-Versionsnummer dort unverändert bleibt.
4. Funktionsprüfung: Login, Suche, Warenkorb, Checkout, Zahlung, Bestellübertragung, Worker und Cron.

Scaling — aus dem Notfall ein System machen

Nach dem Patch ist die eigentliche Frage: Wie lange hat es gedauert — und warum so lange? Wer heute 20 Minuten gebraucht hat, hat eine Pipeline, ein Inventar und klare Zuständigkeiten. Wer sechs Stunden gebraucht hat, hat keines davon und wird beim nächsten Mal wieder sechs Stunden brauchen.

Die Maßnahmen, die das ändern, sind unspektakulär: ein gepflegtes Infrastruktur-Inventar, automatisierte Patch-Pipelines, ein Staging, das der Produktion entspricht, Monitoring mit Alerting und ein Wartungs-Retainer mit definierten Reaktionszeiten. Keine dieser Maßnahmen verhindert die nächste CVE. Alle zusammen entscheiden, ob sie ein Routinevorgang oder ein Krisentag wird.

Wenn sofortiges Patchen nicht möglich ist

Vor dem Release wurden mehrere Zwischenmaßnahmen diskutiert. Wichtig zur Einordnung: Ein PHP-Kernentwickler hat betont, dass Patchen die einzige verlässliche Mitigation ist, und das BSI schreibt, zuverlässige Workarounds seien nicht bekannt. Die folgenden Schritte verschaffen Zeit, sie lösen das Problem nicht:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

Zusätzlich diskutiert wurden das Blockieren von multipart/form-data-Requests auf Webserver- oder WAF-Ebene. Für einen Shop ist das ein massiver Eingriff: Dateiuploads im Admin, Bild-Uploads bei Konfiguratoren, einzelne Payment- und Schnittstellen-Callbacks können dadurch ausfallen. Als Überbrückung für wenige Stunden vertretbar, als Dauerzustand nicht.

Und noch einmal, weil es der häufigste Irrtum ist: Der Shopware-Wartungsmodus ist keine Mitigation.

Wurde mein Shop kompromittiert?

Weil die Details vor dem Patch öffentlich wurden, gibt es ein Zeitfenster, in dem verwundbare Server erreichbar waren — Sansec dokumentiert erste Angriffsversuche bereits am Morgen des 21. Oktober, also vor der Patch-Veröffentlichung. Für Shops, die in diesem Fenster exponiert waren, reicht Patchen allein nicht. Zu prüfen sind:

• neue oder geänderte PHP-Dateien im Webroot, in public/, custom/plugins/ und var/cache — Zeitstempel gegen den letzten Deploy abgleichen.
• unerwartete Admin-Benutzer, Integrationen und API-Keys in Shopware.
• ausgehende Verbindungen und neue Cron-Einträge.
• Webserver-Logs auf auffällige POST-Requests mit multipart/form-data.
• Zahlungs- und Bestelldaten auf Manipulationen, insbesondere eingefügtes JavaScript im Checkout (Skimming).

Ein bestätigter Einbruch ist ein eigener Prozess: isolieren, forensisch sichern, aus einem sauberen Stand neu aufbauen, Zugangsdaten rotieren, Meldepflichten nach Art. 33 DSGVO prüfen. Ein Patch über ein kompromittiertes System drüberzuspielen beseitigt die Lücke, nicht den Angreifer.

Was dieser Tag über Shop-Betrieb aussagt

PHP2Shell ist kein Shopware-Problem, aber ein perfekter Stresstest für den Shopware-Betrieb. Die Shops, die heute in einer halben Stunde durch waren, haben nichts Magisches gemacht — sie wussten, welche PHP-Versionen wo laufen, hatten einen Weg, sie zu aktualisieren, und jemanden, der ihn gehen darf.

Genau das ist die Scaling-Phase in F.O.C.U.S.: Der Go-Live ist kein Erfolg, er ist der Startpunkt der Verantwortung. Sicherheitsupdates gehören nicht in die Kategorie „wenn Zeit ist", sondern in dieselbe Kategorie wie Verfügbarkeit und Checkout-Conversion — messbar, zuständig, planbar. Was dazu gehört, steht auch im Ausblick auf Shopware 6.8: Infrastruktur dokumentieren, automatisierte Kerntests, reservierte Releasefenster.

Fazit

1. PHP-Version jeder internetexponierten Instanz prüfen — CLI und FPM getrennt.
2. Auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren und PHP-FPM neu starten.
3. Gegen den laufenden Prozess verifizieren, nicht gegen die Paketliste — bei Backports gegen Paketversion und Build-Datum.
4. Instanzen auf PHP 8.1 oder älter: Distro-Backport prüfen (Ubuntu Pro/ESM, RHEL-Streams, ELS), sonst Upgrade-Pfad entscheiden oder vom Netz nehmen.
5. Bei Exposition im Leak-Fenster: Kompromittierungsprüfung durchführen.
6. Danach die Lehre ziehen — Inventar, Pipeline, Retainer.

Die Lücke war nicht vermeidbar. Die Reaktionszeit ist es.

Offizielle Quellen

• BSI-Cybersicherheitswarnung 2026-297981-1032 — Kritische Schwachstellen in PHP
• PHP ChangeLog 8.x — Security-Releases
• PHP: Supported Versions
• Ubuntu Security: php2shell — verfügbare Fixes inkl. ESM
• AlmaLinux: php2shell — gepatchte PHP-Pakete veröffentlicht
• Sansec: Critical PHP RCE CVE-2026-109618 und CVE-2026-109619
• Shopware 6.7 Update Guide — unterstützte PHP-Versionen