php2shell: was die PHP-Lücke für euren Shop bedeutet

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen: CVE-2026-109618 und CVE-2026-109619. Beide erlauben es, fremden Code auf dem Server auszuführen, ohne sich vorher anzumelden. Das Bundesamt für Sicherheit in der Informationstechnik hat dazu eine Cybersicherheitswarnung veröffentlicht und hält fest, dass für eine Ausnutzung weder eine Anmeldung noch ein Zutun der lesenden Person nötig ist. Unter dem Namen php2shell kursieren öffentlich Angriffswerkzeuge.

Die berichtigten Fassungen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, alle vom 21. Oktober 2026.

Was 9,2 von 10 bedeutet

Der Maßstab ist CVSS 4.0. Das oberste Band beginnt bei 9,0 und ist nur einen Punkt breit — 9,2 liegt darin, und nicht am Rand.

Aussagekräftiger als die Zahl ist, woraus sie entsteht. Am Anschlag stehen vier Größen:

• über das Netz erreichbar — es braucht keinen Zugang zum Rechenzentrum,
• keine Rechte nötig — kein Konto, keine Anmeldung,
• kein Zutun nötig — niemand muss auf etwas klicken,
• volle Wirkung auf Vertraulichkeit, Unversehrtheit und Verfügbarkeit des betroffenen Systems.

Gedämpft wird die Bewertung an genau zwei Stellen: Der Angriff gilt als aufwendig und setzt besondere Umstände voraus. Nur deshalb steht dort 9,2 und nicht 10. Als Grund zum Abwarten taugt das nicht — es heißt, dass der erste Angriff Können braucht und der tausendste nur noch ein Werkzeug. Solche Werkzeuge kursieren bereits.

Und eine Einschränkung, die man der Zahl nicht ansieht: CVSS bewertet nur das betroffene System. Was dahinter hängt, geht nicht in die Bewertung ein — und bei einem Shop ist genau das der Punkt.

Warum ein Update des Shops nicht hilft

Die Lücke steckt nicht in JTL-Shop, nicht in Shopware, nicht in WordPress. Sie steckt in PHP selbst — in dem Programm, das den Code dieser Anwendungen ausführt. Ein Update der Shopsoftware ändert daran nichts, und eine aktuelle Shopfassung schützt nicht.

Das ist der Punkt, an dem diese PHP-Sicherheitslücke am häufigsten falsch verstanden wird: Sie ist keine Aufgabe für die Shopagentur, sondern für die Stelle, die den Server betreibt. Geschlossen wird sie ausschließlich durch eine berichtigte PHP-Fassung.

Was bei JTL betroffen ist — und was nicht

JTL-Wawi und JTL-WMS sind nicht betroffen. Beides sind Windows-Programme und laufen ohne PHP. Wer ausschließlich mit der Warenwirtschaft arbeitet und keinen eigenen Shop betreibt, muss an dieser Stelle nichts tun.

Euer JTL-Shop läuft auf PHP und ist damit betroffen — und mit ihm der Connector, über den die Warenwirtschaft mit dem Shop spricht. Der liegt im Shop und damit auf demselben Server. Wer dort Code ausführen kann, erreicht die Shopdatenbank und die Zugangsdaten der Schnittstelle. Den Shop als „nur die Website" zu behandeln, greift deshalb zu kurz: Er ist die Tür, hinter der die Warenwirtschaft hängt.

Die drei Schritte

1. Herausfinden, welche PHP-Fassung läuft. Bei den meisten Hostinganbietern steht das im Panel unter den Einstellungen der Domain. Wer es dort nicht findet, fragt beim Anbieter nach — heute ist das die wichtigste Frage von allen.

2. Patchen lassen. Auf geteiltem Hosting erledigt das der Anbieter; sinnvoll ist, nach dem Zeitpunkt zu fragen, statt auf eine Rundmail zu warten. Auf einem eigenen Server macht es die Systemverwaltung. Ziel ist eine der vier oben genannten Fassungen.

3. Die PHP-Prozesse neu starten. Das ist der Schritt, der übersehen wird, und er ist bei dieser Lücke nicht optional. Eine der beiden Schwachstellen lebt davon, dass alter Zustand in einem laufenden Arbeitsprozess überdauert — solange die alten Prozesse bedient werden, läuft auch der alte Code weiter. Ein Neuladen der Konfiguration genügt dafür nicht. Paketaktualisierungen starten PHP-FPM üblicherweise selbst neu; nachsehen lohnt sich trotzdem, und prüfen lässt sich das Ergebnis an der tatsächlich ausgelieferten Fassung, nicht am installierten Paket.

Der unangenehme Fall: PHP 8.1 oder älter

Gepflegt werden derzeit die Zweige 8.2 bis 8.5. Für alles davor gibt es keine offizielle Berichtigung — auch nicht für diese beiden Lücken. Wer einen Shop betreibt, der wegen einer alten Shopfassung oder eines alten Plugins auf PHP 8.1 festhängt, hat heute kein Update, sondern eine Entscheidung: den Zweig anheben und dabei in Kauf nehmen, dass dabei etwas bricht, oder die Anwendung vorübergehend vom offenen Netz nehmen. Einzelne Betriebssystemanbieter liefern eigene Berichtigungen für ihre alten Pakete nach; das deckt deren Paket, nicht jede selbst gebaute Installation.

Dass dieser Fall weh tut, ist der Grund, warum die PHP-Fassung in die laufende Wartung gehört und nicht erst an einem Tag wie heute interessant wird.

Was nicht hilft

Eine Regel in der Webanwendungsfirewall fängt den öffentlich bekannten Weg, nicht die Lücke. Das PHP-Projekt nennt für Server, die heute nicht aktualisiert werden können, zwei Einstellungen als Zwischenlösung — fatal_error_backtraces=0 und session.upload_progress.enabled=0, beide nur mit anschließendem Neustart der Prozesse — sagt aber in beiden Meldungen (zu 109618, zu 109619) ausdrücklich dazu, dass es über die Konfiguration keine vollständige Absicherung gibt. Als Brücke für ein paar Stunden taugt das, als Zustand nicht.

Ein Patch heilt keinen Einbruch, der schon stattgefunden hat

Das Bundesamt für Sicherheit in der Informationstechnik meldet mit Stand vom 21. Oktober 2026 keine bestätigte Ausnutzung, wohl aber unbestätigte Berichte über vorhandene Angriffswerkzeuge. Wer eine ältere PHP-Fassung in diesen Tagen offen im Netz hatte, sollte nach dem Patchen nachsehen: unerklärte PHP-Dateien im Webverzeichnis, neue Konten in der Shopverwaltung, geänderte Einträge im Zeitplan, ausgehende Verbindungen, die niemand bestellt hat. Ein Update schließt die Tür — es räumt nicht weg, was vorher hereingekommen ist.

Wie wir es auf unseren Servern gehalten haben

Alle bei uns eingesetzten PHP-Zweige — 8.2, 8.3 und 8.4 — sind am 21. Oktober 2026 auf die berichtigten Fassungen gebracht und die Arbeitsprozesse anschließend neu gestartet worden. Keine der betreuten Domains lief auf einem Zweig ohne Berichtigung.

Das ist kein Kunststück, sondern der Grund, warum wir für jede Domain festhalten, welche PHP-Fassung sie bedient: Die Frage „was läuft wo" muss an einem Tag wie heute in Minuten beantwortet sein und nicht erst erhoben werden.

Wenn ihr nicht wisst, woran ihr seid

Schreibt uns die Domain und, falls bekannt, den Hostinganbieter. Wir sehen nach, welche PHP-Fassung ausgeliefert wird und ob sie die berichtigte ist — auch dann, wenn der Shop nicht bei uns liegt und wir ihn nicht betreuen. Das kostet uns ein paar Minuten und nimmt euch die Unsicherheit.