CVE-2026-54390: Wie ich einen Angriff auf einen JTL-Shop abgewehrt habe, und warum ich seither CVEs automatisiert überwache

Ende Juni 2026 hat mir ein Kunde eine harmlos wirkende Kontaktformular-Mail weitergeleitet: Betreff unauffällig, im Nachrichtenfeld nur ein paar kryptische Zeichen. Man hat natürlich sofort gesehen, das ist kein Tippfehler, das ist ein Angriff. Es war einer, und zwar ein automatisierter Massenangriff auf eine frisch veröffentlichte, kritische Lücke in JTL-Shop. Hier ist, was passiert ist, wie ich es eingegrenzt habe und was ich daraus für meine Arbeit geändert habe.

Was CVE-2026-54390 ist

CVE-2026-54390 ist eine kritische, unauthentifizierte Server-Side Template Injection (SSTI) in JTL-Shop, gefunden vom Sansec Threat Research Team. Der Knackpunkt: die Lücke sitzt nicht im sichtbaren Nachrichtentext des Kontaktformulars, sondern im E-Mail-Betreff, der beim Versand der Bestätigungsmail als Smarty-Template gerendert wird. Wer dort Template-Code einschleust, bringt den Server dazu, ihn auszuführen.

Die Auswirkung hängt an der Version:

• 5.2.0 bis 5.3.x: Datendiebstahl (Verschlüsselungs-Key, DB-Zugangsdaten, SMTP- und API-Keys).
• 5.4.0 bis 5.7.1: vollständige unauthentifizierte Remote Code Execution, fremder Code läuft also als Webserver-Benutzer.
• Geschlossen ab 5.5.4 / 5.6.2 / 5.7.2.

Wenn du einen JTL-Shop betreibst und nicht auf einem dieser Patch-Stände bist: aufhören zu lesen, patchen, dann weiterlesen.

Wie der Angriff aussieht

Im Nachrichtenfeld landet verschleierter Smarty-Code. Statt eine URL im Klartext zu schreiben, baut der Bot sie zeichenweise zusammen, um simple Stichwort-Filter zu umgehen:

{assign var=u value=chr(104)|cat:chr(116)|cat:chr(116)|cat:chr(112)...}
{assign var=x value=$u|file_get_contents|urldecode|unserialize}

Übersetzt: lade eine Payload von einem fremden Server, dekodiere sie, und mach per unserialize ein PHP-Objekt daraus. Über eine sogenannte Gadget-Chain wird beim Deserialisieren Code ausgeführt. Eine zweite Variante schreibt direkt eine Webshell-Datei in den Shop.

Warum ein Shop getroffen wurde und ein anderer nicht

Ich betreue mehrere JTL-Shops, und genau dieselbe Angriffswelle lief gegen alle. Das Ergebnis war unterschiedlich, und der einzige Grund war die Version.

• Ein Shop war taggleich auf 5.7.2 aktualisiert. Der Angriff prallte ab. Das stärkste Entwarnungssignal: der Betreiber bekam den Schadcode als Klartext in der Benachrichtigungs-Mail. Das Feld wurde also als Text behandelt, nicht als Template ausgeführt.
• Ein anderer Shop lief noch auf 5.7.1, also im RCE-Bereich. Dort feuerte die Lücke: der Bot legte eine Marker-Datei im Shop-Verzeichnis an. Glück im Unglück, der fremde Server war nicht erreichbar, also blieb die Datei leer und es landete keine funktionsfähige Webshell. Aber die Lücke war nachweislich offen.

Die Lehre daraus: dass die Mail im Klartext ankommt, ist nur dann eine Entwarnung, wenn der Shop schon gepatcht ist. Bei einem ungepatchten Shop sitzt die eigentliche Payload im Betreff, und die harmlose "Hi"-Nachricht kann trotzdem ein Treffer sein.

Wie ich den Schaden eingegrenzt habe

Ein reiner Blick ins Shop-Verzeichnis reicht nicht. Ich prüfe vier Dinge, sonst übersieht man, ob im verwundbaren Zeitfenster wirklich etwas passiert ist:

1. Versions-Timeline: War der Shop zum Zeitpunkt der Angriffs-Mail noch auf der verwundbaren Version, oder schon gepatcht?
2. Die komplette Kontakt-Historie in der Datenbank, alle Felder: Der Schadcode kann nicht nur im Nachrichtentext stehen, sondern auch in Vor- und Nachname oder im Betreff.
3. Temporäre Verzeichnisse: Manche Payload-Familien schreiben ihre Dateien nach /tmp, nicht in den Shop-Ordner. Wer nur den Webroot prüft, übersieht das.
4. Frisch geänderte Dateien exakt im Angriffsfenster, nicht nur "letzte Stunde".

So konnte ich für den getroffenen Shop belegen: die Lücke wurde markiert, aber es lief kein funktionsfähiger Code, keine Webshell, kein Persistenz-Mechanismus.

Eine ehrliche Einschränkung gehört dazu: ob ein Key über einen Outbound-Request abgeflossen ist, lässt sich auf Shared-Hosting nachträglich nicht zu hundert Prozent ausschließen, weil es kein zugängliches Ausgangs-Log gibt. Über den Angriffsvektor selbst, das Kontaktformular, war aber kein einziger Versuch protokolliert, der Zugangsdaten ausliest. Das ist die belastbarste Aussage, die man treffen kann, ohne sie zu schönen.

Was JTL-Shop-Betreiber jetzt tun sollten

• Patchen auf 5.7.2 / 5.6.2 / 5.5.4. Das schließt die Lücke. Alles andere ist Symptombehandlung.
• Bei Verdacht auf Einschlag: die vier Punkte oben prüfen, nicht nur ins Verzeichnis schauen.
• Wenn die Lücke offen war: Zugangsdaten rotieren (DB, Admin, SMTP, API-Keys). Den Verschlüsselungs-Key nur mit Plan tauschen, denn er entschlüsselt gespeicherte Daten.
• IP-Sperren bringen wenig, die Scanner rotieren ihre Adressen. Nur bei wiederholten Treffern derselben Quelle sinnvoll.

Die eigentliche Lehre: proaktiv statt reaktiv

Was mich am meisten gewurmt hat: der Patch war schon einige Tage öffentlich verfügbar, bevor er bei dem betroffenen Shop eingespielt wurde. Die Lücke war bekannt, der Fix war da, und trotzdem lief der Shop im verwundbaren Fenster. Genau diese Lücke zwischen "Patch existiert" und "Patch ist eingespielt" ist das eigentliche Risiko.

Also habe ich danach einen automatisierten Wächter gebaut. Einmal täglich prüft er die relevanten Quellen, GitHub Security Advisories, die NVD-CVE-Datenbank und das JTL-Forum, gegen eine Liste der Technologien, die ich und meine Kunden tatsächlich einsetzen. Neue Funde werden von einem Sprachmodell kurz eingeordnet (relevant ja oder nein, Schwere, welcher Kunde betroffen), und bei kritischen oder JTL-spezifischen Treffern bekomme ich sofort eine Nachricht. Kosten: Cent-Beträge im Monat, weil nur neue Funde überhaupt analysiert werden.

Das ist der Unterschied zwischen "ich erfahre von einer Lücke, weil ein Kunde mir eine seltsame Mail weiterleitet" und "ich weiß von der Lücke an dem Tag, an dem sie veröffentlicht wird".

Wann sich das lohnt, und wann nicht

Ein automatisiertes Sicherheits-Monitoring lohnt sich, wenn du mehrere Systeme oder Kundenprojekte mit unterschiedlichen Technologien betreust. Dann verlierst du sonst den Überblick, welche Lücke welches System betrifft.

Wenn du einen einzelnen Shop betreibst, brauchst du keinen eigenen Wächter. Dann reichen zwei Dinge: konsequente Update-Disziplin, also Sicherheits-Patches innerhalb von Tagen statt Wochen, und der offizielle JTL-Sicherheits-Newsletter. Das deckt den Großteil ab. Den automatisierten Weg gehst du erst, wenn das manuelle Nachverfolgen über mehrere Systeme selbst zur Fehlerquelle wird.

So oder so gilt: die gefährlichste Phase ist nicht der Tag, an dem eine Lücke entdeckt wird. Es ist die Zeit danach, in der der Patch da ist und nicht eingespielt wird.

Wenn du einen JTL-Shop betreibst und nicht sicher bist, auf welchem Stand er ist, oder ob in den letzten Wochen etwas durchgekommen ist: schreib mir, dann schauen wir gemeinsam drauf.