Seit Bekanntwerden der Schwachstelle CVE-2026-54390 am 17. Juni 2026 registrieren unsere Monitoring-Systeme bei EcomSec eine deutliche und anhaltende Zunahme automatisierter Angriffe auf JTL-Shop-Installationen. Betroffen sind Shops aller Größen – vom kleinen Einzelhändler bis zum etablierten Multichannel-Händler. Wenn Sie JTL-Shop betreiben und noch kein Update eingespielt haben, sollten Sie diesen Artikel jetzt lesen.
Was ist passiert?
Am 17. Juni 2026 veröffentlichte das Sicherheitsforschungsteam von Sansec eine kritische Schwachstelle in JTL-Shop, die sie selbst entdeckt und koordiniert an JTL gemeldet hatten . JTL reagierte professionell und schnell: Noch am selben Tag wurden Sicherheits-Patches für alle aktiven Versionszweige veröffentlicht.
Die Schwachstelle ist als CVE-2026-54390 registriert und trägt einen CVSS-Score von 9.8 (KRITISCH) . Sie betrifft JTL-Shop in den Versionen 5.2.0 bis 5.7.1 und steckt in der Datei SmartyRenderer.php, die für die Verarbeitung von E-Mail-Templates zuständig ist.
Die Technik hinter dem Angriff: Server-Side Template Injection (SSTI)
Die Schwachstelle ist eine sogenannte Server-Side Template Injection (SSTI). Dabei werden Benutzereingaben – zum Beispiel aus einem Kontaktformular oder einem E-Mail-Betreff – ungefiltert an die Smarty Template Engine des Shops weitergegeben . Smarty interpretiert diese Eingaben als Programmcode und führt ihn aus.
Das Ausmaß des Schadens hängt dabei direkt von der installierten JTL-Shop-Version ab:
| Version | Risiko | Konsequenz |
|---|---|---|
| 5.0.0 – 5.1.8 | Nicht betroffen | – |
| 5.2.0 – 5.3.x | Hoch | Auslesen von Datenbankpasswort und Blowfish-Key |
| 5.4.0 – 5.7.1 | Kritisch | Vollständige Serverübernahme via Remote Code Execution (RCE) |
| 5.5.4 / 5.6.2 / 5.7.2 | Gepatcht | – |
Ein Angreifer kann auf Shops ab Version 5.4.0 eine sogenannte Webshell auf dem Server hinterlegen – eine Backdoor, die dauerhaften, versteckten Zugriff auf das gesamte System ermöglicht. Von dort aus sind Datenbankzugriff, Manipulation von Bestellungen, Diebstahl von Kundendaten und die vollständige Übernahme des Servers möglich .
Was unsere Monitoring-Systeme zeigen: Die Angriffe laufen bereits
Theorie ist das eine. Was wir in den Logfiles unserer Systeme sehen, ist das andere. Unmittelbar nach Veröffentlichung des Patches begannen automatisierte Scanner, das Internet nach verwundbaren JTL-Shops abzusuchen. Das ist ein bekanntes Muster: Sobald ein Patch erscheint, wissen Angreifer genau, wo die Lücke sitzt – und beginnen sofort, ungepatchte Systeme zu finden.
Ein typischer Angriffspayload, den wir in unseren Logs dokumentiert haben:
{assign var=u value=chr(104)|cat:chr(116)|cat:chr(116)...}Dieser Smarty-Code versucht, eine URL zusammenzusetzen und eine externe Datei (die Webshell) auf den Server zu laden. Die Angreifer-User-Agents, die wir beobachtet haben, lassen dabei keinerlei Zweideutigkeit zu:
jtl-cve-2026-54390-authorized-check/1.0
CVE-2026-54390-PoC/1.0Das sind keine zufälligen Bots. Das sind gezielte, automatisierte Exploit-Werkzeuge, die speziell für diese Schwachstelle gebaut wurden.
Angriffsphasen im Detail
Die Angriffe folgen einem klaren, vierstufigen Muster, das wir in unseren Logs vollständig dokumentieren konnten:
- Phase 1 – Reconnaissance: Automatisierte Scanner prüfen, ob der Shop eine verwundbare JTL-Version betreibt. Dieser Schritt ist passiv und hinterlässt kaum Spuren.
- Phase 2 – Exploitation: Der SSTI-Payload wird über das Kontaktformular oder einen anderen E-Mail-Auslöser eingeschleust. Der Angreifer versucht, den Smarty-Code zur Ausführung zu bringen.
- Phase 3 – Verification: Der Angreifer prüft, ob eine Backdoor-Datei (proof-ssti.php) erfolgreich auf dem Server angelegt wurde. Dieser Schritt ist der eindeutige Beweis für eine erfolgreiche Kompromittierung.
- Phase 4 – Persistenz: Bei Erfolg wird eine vollwertige Webshell installiert, die dauerhaften, versteckten Zugriff ermöglicht – auch nach einem späteren Shop-Update.
Herkunft der Angreifer
Wir konnten die folgenden Angreifer-IPs in unseren Logs identifizieren und über öffentliche Threat-Intelligence-Datenbanken validieren:
| IP-Adresse | Herkunft | Infrastruktur | Einordnung |
|---|---|---|---|
| 45.77.118.169 | USA (Miami, Florida) | Vultr Cloud Hosting | Gemieteter Cloud-Server, laut Shodan für CVE-Scans missbraucht |
| 85.97.32.16 | Türkei (Istanbul) | Turk Telekom | Regulärer Internetanschluss |
| 64.190.76.3 | Italien (Turin) | Osservatorio Nessuno | Proxy-Server / anonymisierter Zugang |
Das Muster ist typisch für organisierte Scan-Kampagnen: Ein gemieteter Cloud-Server übernimmt die schwere Arbeit der Exploitation, während Proxy-Server und reguläre Anschlüsse zur Verschleierung eingesetzt werden.
Bin ich betroffen?
Grundsätzlich ist jede JTL-Shop-Installation potenziell ein Ziel. Besonders gefährdet sind Shops, die eine der folgenden Bedingungen erfüllen:
Ihr Shop läuft auf einer Version zwischen 5.2.0 und 5.7.1 und hat das Sicherheitsupdate noch nicht eingespielt. Ihr Shop verfügt über ein aktives Kontaktformular oder andere Formulare, die eine E-Mail-Benachrichtigung auslösen. Ihr Hosting-Anbieter hat Sie nicht automatisch abgesichert (JTL-eigenes Hosting wurde bereits automatisch gepatcht).
Wie prüfen Sie Ihre Version? Melden Sie sich im JTL-Shop Backend unter /admin an. Im Dashboard-Widget “Informationen” steht Ihre aktuelle Version.
Was Sie jetzt sofort tun müssen
Schritt 1: Update einspielen
Das ist die einzige wirklich wirksame Maßnahme. Spielen Sie umgehend das Sicherheitsupdate ein:
- Auf Version 5.7.1? → Update auf 5.7.2
- Auf Version 5.6.x? → Update auf 5.6.2
- Auf Version 5.5.x? → Update auf 5.5.4
- Ältere 5.x-Versionen? → Manuellen Patch von JTL einspielen (verfügbar im JTL-Forum)
Legen Sie vor dem Update zwingend ein vollständiges Backup an (Datenbank und alle Dateien).
Schritt 2: Logs auf Kompromittierung prüfen
Prüfen Sie Ihre Server-Logs z.B. auf folgende Indikatoren:
# Alle PHP-Aufrufe die nicht zum Shop gehören
zcat logs/logname.gz \
| grep "GET .*\.php" \
| grep -v "index\.php\|io\.php\|jtl\.php\|status\.php" \
| grep " 200 "Wenn Sie diese Einträge finden und Ihr Shop zum Zeitpunkt des Angriffs ungepatch war, müssen Sie von einer Kompromittierung ausgehen und umgehend handeln.
Schritt 3: Bekannte Angreifer-IPs temporär sperren
Als sofortige Überbrückungsmaßnahme können Sie die Angreifer-IPs aus den Logs in Ihrer .htaccess sperren:
deny from 45.77.118.169
deny from 85.97.32.16
deny from 64.190.76.3Wichtig: Das ist eine temporäre Maßnahme, kein Ersatz für das Update. Angreifer wechseln ihre IP-Adressen regelmäßig.
Schritt 4: Secrets rotieren
Wenn Ihr Shop zum Zeitpunkt der Scan-Wellen verwundbar war, müssen Sie davon ausgehen, dass folgende Daten kompromittiert wurden:
- Datenbankpasswort
- Blowfish-Key (für verschlüsselte Daten im Shop)
- SMTP-Zugangsdaten
- FTP- und Redis-Zugangsdaten
- Gespeicherte SFTP-Schlüssel
Ändern Sie alle diese Zugangsdaten, auch wenn Sie keine eindeutigen Anzeichen einer Kompromittierung finden.
Was tun, wenn der Shop bereits kompromittiert wurde?
Wenn Sie in Ihren Logs den String proof-ssti.php finden oder eine unbekannte PHP-Datei im Web-Root entdecken, ist Ihr Shop kompromittiert. In diesem Fall gilt:
Nehmen Sie den Shop sofort offline. Stellen Sie ein sauberes Backup ein, das vor dem Zeitraum der Angriffe erstellt wurde. Ändern Sie alle Zugangsdaten. Informieren Sie Ihre Kunden über den Vorfall – das ist nach DSGVO Art. 33 bei einem Datenschutzverstoß mit Risiko für Betroffene innerhalb von 72 Stunden an die zuständige Aufsichtsbehörde zu melden. Ziehen Sie professionelle Hilfe hinzu.
Wenn Sie unsicher sind, ob Ihr Shop betroffen ist, oder wenn Sie Unterstützung bei der Analyse Ihrer Logs, dem Update-Prozess oder der Härtung Ihres Systems benötigen, melden Sie sich bei uns: info [@] ecomsec.de
Wir bieten eine kostenlose Ersteinschätzung an.