Das PHP-Projekt hat am 21.10.2026 zwei kritische Sicherheitslücken geschlossen: CVE-2026-109618 und CVE-2026-109619, in Fachkreisen „PHP2Shell“ genannt. Beide erlauben es, ohne Anmeldung Schadcode auf dem Webserver auszuführen. Bewertet sind sie mit CVSS 9.2. Ein Exploit ist bereits öffentlich, erste Angriffe wurden noch vor dem Update beobachtet.
Wichtig für JTL-Händler: Betroffen ist der Webserver Ihres Shops, nicht die Warenwirtschaft. JTL-Wawi nutzt kein PHP, auch nicht im Wawi-Hosting.
Unsere Lösung: Wir prüfen die PHP-Version Ihres Shops und Servers, spielen das Update auf eigenen Servern ein und sichern Shops beim Hoster mit einer Notfall-Regel ab, bis das Update dort angekommen ist. Wenn es schnell gehen muss, melden Sie sich. Termin buchen
Auf einen Blick
| Punkt | Details |
|---|---|
| Lücken | CVE-2026-109618 (Fehler bei Speichermangel) · CVE-2026-109619 (veralteter Zustand zwischen Anfragen) |
| Risiko | Schadcode ohne Anmeldung, noch bevor der Shop-Code läuft |
| Betroffen | Alle PHP-Installationen, die Webanfragen bedienen: PHP-FPM, Apache mit mod_php (dort am kritischsten), php-cgi, LiteSpeed, FrankenPHP |
| Sicher ab | PHP 8.2.35 · 8.3.36 · 8.4.27 · 8.5.12 |
| Kein offizielles Update | PHP 8.1 und älter |
| Nicht betroffen | JTL-Wawi, auch gehostet bei ecomDATA oder auf eigenem Server · Shops im JTL-Hosting (bereits gepatcht) |
Wer muss was tun?
| Ihr Shop läuft … | Was zu tun ist |
|---|---|
| bei JTL gehostet | Nichts. JTL hat alle Shops bereits auf gepatchte Versionen umgestellt. |
| auf eigenem Server (Root-Server, VPS, eigener Rechner) | Sofort PHP aktualisieren und alle PHP-Prozesse neu starten. |
| bei einem Hoster (Webhosting, Shared Hosting, Managed Server) | Version prüfen, auf eine gepatchte Version umstellen. Hat der Hoster noch nicht aktualisiert: Shop absichern oder vom Netz nehmen. |
Das gilt genauso für Connectoren, die Sie selbst hosten, etwa für WooCommerce oder Shopware, und für jede andere PHP-Seite auf demselben Server.
Eigener Server: Update und Neustart
- PHP über den Paketmanager aktualisieren, je nach Quelle über die Distribution, Remi oder deb.sury.org.
- Alle PHP-Prozesse neu starten: PHP-FPM-Dienste und Apache. Erst nach dem Neustart läuft die neue Version.
- Version prüfen. Bei Distributionen mit eigenen Fixes (zum Beispiel Debian, Ubuntu, RHEL/AlmaLinux) kann die Versionsnummer älter aussehen; maßgeblich ist der Sicherheitshinweis der Distribution.
Bis das Update eingespielt ist, nennt das PHP-Projekt Einstellungen, die das Risiko senken. Sie gehören in die php.ini, den FPM-Pool oder die Server-Konfiguration, nicht in ini_set() oder .user.ini. Danach alle Prozesse neu starten:
session.upload_progress.enabled = 0
post_max_size = 8M ; 32M nur, wenn Uploads nötig sind
upload_max_filesize = 8M ; immer unter post_max_size
; nur PHP 8.5:
fatal_error_backtraces = 0
Das PHP-Projekt empfiehlt zusätzlich memory_limit = -1 zusammen mit einer Speichergrenze für den Container oder Dienst. Das sollte nur setzen, wer seinen Server kennt: Ohne äußere Grenze kann ein einzelnes Skript den ganzen Speicher belegen.
Shop beim Hoster: Was Sie selbst tun können
Beim Hoster haben Sie keinen Zugriff auf PHP selbst. Das Update muss der Hoster einspielen. Was Sie tun können:
- PHP-Version prüfen, im Kundenmenü des Hosters bei den Einstellungen der Domain.
- Auf die neueste Version umstellen. Viele Hoster bieten mehrere PHP-Versionen an. Läuft Ihr Shop noch mit PHP 8.1 oder älter, bekommt diese Version kein Update mehr: Wechseln Sie auf 8.2 oder neuer. Prüfen Sie vorher, ob Ihre Shop-Version damit läuft. Ältere Shops brauchen dafür oft zuerst ein Shop-Update.
- Beim Hoster nachfragen, wann die gepatchten Versionen bereitstehen.
- Bis dahin absichern mit der Notfall-Regel unten, oder den Shop vom Netz nehmen.
Notfall-Regel per .htaccess
Die Lücken werden über präparierte Anfragen ausgelöst, die PHP schon beim Einlesen verarbeitet. Die folgende Regel blockt deshalb Datei-Uploads (multipart/form-data) und begrenzt die Größe von Anfragen. Sie greift im Webserver, bevor PHP startet.
Die Regel gehört ganz nach oben in die .htaccess im Shop-Verzeichnis, vor die Regeln des Shops. Legen Sie vorher eine Sicherung der Datei an.
# PHP2Shell (CVE-2026-109618/-109619) – Notbehelf, bis der Hoster PHP gepatcht hat
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP:Content-Type} multipart/ [NC]
# Ausnahme: JTL-Wawi-Abgleich (dbeS) darf weiter, aber nur von der festen IP Ihrer Wawi.
# 203.0.113.45 ist nur ein BEISPIEL -> durch die IP Ihres Wawi-Anschlusses ersetzen
# (ermitteln: an dem Rechner, auf dem der Abgleich bzw. der JTL-Worker läuft,
# wieistmeineip.de aufrufen).
# Schreibweise beibehalten: ^ am Anfang, \ vor jedem Punkt, $ am Ende.
RewriteCond %{REQUEST_URI} !/dbeS/ [OR]
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.45$
RewriteRule .* - [F,L]
</IfModule>
<If "%{REQUEST_URI} !~ m#/dbeS/#">
LimitRequestBody 8388608
</If>
Wichtig: 203.0.113.45 ist eine Beispieladresse, die es im Internet nicht gibt. Ersetzen Sie sie durch die öffentliche IP-Adresse, von der aus Ihre JTL-Wawi den Abgleich macht. Ohne diese Ausnahme blockiert die Regel auch den Wawi-Abgleich: Die Wawi überträgt Artikel und Bilder als Datei-Upload an den Shop.
So finden Sie die richtige Adresse:
- Wawi im eigenen Büro: Rufen Sie an dem Rechner, auf dem der Abgleich gestartet wird oder der JTL-Worker läuft (oft der Server, nicht jeder Arbeitsplatz), eine Seite wie
wieistmeineip.deauf. Die angezeigte Adresse ist die öffentliche IP Ihres Internetanschlusses. - Wawi gehostet (ecomDATA, Mietserver, Rechenzentrum): Die Adresse ermitteln Sie genauso, aber auf dem Server per Remotedesktop. Oder Sie fragen Ihren Anbieter.
- Feste IP nötig: Die Ausnahme funktioniert nur, wenn sich die Adresse nicht ändert. Viele Privat- und kleine Geschäftsanschlüsse bekommen täglich eine neue IP. Fragen Sie im Zweifel Ihren Internetanbieter.
So tragen Sie die Adresse ein: Nur die Ziffern austauschen, alles andere bleibt. Zeigt wieistmeineip.de zum Beispiel 198.51.100.23, lautet die Zeile:
RewriteCond %{REMOTE_ADDR} !^198\.51\.100\.23$
Was die Regel kostet und was nicht:
- Uploads im Shop sind gesperrt, etwa Bilder im Shop-Backend, Plugin-Uploads oder Formulare mit Dateianhang. Normale Bestellungen, Login und Kontaktformulare ohne Anhang funktionieren weiter.
- Ohne feste IP Ihrer Wawi gibt es keine saubere Ausnahme. Dann den Abgleich pausieren, solange die Regel aktiv ist, oder den Shop vom Netz nehmen.
- Keine Garantie. Die Regel verkleinert die Angriffsfläche deutlich, schließt die Lücke aber nicht. Auch das PHP-Projekt sagt: Vollständig schützt nur das Update.
Entfernen Sie die Regel wieder, sobald Ihr Hoster die gepatchte Version bereitstellt und Ihr Shop darauf läuft.
Shop vom Netz nehmen: aber richtig
Der Wartungsmodus des JTL-Shops schützt nicht. Auch im Wartungsmodus verarbeitet PHP jede Anfrage, und die Lücken greifen, bevor der Shop-Code läuft. Wer den Shop vom Netz nimmt, muss dafür sorgen, dass PHP gar nicht mehr aufgerufen wird.
Am einfachsten geht das mit einer statischen Seite: Legen Sie eine Datei wartung.html mit einem kurzen Hinweis in das Shop-Verzeichnis und setzen Sie diese Zeilen ganz nach oben in die .htaccess:
# Shop vorübergehend offline, ohne PHP (PHP2Shell)
ErrorDocument 503 /wartung.html
RewriteEngine On
# Ihre eigene IP kommt weiter durch (zum Testen).
# 203.0.113.45 ist nur ein BEISPIEL -> durch Ihre aktuelle IP ersetzen (wieistmeineip.de),
# Schreibweise beibehalten: ^ am Anfang, \ vor jedem Punkt, $ am Ende.
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.45$
RewriteCond %{REQUEST_URI} !^/wartung\.html$
RewriteRule .* - [R=503,L]
Besucher sehen dann die Wartungsseite, Suchmaschinen erhalten den Status 503 („vorübergehend nicht verfügbar“) und werten das nicht als dauerhaften Ausfall. Statt der Beispieladresse 203.0.113.45 tragen Sie Ihre eigene aktuelle IP-Adresse ein, genauso ermittelt und geschrieben wie oben: Dann sehen nur Sie weiter den Shop, zum Testen. Liegt der Shop in einem Unterverzeichnis, passen Sie die Pfade entsprechend an. Alternativ kann Ihr Hoster PHP für die Domain abschalten oder die Domain auf eine Wartungsseite umleiten.
Solange der Shop offline ist, läuft auch kein Wawi-Abgleich mit dem Shop. Bestellungen von Amazon, eBay und anderen Marktplätzen kommen über JTL-eazyAuction und sind davon nicht betroffen.
So unterstützen wir Sie
Wir prüfen, auf welcher PHP-Version Ihr Shop und Ihre Connectoren laufen, spielen auf eigenen Servern das Update ein und starten alle Dienste sauber neu. Bei Shops im Hosting setzen wir die Notfall-Regel mit Ausnahme für Ihren Wawi-Abgleich, stimmen den Wechsel der PHP-Version mit Ihrer Shop-Version ab und nehmen die Regel wieder heraus, sobald der Hoster nachgezogen hat.
Häufige Fragen
Ist meine JTL-Wawi betroffen?
Nein. JTL-Wawi läuft unter Windows mit Microsoft SQL Server und nutzt kein PHP. Das gilt auch für eine Wawi, die bei ecomDATA oder auf einem Mietserver gehostet wird. Betroffen ist alles, was im Web mit PHP läuft: JTL-Shop, WooCommerce, Shopware, WordPress und PHP-Connectoren.
Mein Shop liegt bei JTL. Muss ich etwas tun?
Nein. Laut JTL sind alle bei JTL gehosteten Shops bereits auf die gepatchten PHP-Versionen aktualisiert.
Welche PHP-Versionen sind sicher?
8.2.35, 8.3.36, 8.4.27 und 8.5.12 sowie jeweils neuere. PHP 8.1 und älter bekommt vom PHP-Projekt kein Update mehr. Auf eigenen Servern kann die Versionsnummer bei Linux-Distributionen niedriger aussehen, obwohl der Fix nachgereicht wurde. Dann zählt der Sicherheitshinweis der Distribution.
Reicht der Wartungsmodus des JTL-Shops?
Nein. Auch im Wartungsmodus verarbeitet PHP jede Anfrage. Die Lücken greifen, bevor der Shop-Code überhaupt läuft. Wer den Shop vom Netz nehmen will, muss dafür sorgen, dass PHP gar nicht mehr aufgerufen wird, zum Beispiel mit einer statischen Wartungsseite per .htaccess.
Hilft die .htaccess-Regel zuverlässig?
Sie verkleinert die Angriffsfläche, ist aber kein Ersatz für das Update. Eine hundertprozentige Garantie gibt es dafür nicht, auch das PHP-Projekt sagt: Es gibt keine vollständige Abhilfe, nur das Update ist sicher.
Quellen
- PHP: Sicherheits-Release vom 21.10.2026 (betroffene Komponenten, gepatchte Versionen, Abhilfen)
- php-src Security Advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) · GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- Sansec: PHP2Shell – Critical PHP RCE (erste Angriffe am 21.10.2026)
- Kundeninformation von JTL-Software vom 21.10.2026 („PHP Sicherheits-Update – bei JTL gehostete Shops gesichert“)