JTL-Shop: Sicherheitslücke im Retouren-Modul gibt Lieferadressen fremder Kunden preis

Auf einen Blick

• ✓JTL hat am 24. September 2026 das Advisory SHOP-9886 veröffentlicht: eine IDOR-Lücke (CWE-639, CVSS 3.1: 6.5, vom Advisory selbst als „Hoch“ eingestuft) im Retouren-Modul erlaubt registrierten Kunden, mit einem einfachen Hochzähl-Skript die Lieferadressen aller anderen Kunden auszulesen. Betroffen sind alle Versionen von 5.3.0 bis einschließlich 5.6.3, 5.7.3 und 5.8.0. Eine CVE-Nummer wurde nicht vergeben.
• ✓Der Fix steckt seit dem 24. September 2026 in den Versionen 5.6.4, 5.7.4 und 5.8.1. Für die Zweige 5.3.x bis 5.5.x gibt es keinen regulären Versionssprung mehr, sondern einen separaten manuellen Patch, weil diese Zweige laut JTL kein reguläres Sicherheitsupdate mehr erhalten. Die Vlarom E-Commerce Agentur spielt beide Wege ein, prüft anschließend, was in den Logs zu erkennen ist, und was nicht.
• ✓Das Deaktivieren der Retourenfunktion im Backend schützt nicht: Die Schnittstelle bleibt unabhängig davon erreichbar. Betroffen sind Vorname, Nachname, Adresse und, wenn im Shop aktiviert, weitere Kontaktdaten. Passwörter, Zahlungsdaten und Bestellhistorie sind nach Angaben von JTL nicht betroffen.

Wir bei Vlarom E-Commerce Agentur begleiten JTL-Shop-Updates für Händler deutschlandweit, als JTL Service Partner Gold aus Ahrensfelde bei Berlin. Bei einer Lücke wie SHOP-9886 sehen wir in der Praxis zwei typische Reaktionen: die Retourenfunktion vorsichtshalber abschalten, oder abwarten, weil im Access-Log nichts Auffälliges steht. Beides greift hier eben zu kurz, und genau deshalb ordnen wir unten ein, was die Backend-Einstellung tatsächlich tut und was ein leeres Logfile wirklich bedeutet, bevor wir zum Update kommen.

Die folgenden Angaben stammen aus dem JTL-Advisory zu SHOP-9886 sowie den drei zugehörigen Release-Beiträgen im JTL-Forum, alle veröffentlicht am 24.09.2026.

Die einzige Prüfung ist, ob der Datensatz existiert – nicht, wem er gehört.

Die wichtigsten Eckdaten zu SHOP-9886 im Überblick:

• →IDOR im Retouren-Modul, CVSS 6.5, als Hoch eingestuft: JTL klassifiziert SHOP-9886 als Broken Object Level Authorization / IDOR (CWE-639, OWASP API1:2023) mit CVSS-3.1-Vektor AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, Basiswert 6.5. Der Schweregrad im Advisory lautet ‚Hoch‘. In den drei Release-Beiträgen im JTL-Forum bezeichnet JTL denselben Fix zusätzlich als ‚kritischen Security Fix‘ — beide Formulierungen sind belegt, gemeint ist dieselbe Lücke. Eine CVE-Nummer wurde nicht vergeben.
• →Betroffen: 5.3.0 bis einschließlich 5.6.3, 5.7.3 und 5.8.0: Laut JTL sind alle Versionen ab 5.3.0 bis einschließlich 5.6.3, 5.7.3 und 5.8.0 betroffen. Versionen vor 5.3.0 sind nicht betroffen, weil die Retourenfunktion selbst erst mit Version 5.3.0 eingeführt wurde. Ein bereits im Juni oder August eingespielter Sicherheitspatch schützt vor SHOP-9886 nicht — das ist eine eigenständige Lücke.
• →Fix seit 24.09.2026 in 5.6.4, 5.7.4 und 5.8.1: JTL hat die drei Fixversionen am selben Tag veröffentlicht: 5.8.1 um 10:16 Uhr, 5.7.4 um 10:20 Uhr und 5.6.4 um 10:24 Uhr, jeweils im JTL-Releaseforum. Alle drei enthalten zusätzlich den Fix für eine reflektierte XSS-Lücke im Passwort-vergessen-Ablauf — eine eigene, dritte Schwachstelle, die nicht Teil von SHOP-9886 ist. 5.8.1 behebt außerdem separat einen Fehler beim Bestellabschluss (SHOP-9863).
• →5.3.x bis 5.5.x: manueller Patch statt Versionssprung: Für diese älteren Zweige erscheint laut JTL kein reguläres Sicherheitsupdate mehr. Stattdessen stellt JTL ein Patch-Archiv zum manuellen Einspielen bereit. Unabhängig vom Patch empfiehlt JTL selbst den Wechsel auf einen aktuell gepflegten Versionszweig, weil 5.3.x bis 5.5.x generell keine weiteren Sicherheitsupdates mehr erhalten.
• →Betroffene Daten: Adresse immer, Kontaktdaten teils: Immer auslesbar waren Vorname, Nachname, Straße, Hausnummer, PLZ, Ort, Land und, falls im Shop aktiv, der Titel. Zusätzlich betroffen, wenn im Shop aktiviert: Firma, Firmenzusatz, Adresszusatz, Bundesland, Telefon-, Mobil- und Faxnummer sowie E-Mail-Adresse. Nicht betroffen waren laut JTL Passwörter und Passwort-Hashes, Zahlungs- und Bankdaten, Bestellinhalte und -historie, Rechnungsadressen im Kundenstammsatz sowie Backend-Benutzerkonten. Der Zugriff war ausschließlich lesend, eine Veränderung oder Löschung war nicht möglich.

Die technische Ursache und warum das Abschalten der Retourenfunktion nicht hilft, ordnen wir im nächsten Abschnitt ein.

info

Fehlende Eigentümerprüfung an einer AJAX-Schnittstelle

Der Shop stellt unter dem Pfad /io (in 5.3.x: io.php) eine AJAX-Schnittstelle für das Frontend bereit. Die Methode rmaSummary erzeugt die Zusammenfassungsseite einer Retoure und prüft dabei korrekt CSRF-Token und Login. Den Parameter returnAddress nimmt sie laut JTL aber direkt aus der Anfrage entgegen und lädt den zugehörigen Datensatz allein anhand des Primärschlüssels aus der Tabelle tlieferadressevorlage.

Die einzige Prüfung war laut JTL, ob der Datensatz überhaupt existiert, nicht, wem er gehört. Die Adressen liegen in der Datenbank teilweise XTEA-verschlüsselt, werden auf dem regulären Ladeweg aber entschlüsselt ausgegeben, die Verschlüsselung bot hier deshalb keinen Schutz. Weil die Adress-IDs dichte, fortlaufende Ganzzahlen sind, ließ sich der gesamte Adressbestand zudem mit einem einfachen Hochzähl-Skript automatisiert durchlaufen.

critical

Retouren im Backend deaktivieren schützt nicht

Die Backend-Einstellung ‚Retouren aktivieren‘ (global_rma_enabled) steuert laut JTL ausschließlich die Anzeige im Frontend. Der betroffene Schnittstellen-Endpunkt bleibt auch bei deaktivierter Retourenfunktion vollständig erreichbar und angreifbar.

Auch Shops, die noch nie eine Retoure hatten, waren betroffen: Exponiert sind die regulär unter ‚Mein Konto > Lieferadressen‘ gespeicherten Adressen, unabhängig davon, ob der Retourenprozess je genutzt wurde.

warning

Für den Angriff genügte ein normaler Kundenaccount

Laut JTL waren für den Zugriff keine Administrationsrechte nötig, keine Bestellung und keine retournierbare Ware. Ein beliebiger regulärer Kundenaccount reichte aus.

Das unterscheidet SHOP-9886 von der im Juni geschlossenen Lücke CVE-2026-54390: Dort ging es um eine Server-Side-Template-Injection mit möglicher Remote Code Execution. SHOP-9886 ist eine eigenständige, andere Schwachstelle und wurde von JTL selbst über eine Sicherheitsüberprüfung gefunden, nicht wie CVE-2026-54390 im Zusammenhang mit einem bekannten Vorfall.

info

Was deine Logs zeigen können, und was nicht

Der Angriff läuft laut JTL als POST-Aufruf. Der Name der aufgerufenen Funktion und die durchgezählte Adress-ID stehen dabei im Nachrichtenrumpf der Anfrage. Reguläre Zugriffsprotokolle von Webservern zeichnen diesen Teil nicht auf. Ein Auslesen per POST ist damit nachträglich nicht nachweisbar und hinterlässt keine Spur in der Datenbank, da es sich um einen reinen Lesevorgang handelt.

Zwei Ausnahmen: Wurde der Aufruf per GET abgesetzt, findest du ihn mit einer Suche nach rmaSummary im Access-Log. Betreibst du eine Web Application Firewall mit Body-Logging, etwa das ModSecurity Audit-Log, ist eine Suche dort laut JTL die zuverlässigste Quelle, weil sie auch POST-Aufrufe eindeutig belegt. Wichtig: Ein fehlender Treffer ist keine Entwarnung, er bedeutet nur, dass die dafür nötigen Daten in deiner Infrastruktur gar nicht protokolliert werden, nicht, dass nichts passiert ist.

Der Ablauf folgt einem regulären JTL-Shop-Update, ergänzt um die Log-Prüfung und die Einordnung nach DSGVO, die bei dieser Lücke dazugehören. Allgemeine Sicherheitseinstellungen des Shops behandelt das Guide-Kapitel Sicherheit in JTL-Shop unabhängig davon.

Im Backend zeigt das Dashboard-Widget ‚Informationen zum Onlineshop‘ laut JTL-Guide, welche Version aktuell läuft. Betroffen sind Versionen von 5.3.0 bis einschließlich 5.6.3, 5.7.3 und 5.8.0. Läufst du auf 5.6.4, 5.7.4, 5.8.1 oder neuer, ist die Lücke bereits geschlossen.

Backup der Datenbank und aller Shop-Dateien, vor jedem Update ohne Ausnahme — eine Anleitung dazu steht im Guide-Kapitel Datenbank-Backups von JTL-Shop erstellen. Läufst du auf 5.6.x, 5.7.x oder 5.8.x, aktualisierst du danach über den Update-Assistenten im Backend auf 5.6.4, 5.7.4 beziehungsweise 5.8.1. Läufst du auf 5.3.x bis 5.5.x, gibt es kein reguläres Update mehr, sondern nur den von JTL bereitgestellten manuellen Patch. Weil diese Zweige generell keine weiteren Sicherheitsupdates mehr erhalten, ist das der richtige Zeitpunkt, auch über einen Wechsel auf einen aktuell gepflegten Zweig nachzudenken.

Durchsuche deine Zugriffsprotokolle nach GET-Aufrufen mit dem Funktionsnamen rmaSummary. Hast du eine WAF mit Body-Logging im Einsatz, etwa ein ModSecurity Audit-Log, ist eine Suche dort nach demselben Funktionsnamen der zuverlässigere Weg, weil sie auch POST-Aufrufe erfasst; findest du nichts, bedeutet das nicht automatisch, dass nichts passiert ist, da POST-Aufrufe an regulären Access-Logs vorbeilaufen. Mit der Abfrage SELECT COUNT(*) AS gespeicherte_lieferadressen, MAX(kLieferadresse) AS hoechste_id FROM tlieferadressevorlage; siehst du, wie viele Lieferadressen in deiner Datenbank stehen — diese Zahl hängt laut JTL nicht davon ab, ob in deinem Shop jemals eine Retoure angelegt wurde.

Personenbezogene Daten waren betroffen. Ob eine Meldepflicht nach Art. 33 DSGVO (an die Aufsichtsbehörde, bei Risiko, innerhalb von 72 Stunden) oder zusätzlich nach Art. 34 DSGVO (an die betroffenen Personen, nur bei voraussichtlich hohem Risiko) in deinem konkreten Fall greift, hängt vom Einzelfall ab. Das ist keine Rechtsberatung, sondern eine Einordnung der Norm. Kläre den konkreten Fall mit deinem Datenschutzbeauftragten oder deiner Rechtsberatung.

Retourenprozess testweise durchlaufen, Bestellung testen, Connector-Verbindung kontrollieren. Da es sich um einen reinen Sicherheitspatch handelt, ist mit sichtbaren Funktionsänderungen im Frontend nicht zu rechnen.