Patch eingespielt, Shop trotzdem offen: Was beim Aufräumen nach CVE-2026-54390 übersehen wird
Das Update schließt die Tür. Es entfernt aber nicht, was in der Zwischenzeit im Verzeichnis liegen geblieben ist — und es rotiert keine Zugangsdaten.
Die Lücke selbst ist inzwischen gut dokumentiert: CVE-2026-54390, eine Server-Side Template Injection über die Smarty-Engine im E-Mail-Template-System, bewertet mit einem CVSS-Wert von 9,8. Betroffen sind die Versionen 5.2.0 bis 5.7.1 — ab 5.4.0 lässt sie sich ohne Anmeldung bis zur vollständigen Codeausführung missbrauchen. Gepatcht ist sie in 5.5.4, 5.6.2 und 5.7.2, für ältere Stände gibt es einen Back-Patch.
Was in den Beschreibungen kürzer wegkommt, ist der Teil danach. Und der entscheidet, ob Sie nach dem Update wirklich sauber sind.
Warum das Update allein nichts beweist
Über diese Lücke ließen sich laut der technischen Analyse unter anderem der Blowfish-Key, die Datenbank-Zugangsdaten sowie Zugänge für SMTP, Newsletter, FTP, Redis und OAuth auslesen. Ab Version 5.4.0 konnte zusätzlich eine Datei im Webverzeichnis abgelegt werden.
Daraus folgt eine unangenehme Logik: Das Update schließt die Tür, aber es holt nichts zurück, was vorher hinausgetragen wurde, und es räumt nichts weg, was hereingetragen wurde. Zugangsdaten, die abgeflossen sind, bleiben gültig. Dateien, die abgelegt wurden, bleiben liegen — und zwar in einem Verzeichnis, das per Definition aus dem Internet erreichbar ist.
Drei Dinge, die ich in der Praxis übersehen gesehen habe
1. Die Artefakte, die kein Aufräumskript kennt
Wenn ein Angriffsskript läuft, hinterlässt es oft mehr als die eigentliche Hintertür. Es schreibt Protokolle, Zwischenergebnisse, Berichte. Beim Aufräumen sucht man nach PHP-Dateien — das ist naheliegend und deckt genau die Hälfte ab.
In einem Fall, den ich untersucht habe, lagen drei Wochen nach dem sauber durchgeführten Patch immer noch mehrere Textdateien im Webroot, angelegt vom Skript des Angreifers. Inhalt: Pfad des Skripts, veränderte Dateien im Kern des Shops — und die Datenbank-Zugangsdaten im Klartext. Endung .txt, also keine Ausführung durch PHP, sondern direkte Ausgabe im Browser. Jeder, der die URL kannte, konnte sie lesen.
Wonach Sie also suchen sollten, ist nicht nur *.php:
# alles, was im fraglichen Zeitraum im Webroot entstanden ist
find /pfad/zum/webroot -maxdepth 2 -newermt "2026-06-01" ! -newermt "2026-07-15" \
\( -name "*.txt" -o -name "*.log" -o -name "*.php" -o -name "*.bak" \) -ls
Und danach: Prüfen Sie über HTTP, nicht nur im Dateisystem. Was Sie im Browser abrufen können, kann jeder abrufen.
2. Die Rotation, die nur halb stattgefunden hat
„Credentials rotiert” steht schnell in einem Protokoll. In der Praxis wird oft das rotiert, woran man zuerst denkt — Admin-Zugang, FTP — und das vergessen, was tief in einer Konfigurationsdatei steht.
Genau dort lag im geschilderten Fall das Problem: Das Datenbank-Passwort in der Shop-Konfiguration war identisch mit dem, das in den öffentlich lesbaren Dateien stand. Wochen nach dem „abgeschlossenen” Cleanup.
Die Konsequenz für Ihre Checkliste: Vergleichen Sie jede rotierte Zugangsdate mit dem Wert, der tatsächlich im System steht. Nicht abhaken, sondern nachsehen. Betroffen sind mindestens: Datenbank, Shop-Administration, FTP und SFTP, SMTP und Newsletter-Versand, Redis, angebundene Dienste mit OAuth-Zugängen, sowie der Blowfish-Key.
Beim Blowfish-Key gilt eine Besonderheit: Er verschlüsselt Daten im Shop, ein Wechsel ist deshalb nicht folgenlos. Klären Sie vorher mit JTL oder Ihrem Dienstleister, was daran hängt, statt ihn spontan zu ändern.
3. Die Backup-Datei, die man selbst anlegt
Das ist der Fehler, der beim Aufräumen entsteht — nicht beim Angriff. Man will vorsichtig sein, sichert die Konfiguration vor der Änderung und legt sie daneben:
includes/config.JTL-Shop.ini.php <- wird von PHP ausgeführt, gibt nichts preis
includes/config.JTL-Shop.ini.php.bak <- wird ausgeliefert wie eine Textdatei
Die Endung entscheidet. Alles, was nicht auf .php endet, liefert der Webserver als Text aus — inklusive aller Zugangsdaten darin. Ein Backup mit Zugangsdaten gehört niemals in ein Verzeichnis, das aus dem Internet erreichbar ist, auch nicht für zehn Minuten.
Ich habe diesen Fehler selbst gemacht, bei einer Passwortrotation, und ihn innerhalb weniger Minuten bemerkt. Genau deshalb steht er hier: Er passiert nicht aus Nachlässigkeit, sondern aus Vorsicht.
Die Nachkontrolle, die ich empfehle
- Version prüfen — läuft tatsächlich 5.5.4, 5.6.2, 5.7.2 oder ein zurückportierter Patch?
- Webroot durchsehen — nach Dateien aller Endungen im Zeitraum des Vorfalls, nicht nur nach PHP.
- Jede gefundene Datei über HTTP testen, bevor Sie sie löschen. Sie wollen wissen, was öffentlich war.
- Kern-Dateien gegen eine saubere Version vergleichen — ein modifizierter Kern ist ein deutliches Zeichen und wird beim Update nicht zwingend überschrieben.
- Alle Zugangsdaten rotieren und die Rotation verifizieren, Wert für Wert.
- Administratorkonten und geplante Aufgaben durchsehen — beides sind beliebte Wege, sich Zugang zu erhalten.
- Prüfen, ob abgelegte Dateien in Suchmaschinen gelandet sind. Wenn ja, gehört eine Entfernung beantragt, sonst stehen die Inhalte weiter in Caches.
- Rechtlich bewerten lassen, ob eine Meldung nach Artikel 33 DSGVO nötig ist. Die Frist beträgt 72 Stunden ab Kenntnis.
Was ich daraus mitgenommen habe
Ein Cleanup ist erst dann fertig, wenn jemand von außen nachgesehen hat. Nicht im Dateisystem, nicht im Protokoll — über HTTP, so wie ein Fremder es sähe. Diese eine Perspektive fehlt in fast jeder Nachbereitung, und sie ist die einzige, die die Frage beantwortet, um die es geht: Was kann ein Unbeteiligter gerade sehen?
Wenn Sie unsicher sind, ob bei Ihnen wirklich alles erledigt ist: Der Blick von außen dauert eine halbe Stunde und ist die günstigste Versicherung in diesem ganzen Thema.
Quellen: Technische Analyse der Schwachstelle bei Sansec Threat Research, Einstufung im National Vulnerability Database. Abgerufen am 29.07.2026.
Häufige Fragen
Reicht das Update auf eine gepatchte Version aus?
Nein. Das Update schließt die Schwachstelle, entfernt aber nichts, was ein Angreifer vorher abgelegt oder ausgelesen hat. Wenn Zugangsdaten abgeflossen sind, bleiben sie gültig, bis Sie sie ändern — unabhängig davon, welche Shop-Version läuft.
Woran erkenne ich, ob mein Shop tatsächlich betroffen war?
Anhaltspunkte sind unbekannte Dateien im Webroot mit Zeitstempeln aus dem fraglichen Zeitraum, veränderte Dateien im Kern des Shops, neu angelegte Administratorkonten und auffällige Muster im Zugriffslog. Sicherheit gibt nur eine systematische Prüfung — im Zweifel mit jemandem, der so etwas schon gemacht hat.
Muss ich einen Vorfall melden?
Wenn personenbezogene Daten betroffen sein könnten, greift die Meldepflicht nach Artikel 33 DSGVO mit einer Frist von 72 Stunden ab Kenntnis. Bei einer Lücke, über die sich Datenbank-Zugangsdaten auslesen lassen, ist ein Abfluss von Kundendaten zumindest nicht auszuschließen — das sollten Sie rechtlich bewerten lassen, statt es abzuhaken.
