PHP-Sicherheitslücke Oktober 2026: Was JTL-Shop-Betreiber jetzt tun müssen

Am 20. Oktober hat das PHP-Projekt ein außerplanmäßiges Sicherheitsupdate angekündigt, am 21. Oktober ist es erschienen. Es schließt zwei Lücken in PHP selbst, beide mit CVSS v4.0 9,2 bewertet, beide erlauben das Ausführen von fremdem Code auf dem Server. In der Fachpresse laufen sie unter dem Namen „php2shell”.

Lücken	CVE-2026-109618 — Code-Ausführung über fehlerhafte Behandlung von Speichermangel (GHSA-w8hw-w9fx-j79w)
	CVE-2026-109619 — Code-Ausführung über veralteten Zustand zwischen zwei Anfragen (GHSA-6wmf-4rv5-p3rp)
Betroffen	jede PHP-Installation, die Webanfragen bedient: PHP-FPM, Apache mit mod_php (höchstes Risiko), php-cgi, FrankenPHP, LiteSpeed
Behoben in	8.5.12, 8.4.27, 8.3.36, 8.2.35
Ohne offizielles Update	PHP 8.1 und älter — nur Quellcode-Backports für 7.4, 8.0 und 8.1

Wenn Sie einen JTL-Shop betreiben, lautet die kurze Antwort: PHP-Version prüfen, und wenn sie unter diesen Ständen liegt, heute aktualisieren — oder den Shop vom Netz nehmen, bis das erledigt ist. Der Rest dieses Beitrags erklärt, warum das ernster ist als die übliche Update-Meldung, was je nach Hosting zu tun ist und woran ein eiliges Update in der Praxis hängen bleibt.

Warum diese Lücke anders ist als die üblichen

Die meisten Sicherheitslücken, über die ich hier schreibe, sitzen in einer Anwendung: im Shop, in einem Plugin, im Adminbereich. Dann muss ein Angreifer eine bestimmte Seite finden, oft einen Login haben, oft eine bestimmte Version treffen.

Diese hier sitzt eine Ebene tiefer. Laut der Meldung des PHP-Projekts lässt sie sich bei der Verarbeitung von Upload- und Anfragedaten ausnutzen — bevor die Anwendung überhaupt läuft. Für mod_php gibt es nach Angaben des PHP-Projekts einen nachgewiesenen Angriff mit einer einzigen, nicht angemeldeten Anfrage.

Für Shopbetreiber heißt das drei Dinge:

• Die Shop-Version ist egal. JTL-Shop 5.8 auf einem ungepatchten PHP ist genauso angreifbar wie JTL-Shop 5.4. Maßgeblich ist allein die PHP-Version.
• Kein Login nötig. Jede öffentlich erreichbare PHP-Datei ist ein möglicher Einstieg.
• Der Wartungsmodus des Shops schützt nicht. Er ist selbst PHP. Die Anfrage landet trotzdem bei PHP, und genau dort sitzt das Problem.

Hoster nehmen Websites vom Netz

Wie ernst die Branche das nimmt, zeigt der 21. Oktober selbst. Mehrere Hoster haben die Websites ihrer Kunden vorsorglich abgeschaltet, bis die Updates eingespielt waren:

• Timme Hosting hat laut eigener Statusseite um 13:31 Uhr UTC vorübergehend alle Websites auf seinen Servern und die ISPConfig-Oberflächen deaktiviert und dazu geschrieben, die Lücke werde bereits aktiv ausgenutzt. Das Wartungsfenster ist bis 23.10.2026, 07:00 Uhr UTC angesetzt. Am Abend (17:24 Uhr UTC) meldete Timme, dass für PHP 8.2 bis 8.5 Updates ausgerollt und die Sperren aufgehoben sind; Websites auf älteren PHP-Versionen zeigen weiter eine statische Wartungsseite. Bemerkenswert ist der Rat an die Kunden: nicht den Wartungsmodus des eigenen Shops verwenden, weil der ebenfalls PHP nutzt.
• Mijndomein (Niederlande) hat laut eigener Störungsmeldung am Nachmittag alle Kunden-Websites, Webhosting und Webmail vorsorglich offline genommen und ab 18:05 Uhr nach dem Update schrittweise wieder freigegeben.
• Cyon (Basel) hat laut blue News um 15:45 Uhr Kundenportal, Webmail und sämtliche Webhostings vorsorglich vom Netz genommen.
• Uberspace hat laut heise online angekündigt, seine PHP-Dienste ab 15:45 Uhr zeitweise komplett zu deaktivieren.

Auch außerhalb der Hosting-Branche wurde abgeschaltet: Das Rechenzentrum der Universität Freiburg hat am Vormittag alle Websites auf seinen Webservern vorsorglich vom Netz genommen; blue News berichtet zudem von der Charité in Berlin sowie von Behörden- und Regierungsseiten in den Niederlanden, Finnland und Frankreich.

Zur Einordnung: Ob die Lücken zum Zeitpunkt der Abschaltungen bereits breit ausgenutzt wurden, ist uneinheitlich berichtet. Timme spricht von aktiver Ausnutzung, heise meldete am Nachmittag noch keine bekannten Angriffe, aber die Erwartung, dass sie bald kommen. Für Ihre Entscheidung ändert das wenig — ein Angriff, der ohne Login und vor der Anwendung greift, wartet nicht, bis die Lage geklärt ist.

Was JTL sagt

JTL hat seine Kunden am 21. Oktober per E-Mail informiert. Die Kernaussagen:

• Bei JTL gehostete Shops sind bereits gepatcht. Dort ist nichts zu tun.
• Wer selbst hostet oder bei einem anderen Anbieter liegt, soll sofort aktualisieren — oder den Shop bis dahin offline nehmen.

Was Sie jetzt tun müssen — nach Hosting-Modell

Shop bei JTL gehostet

Nichts, außer im Zweifel einmal in den Systeminformationen im Shop-Backend nachsehen, welche PHP-Version angezeigt wird.

Shop bei einem Webhoster (Shared Hosting, Managed Server)

Hier spielt in aller Regel der Hoster das PHP-Update ein, nicht Sie. Ihre Aufgabe ist, nachzusehen, ob es angekommen ist:

1. Im Hosting-Panel oder in den Systeminformationen des Shops die PHP-Version ablesen. Gesucht ist mindestens 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 — je nach Zweig.
2. Steht dort noch ein älterer Stand, die Statusseite des Hosters prüfen. Viele haben heute eigene Meldungen veröffentlicht.
3. Läuft der Shop auf PHP 8.1 oder älter, auf einen gepflegten Zweig umstellen. Der Hoster wird für diese Versionen in vielen Fällen nichts mehr liefern — und die Umstellung ist bei einem JTL-Shop ein Test wert, kein Klick nebenbei.
4. Ist unklar, ob gepatcht ist: Shop beim Hoster deaktivieren oder per Firewall sperren, bis die Antwort da ist. Nicht den Wartungsmodus im Shop-Backend verwenden.

Eigener Server (Root-Server, VPS, eigene Hardware)

Dann sind Sie der Hoster. Die Distributionen haben die Patches vorab bekommen und liefern aktualisierte Pakete; das Update kommt über den gewohnten Paketmanager. Wichtig ist der Neustart aller PHP-FPM-Pools bzw. des Webservers bei mod_php — erst dann läuft der neue Code. Und danach der Abschnitt weiter unten über fehlende Erweiterungen.

Übergangsschutz, wenn das Update noch nicht geht

Das PHP-Projekt nennt Maßnahmen, die die bekannten Angriffswege versperren. Es schreibt ausdrücklich dazu, dass sie kein Update ersetzen und eine der beiden Lücken sich damit nicht vollständig entschärfen lässt:

; php.ini oder FPM-Pool — NICHT per ini_set() oder .user.ini, das greift zu spät
session.upload_progress.enabled = 0

; nur PHP 8.5:
fatal_error_backtraces = 0

; Anfragen klein halten: 8M ohne Datei-Uploads, 32M mit Uploads
post_max_size = 8M

Danach alle PHP-Worker neu starten.

Eine Empfehlung aus der PHP-Meldung übernehme ich bewusst nicht: Für die Speichermangel-Lücke schlägt das PHP-Projekt vor, memory_limit auf -1 zu setzen, also das Speicherlimit ganz aufzuheben. Auf einem Shop-Server heißt das, dass eine einzige Anfrage — absichtlich oder durch einen hängenden Import — den gesamten Arbeitsspeicher leerlaufen lassen kann. Dann steht nicht nur der Shop, sondern alles auf der Maschine. Wenn das Update ohnehin heute kommt, ist das ein schlechter Tausch.

Was beim Update schiefgehen kann

Wir haben heute selbst PHP auf 8.3.36 gehoben, auf einem Server mit mehreren JTL-Shops unter CloudPanel. Das Update lief durch, die Shops antworteten, alles grün — auf den ersten Blick.

Auf den zweiten fehlte etwas. Das eilig gebaute Sicherheitspaket des Panel-Anbieters enthielt die Erweiterungen redis, memcached und imagick nicht mehr, die vorher mitgeliefert wurden. Der Shop merkt das nicht laut: Ohne Redis-Erweiterung fällt der Objekt-Cache still auf eine langsamere Methode zurück, ohne imagick rechnet die Bildverarbeitung anders. Keine Fehlermeldung im Frontend, nur ein Shop, der spürbar langsamer ist als gestern.

Deshalb gehören zu jedem PHP-Update zwei Minuten, die in keiner Anleitung stehen:

# vorher
php -m > module-vorher.txt

# ... Update einspielen, FPM neu starten ...

# nachher
php -m > module-nachher.txt
diff module-vorher.txt module-nachher.txt

# und das FPM-Log
grep -i "Unable to load dynamic library" /var/log/php*-fpm.log

Zeigt der Vergleich fehlende Module, nachinstallieren — bei uns über die Pakete der Distribution statt über das Panel-Paket — und erneut prüfen. Wichtig: php -m auf der Kommandozeile und PHP-FPM können unterschiedliche Konfigurationen laden. Maßgeblich ist, was FPM lädt; im Zweifel zeigt das die Systeminformation im Shop-Backend.

Danach der Rundgang im echten Shop, in dieser Reihenfolge:

1. Startseite und eine Kategorie — lädt alles, stimmen Bilder?
2. Artikeldetailseite — Bilder, Preise, Varianten.
3. Warenkorb bis kurz vor den Bestellbutton.
4. Admin-Login im Shop-Backend, Systeminformation: PHP-Version und Cache-Methode.
5. Wawi-Abgleich einmal anstoßen und prüfen, ob er durchläuft.

Wer das schon einmal bei einem Shop-Update gemacht hat, kennt die Liste aus dem Beitrag zur Update-Reihenfolge bei JTL — nur dass diesmal nicht der Shop, sondern das Fundament darunter ausgetauscht wird.

Nach dem Update: kurz nachsehen, ob vorher jemand da war

Eine Lücke, die Code-Ausführung ohne Login erlaubt, kann Spuren hinterlassen haben, bevor sie geschlossen wurde. Wer sicher gehen will, schaut einmal nach unbekannten PHP-Dateien im Webroot, nach kürzlich geänderten Dateien und nach neuen Backend-Konten. Wie eine solche Durchsicht konkret aussieht, steht im Beitrag zum Aufräumen nach CVE-2026-54390 — andere Lücke, gleiches Vorgehen.

Kurz

• PHP-Version prüfen. Sicher sind 8.5.12, 8.4.27, 8.3.36, 8.2.35 und neuer.
• Bei JTL gehostet: erledigt. Beim Hoster: nachsehen, ob es angekommen ist. Eigener Server: heute aktualisieren und alle Pools neu starten.
• Bis dahin den Shop lieber vom Netz nehmen — beim Hoster oder per Firewall, nicht über den Wartungsmodus im Shop.
• Nach dem Update Module vergleichen, FPM-Log lesen, einmal durch den Shop klicken.
• PHP 8.1 und älter ist kein Zustand mehr, sondern eine Aufgabe mit Termin.

Stand dieses Beitrags: 21.10.2026, abends. Bei einer laufenden Lage ändert sich manches stündlich — maßgeblich sind die Meldung des PHP-Projekts und die Statusseite Ihres Hosters.

Wenn Sie nicht sicher sind, auf welcher PHP-Version Ihr Shop läuft, oder das Update nicht selbst einspielen wollen: Das ist eine Sache von wenigen Minuten bis zu einer Stunde, und ich sehe es mir im Rahmen der JTL-Shop-Betreuung gern heute noch an.

Quellen

• PHP-Projekt: Sicherheitsmeldung vom 21.10.2026 mit Versionen und Übergangsmaßnahmen
• GitHub-Advisories: GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp
• heise online: php2shell: Kritische Sicherheitslücken erlauben Codeeinschleusung in PHP
• Statusseite Timme Hosting
• Störungsmeldung Mijndomein (niederländisch)
• blue News: Sicherheitslücke bedroht Millionen von Webseiten
• Universität Freiburg, Rechenzentrum: Maßnahmen zur PHP-Sicherheitslücke