JTL-Shop-Sicherheitslücke CVE-2026-54390: Der 10-Sekunden-Test mit /site.php

Kritische Lücke in JTL-Shop 5.2.0 bis 5.7.1 (CVSS 9.3). So prüfen Sie in Sekunden, ob Ihr Shop kompromittiert ist – und was danach zu tun ist.

Aktuell werden reihenweise JTL-Shops kompromittiert. Ursache ist eine kritische Schwachstelle im Template-Handling, die JTL-Software Ende Juni 2026 gepatcht hat – nur läuft ein großer Teil der Shops weiterhin ungepatcht. Wer sein Backend seit Wochen nicht angefasst hat, sollte diesen Beitrag zu Ende lesen.

Der Schnelltest: Rufen Sie /site.php auf

Öffnen Sie im Browser Ihre Shop-Domain mit dem Zusatz /site.php:

https://ihr-shop.de/site.php

Erscheint dort irgendetwas außer einer 404-Fehlerseite, ist Ihr Shop mit hoher Wahrscheinlichkeit kompromittiert. Eine Datei namens site.php gehört nicht zum Auslieferungsumfang von JTL-Shop. Sie taucht bei einer ganzen Reihe der aktuell beobachteten Fälle als abgelegte Webshell im Webroot auf – also als Hintertür, über die Angreifer beliebige Befehle auf Ihrem Server ausführen können.

Ein negativer Test ist allerdings keine Entwarnung. Angreifer benennen Webshells beliebig. Der Test ist ein schneller Indikator, keine vollständige Prüfung.

⚠️ Das Löschen der site.php reicht nicht aus

Wenn Sie die Datei finden und löschen, haben Sie ein Symptom entfernt, nicht die Ursache. Zu diesem Zeitpunkt hatte ein Angreifer bereits Code-Ausführung auf Ihrem Server.

Vier Dinge bleiben nach dem Löschen bestehen:

1. Die Lücke ist weiterhin offen. Ohne Update auf eine gepatchte Version wird binnen Stunden die nächste Webshell abgelegt – automatisierte Scanner kommen wieder.
2. Es gibt fast nie nur eine Backdoor. Üblich sind mehrere: in Plugin- und Template-Verzeichnissen, in includes/, als eingeschleuster Code in bestehenden PHP-Dateien, als Cronjob oder als zusätzliches Admin-Konto.
3. Ihre Zugangsdaten sind bereits abgeflossen. BLOWFISH_KEY, Datenbank-, SMTP-, FTP- und OAuth-Credentials liegen beim Angreifer. Kein Löschvorgang holt sie zurück.
4. Andere Websites im selben Hosting sind ebenfalls betroffen. Eine Webshell ist nicht auf das Shop-Verzeichnis beschränkt – siehe Der Shop ist selten das einzige Opfer.

Die site.php ist der Rauchmelder, nicht das Feuer. Wenn der Test anschlägt, gehen Sie von einer vollständigen Systemkompromittierung aus und arbeiten Sie die Schritte unter Was jetzt zu tun ist ab.

Was genau ist passiert?

Die Schwachstelle trägt die Kennung CVE-2026-54390 und wird mit einem CVSS-v4-Score von 9.3 (kritisch) bewertet.

Technisch handelt es sich um eine Server-Side Template Injection (SSTI): Nutzereingaben landen ungefiltert in der Smarty-Template-Engine. Angreifer benötigen dafür keinen Login.

Die Auswirkungen hängen von der Version ab:

Für ältere Zweige (5.0.0 bis 5.7.0) hat JTL zusätzlich einen Back-Patch veröffentlicht.

Ab 5.2.0 lassen sich unter anderem der BLOWFISH_KEY, Datenbank-Host, -Name, -Benutzer und -Passwort auslesen – dazu die Shop-Konfiguration mit SMTP- und Newsletter-Zugangsdaten, FTP- und Redis-Einstellungen, OAuth-Secrets und dem hinterlegten SFTP-Private-Key. Ab 5.4.0 kommt der entscheidende Schritt hinzu: Über registrierte Smarty-Modifier wie unserialize und file_get_contents lässt sich eine Webshell ins Webroot schreiben und Code als Webserver-Benutzer ausführen.

Übersetzt heißt das: Bei einem erfolgreichen Angriff sind sämtliche im Shop hinterlegten Zugangsdaten als kompromittiert zu betrachten – auch die zu Systemen außerhalb des Shops.

Der Shop ist selten das einzige Opfer

Ein Punkt, der in der bisherigen Berichterstattung untergeht: Die Webshell ist nicht auf das Shop-Verzeichnis beschränkt. Sie führt Code als Webserver-Benutzer aus – und dieser Benutzer sieht in aller Regel deutlich mehr als nur den Shop.

Über relative Pfade (../../) lässt sich aus dem Shop-Verzeichnis heraus in höherliegende Verzeichnisse wechseln. Bei den üblichen Shared-Hosting- und Plesk-Setups liegen dort:

• weitere Websites desselben Accounts – WordPress-Blog, Firmenseite, Landingpages, Staging-Umgebungen
• Konfigurationsdateien anderer Anwendungen – jede wp-config.php, configuration.php oder .env mit eigenen Datenbank-Zugangsdaten
• Backups, die im Kundenverzeichnis abgelegt sind
• Mail-Verzeichnisse und Cronjob-Definitionen des Accounts

Läuft alles unter derselben Systembenutzer-Kennung – der Normalfall bei einem Hosting-Paket mit mehreren Domains –, kann der Angreifer in jeder dieser Anwendungen Dateien lesen, verändern und eigene Backdoors ablegen. Ein häufiges Muster: Der Shop wird gepatcht und bereinigt, die Webshell im WordPress-Blog nebenan bleibt liegen. Zwei Wochen später ist der Shop wieder kompromittiert – über den Nachbarn.

Selbst wenn die Datenbanken getrennt sind, hilft das wenig: Die Zugangsdaten stehen in den Konfigurationsdateien, die alle im selben Verzeichnisbaum liegen.

Praktisch heißt das: Wenn der /site.php-Test anschlägt, ist nicht „der Shop” kompromittiert, sondern das Hosting-Paket. Prüfen und bereinigen Sie jede Website und jede Anwendung, die unter derselben Benutzerkennung läuft, und rotieren Sie deren Zugangsdaten mit. Ein Blick in /httpdocs reicht nicht – gehen Sie eine Ebene höher.

Weitere Anzeichen einer Kompromittierung

Prüfen Sie zusätzlich zum /site.php-Test:

• Unbekannte PHP-Dateien im Webroot – vergleichen Sie den Dateibestand mit einem sauberen Backup oder einer frischen Installation derselben Version.
• Unbekannte Admin-Konten im Backend unter Benutzerverwaltung.
• Auffällige Zugriffe in den Access-Logs – ungewöhnliche POST-Requests, insbesondere ab Mitte Juni 2026.
• Veränderte Dateistrukturen – JTL-Shop bringt unter System → Diagnose eine Dateiprüfung mit, die Abweichungen gegenüber dem Auslieferungszustand meldet.
• Fremder JavaScript-Code im Frontend-Quelltext, besonders im Checkout.

Was jetzt zu tun ist

1. Patchen. Aktualisieren Sie umgehend auf 5.5.4, 5.6.2 oder 5.7.2 – je nach Ihrem Versionszweig. Wenn Sie nur eine Sache aus diesem Beitrag umsetzen, dann diese.

2. Zugangsdaten rotieren. Bei einem Verdacht auf Datenabfluss: Datenbank, FTP/SFTP, SSH, SMTP, Redis, OAuth-Secrets, Admin-Passwörter. Und zwar nicht nur die des Shops, sondern die aller Anwendungen im selben Hosting-Account. Der Patch entfernt keine bereits abgeflossenen Schlüssel.

3. Das gesamte Hosting prüfen – nicht nur den Shop. Angreifer platzieren Backdoors gerne in Template- und Plugin-Verzeichnissen, und über relative Pfade auch außerhalb des Shop-Verzeichnisses: in parallel gehosteten Websites, Staging-Instanzen und Backup-Ordnern. Und noch einmal in aller Deutlichkeit: Eine gefundene site.php zu löschen, ersetzt keinen dieser Schritte. Wer nur die Datei entfernt und weitermacht, betreibt einen Shop, in dem der Angreifer weiterhin ein- und ausgeht.

4. Bei bestätigter Kompromittierung: Neuaufbau erwägen. Ein System, auf dem fremder Code mit Webserver-Rechten lief, lässt sich nicht zuverlässig „bereinigen”. Der belastbare Weg ist ein sauberer Neuaufbau auf Basis eines Backups von vor dem Vorfall, kombiniert mit einem Import der Bestelldaten.

5. Datenschutz nicht vergessen. Sind personenbezogene Daten Ihrer Kunden betroffen, greift Art. 33 DSGVO – eine Meldung an die zuständige Aufsichtsbehörde ist innerhalb von 72 Stunden ab Kenntnis zu prüfen. Binden Sie Ihre Datenschutzbeauftragte oder Ihren Datenschutzbeauftragten frühzeitig ein.

Warum das so viele Shops trifft

Ein Shop, der läuft, wird selten angefasst. Genau darin liegt das Problem: Zwischen der Veröffentlichung eines Patches und der breiten Ausnutzung einer Lücke liegen inzwischen oft nur Tage, weil automatisierte Scanner das Netz nach verwundbaren Installationen absuchen. Wer keinen Prozess für Sicherheitsupdates hat, verlässt sich darauf, dass niemand vorbeischaut.

Ein Wartungsvertrag löst das nicht durch Magie, sondern durch Routine: eine Person, die zuständig ist, ein definierter Zeitpunkt für Updates, ein getestetes Backup und ein Monitoring, das Änderungen am Dateibestand meldet.

Wir prüfen Ihren Shop

Wenn Sie unsicher sind, ob Ihr JTL-Shop betroffen ist, oder wenn der /site.php-Test bei Ihnen angeschlagen hat: Wir schauen uns das an – Versionsstand, Dateibestand, Logs, Admin-Konten. Und dabei nicht nur den Shop, sondern alle Websites, die im selben Hosting-Account liegen.

Shop-Sicherheitscheck anfragen oder direkt anrufen unter 05121 – 29 520 22.

Wenn Ihr Shop bereits defaced oder offensichtlich kompromittiert ist, schreiben Sie das bitte in die erste Zeile Ihrer Nachricht – solche Anfragen ziehen wir vor.

Quellen: Sansec: Unauthenticated remote code execution in JTL Shop · CVE-2026-54390 · com-ins-netz: JTL-Shop-Sicherheitslücke