Anfang Juni hat das Forensik-Team von Sansec eine schwerwiegende Schwachstelle in JTL-Shop gemeldet, einer der meistgenutzten Shop-Plattformen im deutschsprachigen Raum. Sie trägt die Kennung CVE-2026-54390 und erreicht auf der zehnstufigen CVSS-Skala den Wert 9,8 — den zweithöchsten überhaupt. JTL hat schnell reagiert und für jeden gepflegten Zweig eine korrigierte Fassung veröffentlicht.
Die eigentliche Nachricht für Shop-Betreiber steckt aber nicht im Update. Sie steckt in dem, was danach zu tun ist.
Was passiert ist
JTL-Shop setzt für seine Templates auf die Vorlagen-Engine Smarty. An einer Stelle wurden Eingaben aus dem Web ungeprüft an diese Engine weitergereicht. Wer weiß, wie man Smarty-Syntax formuliert, konnte dem Shop damit eigene Anweisungen unterschieben — ohne Benutzerkonto, ohne Passwort, allein durch den Aufruf einer Adresse. Fachlich heißt das Server-Side Template Injection.
Wie weit ein Angreifer damit kommt, hängt von der installierten Fassung ab:
| Version | Lage |
|---|---|
| 5.0.0 – 5.1.8 | nicht betroffen |
| 5.2.0 – 5.3.x | Zugangsdaten und Konfiguration auslesbar |
| 5.4.0 – 5.7.1 | zusätzlich Ausführung fremden Codes auf dem Server |
| 5.5.4 / 5.6.2 / 5.7.2 | behoben |
Ab 5.2.0 ließen sich Werte auslesen, die eigentlich nie den Server verlassen: der Blowfish-Schlüssel des Shops, Adresse, Name, Benutzer und Passwort der Datenbank, dazu die hinterlegten Zugänge für SMTP, Newsletter, FTP, Redis, OAuth und ein gespeicherter SFTP-Schlüssel.
Ab 5.4.0 wird es ernster. Dort registriert der Shop zwei Smarty-Modifikatoren, mit denen sich Dateien schreiben lassen. Über diesen Weg konnte ein Angreifer eine Hintertür im Web-Verzeichnis ablegen und anschließend Befehle mit den Rechten des Webservers ausführen. Von „jemand liest mit" wird daraus „jemand sitzt drin".
Warum das Update allein nicht reicht
Ein Update schließt die Tür. Es nimmt aber niemandem den Schlüssel wieder ab, der ihn sich vorher abgeholt hat.
Genau das ist hier der Punkt: Die Lücke gab Zugangsdaten preis. Wer eine verwundbare Fassung im Netz stehen hatte, muss Datenbankpasswort, Blowfish-Schlüssel und alle im Shop hinterlegten Zugänge als offengelegt behandeln — auch dann, wenn nichts Auffälliges passiert ist. Ein Angreifer, der sich das Datenbankpasswort notiert hat, braucht die Lücke nicht mehr. Er hat ja das Passwort.
Sansec berichtete zum Zeitpunkt der Veröffentlichung von keinen bekannten Angriffen. Das ist eine Momentaufnahme und keine Entwarnung: Sobald eine Lücke öffentlich beschrieben ist, dauert es erfahrungsgemäß nicht lange, bis automatisierte Scanner sie abklopfen.
Was jetzt zu tun ist
Erstens: Version feststellen. Sie steht im Backend unter „Systeminfo". Liegt sie zwischen 5.2.0 und 5.7.1, besteht Handlungsbedarf.
Zweitens: aktualisieren. Innerhalb des eigenen Zweigs auf 5.5.4, 5.6.2 oder 5.7.2. Für ältere 5er-Installationen, die den Sprung nicht sofort machen können, hat JTL zusätzlich einen Nachtrags-Patch für 5.0.0 bis 5.7.0 bereitgestellt.
Drittens: Zugangsdaten erneuern. Der Schritt, der am häufigsten vergessen wird und hier der wichtigste ist:
- Datenbankpasswort ändern
- Blowfish-Schlüssel neu setzen
- SMTP- und Newsletter-Zugänge erneuern
- FTP-, SFTP- und Redis-Zugänge erneuern, hinterlegte SFTP-Schlüssel austauschen
- OAuth-Geheimnisse der angebundenen Dienste neu erzeugen
Viertens: nachsehen, ob schon jemand da war. Ungewöhnliche PHP-Dateien im Web-Verzeichnis, fremde Administratorkonten, Änderungen an Templates, auffällige Einträge in den Server-Protokollen. Wer eine verwundbare Fassung längere Zeit offen im Netz hatte, sollte das nicht auf sich beruhen lassen.
Der unbequeme Teil
Schritt drei und vier sind lästig. Sie kosten Zeit, sie bringen sichtbar nichts, und der Shop läuft ja wieder. Genau deshalb bleiben sie so oft liegen — und genau deshalb tauchen Monate später Shops wieder auf, die längst gepatcht waren.
Ein Shop ist kein Stück Software, das man einmal aufsetzt. Er ist ein Dienst, der gepflegt werden will: Updates zeitnah einspielen, Zugangsdaten trennen, Protokolle nicht nur sammeln, sondern gelegentlich auch ansehen.
Unterstützung
Sie betreiben einen JTL-Shop und sind unsicher, ob Sie betroffen waren oder ob das Erneuern der Zugangsdaten sauber durchgelaufen ist? Wir sehen uns das an — von der Versionsprüfung über den Austausch der Zugänge bis zur Durchsicht auf Spuren eines Zugriffs.
Schreiben Sie uns über das Kontaktformular
Quellen: Sansec Forensics Team, „Unauthenticated remote code execution in JTL Shop", 17.06.2026 · NVD-Eintrag zu CVE-2026-54390 · JTL-Forum, Ankündigung zu JTL-Shop 5.7.2
Titelbild mit KI erstellt.