XSS-Patch für JTL-Shop 5.6.3 und 5.7.3: Was das Hochsetzen der Versionsnummer nicht behebt

Am 26. August hat JTL einen Sicherheitspatch für den Shop veröffentlicht. Es geht um Cross-Site-Scripting im Adminbereich: Bestimmte Eingaben wurden nicht ausreichend maskiert, sodass sich JavaScript einschleusen und im Backend ausführen ließ. JTL stuft die Kritikalität als hoch ein und schreibt zugleich, dass keine aktive Ausnutzung bekannt ist.

Die Eckdaten:

Betroffen	JTL-Shop 5.0.0 bis 5.6.2 und 5.7.2
Behoben in	5.6.3, 5.7.3 und alles ab 5.8.0
Ohne Support	alles vor 5.6.0 — dort gibt es keinen Patch mehr

Wenn Sie einen Shop in diesem Bereich betreiben: aktualisieren. Der Rest dieses Beitrags handelt davon, was rund um diesen Vorgang erfahrungsgemäß schiefgeht.

Warum „nur im Adminbereich” die Sache nicht harmloser macht

Der Satz „die Lücke betrifft nur das Backend” liest sich beruhigend. Er bedeutet aber etwas anderes, als er zu bedeuten scheint.

Eine XSS-Lücke im Adminbereich braucht einen angemeldeten Administrator, der eine präparierte Eingabe angezeigt bekommt. Und das ist im Shopalltag keine exotische Konstellation: Backend-Masken zeigen ständig Daten an, die von außen kommen. Kundennamen, Adressen, Bestellanmerkungen, Suchbegriffe, Formularinhalte — alles Text, den jemand anderes geschrieben hat und den ein Mitarbeiter im Backend zu Gesicht bekommt.

Läuft dort fremdes JavaScript, läuft es mit den Rechten der Person, die gerade angemeldet ist. Nicht als anonymer Besucher, sondern als der Administrator, der im Backend alles darf. Der Angreifer muss den Shop also nicht selbst übernehmen — er lässt ihn von jemandem übernehmen, der die Berechtigung ohnehin hat.

Die richtige Reaktion ist deshalb nicht nur „Patch einspielen”, sondern auch: nachsehen, wer eigentlich Zugang zum Backend hat.

Der Stolperstein beim Einspielen

Als der Patch von 5.7.2 auf 5.7.3 herauskam, funktionierte er zunächst nicht. Die ausgelieferten Pakete enthielten die falschen Dateien — der Shop blieb nach dem Einspielen schlicht auf 5.7.2 stehen. JTL hat die Pakete kurz darauf korrigiert und erneut veröffentlicht.

Für alle, die den Patch in diesem Zeitfenster gezogen haben, heißt das: nachsehen, ob der Shop wirklich auf der neuen Version steht — und sich nicht darauf verlassen, dass der Vorgang durchgelaufen ist, nur weil er nicht abgebrochen hat.

Im Forum kursierte in diesen Stunden ein Ratschlag, der schnell hilft und langfristig schadet: in der defines_inc.php die Konstante APPLICATION_VERSION von 5.7.2 auf 5.7.3 setzen. Damit steht die richtige Zahl im Backend. Gepatcht ist dadurch gar nichts.

Das ist keine Kleinigkeit. Ein Shop, der sich als gepatcht ausgibt, es aber nicht ist, fällt bei keiner Prüfung mehr auf — weder bei der eigenen noch bei der eines externen Scans. Und beim nächsten regulären Update passt der Dateistand nicht zur gemeldeten Version, was Folgefehler erzeugt, deren Ursache dann niemand mehr findet.

Wenn der Patch nicht durchläuft, ist der saubere Weg das vollständige Paket der Zielversion statt der Patch-Datei — nicht die Kosmetik an der Versionskonstante.

Der Ablauf, der trägt

1. Version feststellen. Backend oder defines_inc.php. Und zwar den tatsächlichen Stand, nicht den erinnerten.

2. Sicherung anlegen. Shop-Dateien und Shop-Datenbank. Nicht der Snapshot der virtuellen Maschine allein — der hilft, wenn die Maschine kaputt ist, nicht wenn in drei Tagen auffällt, dass etwas fehlt. Wie man prüft, ob eine Sicherung wirklich zurückspielbar ist, steht im Beitrag zum Restore-Test.

3. Zielversion wählen. Auf 5.6.x bleiben und 5.6.3 nehmen, wenn nur gepatcht werden soll; auf 5.7.x entsprechend 5.7.3. Der Sprung auf 5.8.0 ist ein Funktionsupdate und gehört nicht in denselben Termin wie ein Sicherheitspatch — das sind zwei Vorgänge mit zwei verschiedenen Risiken.

4. Einspielen. Danach die Version erneut prüfen. Wirklich erneut.

5. Sichtprüfung. Startseite, Kategorie, Artikeldetail, Warenkorb, Kasse. In dieser Reihenfolge, weil der Schaden nach hinten hin teurer wird. Bei einem eigenen Template gehört ein Blick auf die Stellen dazu, an denen dieses Template arbeitet — dazu mehr im Beitrag zur Update-Reihenfolge bei JTL.

6. Zugänge aufräumen. Siehe nächster Abschnitt.

Nach dem Patch: die Konten

Ein Patch schließt eine Tür. Er sagt nichts darüber, ob vorher jemand hindurchgegangen ist. Bei einer Backend-Lücke ist der naheliegende Schaden ein zusätzliches Konto oder eine stillschweigend erweiterte Berechtigung — beides unauffällig, beides dauerhaft.

Deshalb gehören nach dem Einspielen drei Dinge auf die Liste:

• Benutzerliste im Backend durchgehen. Jeder Eintrag muss einer realen Person zuzuordnen sein. Ehemalige Mitarbeiter, alte Dienstleisterzugänge, Testkonten aus der Einrichtungsphase — das ist der übliche Fund, ganz ohne Angriff.
• Passwörter der aktiven Backend-Konten wechseln. Echte, unterschiedliche, und nicht das alte mit einer neuen Ziffer am Ende.
• Backend zusätzlich absichern. IP-Freigabe, wenn die Zugriffe aus festen Netzen kommen; sonst wenigstens ein zweiter Faktor. Der Adminbereich ist die einzige Stelle im Shop, die niemand außer einer Handvoll Menschen überhaupt sehen muss.

Wie eine gründliche Aufräumaktion nach einem echten Vorfall aussieht — und woran man erkennt, dass wirklich alles weg ist — steht im Beitrag zum Aufräumen nach CVE-2026-54390.

Wer noch auf 5.5 oder älter läuft

Für Versionen vor 5.6.0 gibt es keinen Patch. Das ist keine Nachlässigkeit von JTL, sondern das Ende eines Lebenszyklus — und es bedeutet, dass jede künftige Lücke in diesen Ständen offen bleibt.

Ein Shop auf 5.4 oder 5.5 ist damit kein „läuft doch” mehr, sondern eine Aufgabe mit Termin. Der Sprung auf eine gepflegte Version kostet Aufwand, meist wegen des Templates und der Plugins. Dieser Aufwand wird nicht kleiner, wenn man wartet — nur die Zahl der offenen Lücken wächst.

Kurz

Der Patch selbst ist eine Sache von Minuten. Was ihn zum echten Vorgang macht, ist das Drumherum: prüfen, ob er wirklich angekommen ist, die Versionsnummer nicht von Hand zurechtbiegen und danach einmal ernsthaft auf die Liste der Backend-Konten schauen.

Wenn Sie unsicher sind, auf welchem Stand Ihr Shop läuft oder wer dort noch Zugang hat: Das ist eine Frage von zehn Minuten, und ich sehe sie mir gern an.