JTL-Shop Sicherheitsupdate 5.8.2: Was Händler jetzt tun

Auf einen Blick

• ✓Fixversionen: 5.8.2, 5.7.5 und 5.6.5, veröffentlicht am 14.10.2026. JTL empfiehlt, in der eigenen Versionslinie zu bleiben. Shops auf 5.3 bis 5.5 bekommen laut JTL keine Patches mehr, dort ist das Upgrade auf 5.6.5 oder neuer die einzige dauerhafte Abhilfe.
• ✓Die kritische Lücke (CVE-2026-103904) ist ein gespeichertes Cross-Site-Scripting in der Consent-Statistik und betrifft alle Versionen ab 5.4.0. Bis zum Update öffnest du diese Statistik im Backend nicht. Bereits eingeschleuste Einträge entfernt das Update nicht, die musst du in der Datenbank prüfen.
• ✓Für beide Lücken meldet JTL Stand 14.10.2026 keine Hinweise auf Ausnutzung. Die Ausnutzung der hohen Lücke (CVE-2026-103905) ist laut JTL sehr einfach, deshalb gilt: zeitnah aktualisieren.

Die Vlarom E-Commerce Agentur ist JTL Service Partner Gold aus Ahrensfelde bei Berlin und betreut über 300 aktive Kunden im JTL-Ökosystem, seit über 10 Jahren. Wir spielen JTL-Shop-Updates für Händler seit Jahren ein. Alle Angaben zu den Lücken stammen aus den beiden Sicherheitshinweisen von JTL, dem Releaseforum und den CVE-Datensätzen, abgerufen am 14.10.2026. Wo diese Quellen voneinander abweichen oder etwas offen lassen, steht das hier so.

Beide Hinweise tragen bei JTL die Version 1.0 und das Datum 14. Oktober 2026. Schweregrade und Betroffenheit können sich ändern, prüfe sie vor dem Update noch einmal gegen die JTL-Sicherheitshinweise.

Wer den Shop selbst oder bei einem anderen Anbieter hostet, muss das Update selbst einspielen.

Die Angaben aus den beiden JTL-Hinweisen im Überblick:

• →CVE-2026-103905: Wartungsmodus ohne Anmeldung umschalten (hoch): Laut JTL kann jeder mit einem einzigen Aufruf einer bestimmten Shop-Adresse den Wartungsmodus ein- oder ausschalten, ohne Zugangsdaten. Ist er aktiv, sehen Kunden nur die Wartungsseite und können nicht bestellen. CVSS 3.1: 7.5, CVSS 4.0: 8.7. Betroffen sind 5.3.0 bis 5.8.1, sofern die Version unter der Fixversion ihrer Linie liegt (5.6.5, 5.7.5, 5.8.2). Zugriff auf Kunden- oder Bestelldaten, Zugangsdaten oder den Server gewährt die Lücke laut JTL nicht.
• →CVE-2026-103904: gespeichertes XSS in der Consent-Statistik (kritisch): Der Endpunkt /_updateconsent übernimmt laut JTL beliebige Einwilligungs-Bezeichnungen ohne Anmeldung, die Backend-Statistik gibt sie ohne HTML-Maskierung aus. Ausgelöst wird der Code, wenn ein Administrator mit dem Recht STATS_CONSENT_VIEW die Statistik öffnet. CVSS 3.1: 9.3, CVSS 4.0: 8.6. Betroffen sind alle Versionen ab 5.4.0 unterhalb von 5.6.5, 5.7.5 und 5.8.2. Vor 5.4.0 ist der Shop von dieser Lücke nicht betroffen.
• →Fixversionen: 5.8.2, 5.7.5 und 5.6.5. Patches gibt es jeweils aus der eigenen Linie, zum Beispiel von 5.7.0 bis 5.7.4 auf 5.7.5. Zusätzlich nennt das Releaseforum zwei Path-Traversal-Lücken, die Admin-Zugriff voraussetzen, darunter eine zum Löschen beliebiger Dateien im Backend.
• →Ausnutzung: Keine Hinweise auf Ausnutzung bekannt, Stand 14.10.2026, für beide Lücken laut JTL. Das ist eine Momentaufnahme, kein Dauerzustand.

Die kritische Lücke trifft mehr Versionen, als die Schlagzeile vermuten lässt, und sie trifft ausdrücklich auch 5.7.2. Wer nach dem Vorfall mit CVE-2026-54390 auf 5.7.2 gewechselt ist, muss erneut ran.

Beide Lücken sind unterschiedlich gelagert. Die eine stört den Betrieb, die andere zielt auf das Backend.

1

Lücke 1: Der Wartungsmodus wird zur Angriffsfläche

Im JTL-Sicherheitshinweis zum Wartungsmodus steht die Folge so: Ist der Wartungsmodus aktiv, kommt kein Kunde mehr durch die Bestellstrecke. Wiederholte Aufrufe können den Zustand nach dem Zurücksetzen erneut herbeiführen, ein dauerhaftes Festsetzen gibt es laut JTL nicht. Für einen Shop mit laufendem Tagesgeschäft ist das trotzdem ein Umsatzrisiko, auch wenn keine Daten abfließen.

Eine Unschärfe müssen wir offen benennen: Der JTL-Hinweis spricht vom Wartungsmodus. Der CVE-Datensatz der ENISA beschreibt dieselbe Lücke als Umschalten des Plugin-Safe-Mode, bei dem alle installierten Plugins samt Zahlungs- und Versandanbindungen abgeschaltet werden. Welche Beschreibung technisch zutrifft, haben wir nicht verifiziert. Wir folgen im Text dem JTL-Wortlaut.

2

Lücke 2: Der Angriff wartet auf den Admin

Ein Besucher kann über den Consent-Endpunkt Text in die Tabelle consent_statistics schreiben, maximal 24 Zeichen pro Eintrag. Passiert ist dann noch nichts. Erst wenn ein Administrator mit dem Recht STATS_CONSENT_VIEW die Statistik öffnet, kann der eingeschleuste Code im Browser des Admins laufen. Ohne diesen Aufruf bleibt der Text laut JTL wirkungslos.

Die Auswirkung hängt an den Rechten des Admins. Laut JTL sind Aktionen im Namen des Admins möglich (Einstellungen, Benutzer, Rechte), ebenso das Lesen aller Daten, die er sehen darf, etwa Kundendaten. Mit Plugin- oder Template-Rechten kann es laut JTL bis zur Ausführung von Code auf dem Server reichen. Pauschal von einer Serverübernahme zu sprechen, wäre falsch, es gilt nur unter dieser Bedingung.

3

Das Update räumt nicht auf

Der Punkt, den Händler am ehesten übersehen: Bereits eingeschleuste Einträge entfernt das Update laut JTL nicht. Sie werden danach nicht mehr als Programmcode ausgeführt, bleiben aber in der Datenbank, solange du sie nicht löschst. Die Kontrolle der Consent-Statistik gehört deshalb zum Update dazu.

4

5.3 bis 5.5: Upgrade statt Patch

Für 5.3 bis 5.5 schreibt JTL, diese Versionen würden nicht mehr mit Patches versorgt. Das Upgrade auf 5.6.5 oder neuer sei die einzige dauerhafte Abhilfe. Die JTL-Übersicht der unterstützten Produktversionen (ohne Stand-Datum, abgerufen am 14.10.2026) führt 5.5 noch mit ‚nur kritische Security Fixes‘. Maßgeblich ist der Hinweis vom 14.10. JTL stellt zwar ein Paket mit Patch-Dateien bereit, dessen Ordner reichen bis 5.3.0. Ob JTL diese Kombination für ältere Linien trägt, ist nicht belegt. Dauerhafte Abhilfe ist laut JTL nur das Upgrade.

Sieben Schritte in der Reihenfolge der JTL-Hinweise: Version klären, absichern, aktualisieren, danach Wartungsmodus und Consent-Statistik prüfen.

Shop-Version im Backend nachsehen. Bei JTL-Hosting ist nichts zu tun, die Lücken sind dort laut JTL geschlossen. Bei Selbsthosting oder einem anderen Hoster ist jede Version von 5.3.0 bis 5.8.1 betroffen, die unter 5.6.5, 5.7.5 beziehungsweise 5.8.2 liegt. Bei Lücke 2 gilt das ab 5.4.0.

Laut JTL: Consent-Statistik (Statistiken, Consent-Manager) nicht öffnen und das Recht STATS_CONSENT_VIEW vorübergehend entziehen, wenn es niemand braucht. Beides ersetzt das Update nicht. Für Lücke 1 nennt JTL keine Übergangsmaßnahme.

Dateien und Datenbank, vollständig und geprüft. Das Backup brauchst du auch für das spätere Löschen in der Datenbank.

Von 5.8.x auf 5.8.2, von 5.7.x auf 5.7.5, von 5.6.x auf 5.6.5. JTL empfiehlt, die Versionslinie nicht zu wechseln. Erst in der Testumgebung, dann live. Die offizielle Anleitung steht im JTL-Guide, unseren Ablauf haben wir im Leitfaden zum 5.7-Update beschrieben. Hast du ein eigenes Child-Template oder Plugins, teste die Anpassungen gegen die neue Version, zur Template-Kompatibilität liegen uns keine Angaben vor.

Nach dem Update im Backend kontrollieren, ob der Wartungsmodus so eingestellt ist, wie du ihn willst. Auffällig sind laut JTL Zugriffe mit dem Parameter safemode= auf /admin/logout von fremden IPs sowie unerklärliche Wartungsphasen. Nach dem Update hält JTL eine Kompromittierungsprüfung bei dieser Lücke nicht für nötig.

Nicht im Backend, sondern mit einer lesenden Abfrage in einer Datenbank-Konsole. JTL beschreibt die Abfrage im Sicherheitshinweis zur Consent-Statistik, wir bauen sie hier nicht nach. Auffällig sind HTML-Sonderzeichen und fremde Zeichenfolgen. Namen früherer Einwilligungen, etwa eines deinstallierten Plugins, sind unkritisch.

Nur mit frischer Datenbanksicherung und nur Namen, die du als verdächtig bewertet hast, nicht pauschal alle Treffer. Gibt es Hinweise auf eine Ausnutzung, empfiehlt JTL zusätzlich zu prüfen: die GET-Zugriffe auf /admin/stats/6, die Benutzerkonten, Gruppenrechte, Plugins, Templates und Einstellungen. Dann Admin-Passwörter ändern, Sitzungen beenden und den Support kontaktieren.