Wir haben bei einem Kunden einen Checkout gefunden, der aussah wie der echte, aber leise das Geld der eigenen Kunden an einen Fremden umgeleitet hat. Kein gestohlener Datensatz, kein gehackter Server im klassischen Sinn. Nur eine einzige eingeschleuste Zeile Code im Hintergrund, die den Rest nachlädt. Wir ordnen den Fall hier ein, zusammen mit der aktuellen JTL-Sicherheitslücke, die vermutlich der Türöffner war.
Wie der Fall aufgefallen ist
Angefangen hat alles mit zwei E-Mails am selben Tag, von zwei Kunden, die sich nicht kannten. Beide hatten unterschiedliche Zahlarten gewählt und kamen trotzdem nicht durch: ein Fenster verlangte eine SEPA-Echtzeitüberweisung (eine Überweisung, die in Sekunden statt Tagen beim Empfänger ankommt und sich danach kaum zurückholen lässt), sonst würde die Bestellung nicht reserviert. Zwei eigene Testbestellungen liefen dagegen fehlerfrei durch, kein Fenster, kein Fehler.
Genau das machte die Sache unheimlich. Das Ding ließ sich nicht auf Kommando reproduzieren, war aber real genug, um an einem Tag zwei unabhängige Beschwerden auszulösen. Erst die Häufung hat den Verdacht ausgelöst, genauer hinzuschauen, statt es als Einzelfall abzutun.
Was wir im Checkout gefunden haben
Der Checkout selbst sah auf den ersten Blick unauffällig aus: ein Zahlungsfenster, SEPA-Instant, mit Rabatt beworben, "Scannen & Zahlen", "Digitalbanken", "Bankdaten", ein Warnhinweis zur Echtzeitüberweisung, unten ein Chat-Button. Sieht aus wie ein professionelles Zahlungsmodul. Ist aber keins.
Im Entwicklerwerkzeug des Browsers zeigte sich, was am Bestätigen-Button tatsächlich hängt: ein Klick-Event, das über eine fremde Datei lief, brav mitgeloggt zwischen jQuery und dem eigenen Shop-Template. Der Angreifer musste den Server dafür nicht übernehmen, nur eine Zeile Code in die Seite bekommen, die der Browser des Kunden danach normal mitausführt. Schon im Warenkorb blendete das Skript die PayPal-Express-Buttons aus, offenbar um Kunden erst gar nicht die Möglichkeit zu geben, dort bequem vorbeizuzahlen. Am eigentlichen Bestellabschluss-Button hängte sich das Skript ein, unterbrach die reguläre Bestellung und öffnete stattdessen sein eigenes Zahlungsfenster.
Das Unbequeme daran: keine geänderte PHP-Datei, kein neues Skript im Webroot. Genau die Prüfung, die aktuell überall als erster Schritt empfohlen wird, lief bei diesem Shop ins Leere. Ob der Einfallsweg wirklich über die aktuelle JTL-Sicherheitslücke lief, ist wahrscheinlich, aber noch nicht zweifelsfrei bestätigt. Alle durchgeführten Prüfungen waren negativ, eine hundertprozentige Garantie, dass wirklich keine einzige Datei irgendwo verändert wurde, gibt es trotzdem nicht. Was die Analyse aber zeigt: der Kern des Angriffs saß in der Datenbank, ein einzelner bösartiger Eintrag lud unauffällig fremden JavaScript-Code nach, bei jedem Aufruf der Seite neu, ganz ohne dass irgendeine Datei dafür angefasst werden musste.
Was Man in the Cart eigentlich ist
Klassisches Kartenskimming kopiert die Kartendaten, während der Kunde sie eintippt. Man in the Cart macht etwas Kälteres: es hijackt den ganzen Zahlungsschritt. Die legitimen Zahlungsmethoden des Shops werden versteckt, ein Iframe (eine fremde Seite, unsichtbar in die eigene Seite eingebettet) legt sich darüber, sieht aus wie das eigene Zahlungsmodul, und fordert den Kunden auf, per SEPA-Überweisung oder QR-Scan an eine fremde Bankverbindung zu zahlen, für exakt den Betrag im Warenkorb.
Der Kunde ist überzeugt, an den Shop zu zahlen. Er zahlt an einen Fremden, das Geld ist weg, sobald die Überweisung durch ist. Keine Kartendaten fließen, weshalb jede kartenbasierte Betrugsprüfung schläft. Das ist der entscheidende Unterschied zu allem, was wir bisher unter Payment-Betrug kannten: nicht der Kunde wird beklaut, sondern der Moment des Bezahlens selbst wird gefälscht, während der Rest des Shops normal weiterläuft.
Ganz neu ist das Grundprinzip nicht. Checkout-Overlays wie dieser laufen in der Sicherheitsforschung seit Jahren unter dem Sammelbegriff Magecart, meist mit dem Ziel, Kartendaten abzugreifen. Die Umleitung auf eine gefälschte Banküberweisung statt auf ein Kartenformular, wie bei unserem Kunden, ist in der öffentlich zugänglichen Sicherheitsforschung deutlich seltener beschrieben als der klassische Karten-Overlay. Einen feststehenden Fachbegriff dafür gibt es nach unserer Recherche nicht. Den Namen Man in the Cart haben wir nicht selbst erfunden: Maurizio Fonte, ein italienischer IT-Sicherheitsberater, hat ihn geprägt, nachdem er bei einem völlig anderen, italienischen Shop dieselbe Angriffsart analysiert hatte. Bemerkenswert: unsere eigene forensische Analyse fand bei unserem Kunden eine Laufzeitbibliothek, die exakt so benannt ist wie in Fontes Fund, „StagerRuntime". Das ist kein generischer Name, den zwei Analysten zufällig gleich vergeben, das spricht dafür, dass hier dieselbe Angriffs-Infrastruktur am Werk ist, offenbar nicht auf einen Shop oder ein Land beschränkt. Wir übernehmen den Namen deshalb bewusst mit Verweis auf Fonte, nicht weil wir Anspruch auf den Begriff erheben, sondern weil unser eigener Fund seine Analyse bestätigt.
Bei unserem Kunden tauchte das Fenster mehrfach auf, mit unterschiedlichen Beträgen, jedes Mal exakt passend zur Bestellung, jedes Mal mit demselben Rabatt von 7 % für die "SEPA-Instant-Zahlung", der Druck aufbaut: schnell zahlen, sonst ist der Vorteil weg. Betroffen waren dabei mehrere unterschiedliche Zahlungsarten, nicht nur eine einzelne.
Neu ist vor allem die Machart. Die forensische Analyse bei unserem Kunden zeigt ein sauber strukturiertes, kommentiertes Skript, aufgeteilt in eine allgemeine Laufzeitbibliothek und einen Teil, der eigens auf diesen einen Shop zugeschnitten ist. Zahlungsarten erkennt es nicht über technische IDs, die sich leicht ändern, sondern über den sichtbaren Text auf der Seite, robuster gegen kleine Anpassungen im Shop. Bevor es überhaupt aktiv wird, fragt es einen externen Server nach dessen Status, Land und Betragsgrenzen ab, und schaltet sich nur bei passender Antwort scharf, eine Art Fernbedienung, mit der sich der Angriff zentral an- und ausschalten lässt. Dazu läuft im Hintergrund Telemetrie, jeder Schritt im Checkout wird an den Angreifer zurückgemeldet. Das ist keine Handarbeit mehr, sondern eine kleine, wiederverwendbare Angriffs-Infrastruktur.
Die JTL-Sicherheitslücke, kurz und ohne Umschweife
JTL hat zusammen mit dem Sansec Threat Research Team eine kritische Schwachstelle im JTL-Shop 5 geschlossen: CVE-2026-54390, CVSS 9,8. Der Fehler steckt im E-Mail-Template-System, in SmartyRenderer.php. Bei unserem Kunden lief der Angriff über ein einziges Feld im Kontaktformular: der eingetragene Nachname landete ungefiltert im Mail-Header der automatisch erzeugten Antwort-Mail, im Absendernamen. Genau dort, anders als im sichtbaren Mailtext, wertet JTL-Shop den Inhalt über die Smarty-Template-Engine aus. Ein präparierter Wert an dieser einen Stelle reichte, um Code statt Text ausführen zu lassen.
Bist du betroffen?
Betroffen sind die Versionen 5.2.0 bis 5.7.1, komplett unauthentifiziert. Bis 5.3.x lässt sich der Blowfish-Key und das Datenbankpasswort auslesen, dazu SMTP-, FTP-, Redis- und OAuth-Zugänge. Ab 5.4.0 kommt eine unauthentifizierte Remote Code Execution dazu, über die sich ganz ohne Login eine Webshell in den Webroot schreiben lässt. JTL hat Patches für alle aktiven Zweige bereitgestellt: 5.5.4, 5.6.2, 5.7.2. Wer im JTL-Hosting oder bei ecomDATA hostet, wurde automatisch abgesichert, wer selbst hostet, muss selbst patchen.
Wird die Lücke schon ausgenutzt?
Ja. JTL beobachtet inzwischen aktive Ausnutzung und hat Servicepartnern zusätzliche Erkennungshilfen an die Hand gegeben. Sinnvoll ist in jedem Fall, die eigenen Access-Logs seit dem 17.06.2026 auf gehäufte, ungewöhnliche Zugriffe zu prüfen. Veröffentlichte Lücken mit bekanntem Angriffsvektor werden erfahrungsgemäß innerhalb von Stunden bis Tagen von automatisierten Scannern aufgegriffen, unabhängig von der Größe deines Shops.
Nur: die Backdoor-Datei ist die eine Sache. Was danach damit gemacht wird, ist eine andere, und genau da schließt sich der Kreis zu unserem Kundenfall.
Zwei Irrtümer, die aktuell kursieren
"Es wurden keine neuen Dateien gefunden oder Dateien verändert, also ist alles in Ordnung." Genau das war bei unserem Kunden der Fall, und trotzdem lief im Checkout fremder Code. Ein sauberer Webroot ist kein Beweis dafür, dass nichts passiert ist. Die Datenbank kann fremden JavaScript-Code an jeden Kunden ausliefern, während kein einziges File verändert wurde.
"Wir konnten das Problem nicht nachstellen, also war es wohl ein Einzelfall." Zwei Testbestellungen liefen bei uns fehlerfrei durch. Trotzdem war das Fenster für zwei echte Kunden real genug, um Beschwerden auszulösen. Die forensische Analyse liefert die Erklärung nach: Das Skript fragt vor jedem Angriff erst einen externen Server ab, ob dessen Zahlungskonten verfügbar sind, das Land des Shops zugelassen ist und der Bestellwert innerhalb bestimmter Grenzen liegt, und schaltet sich nur bei passender Antwort scharf. Nicht reproduzierbar heißt also nicht harmlos, es kann bedeuten, dass der Angreifer den eigenen Angriff gezielt an- und ausschaltet.
Was jetzt zu tun ist, wenn du einen JTL-Shop selbst hostest
Patchen ist die Pflicht, keine Kür: 5.7.1 auf 5.7.2, 5.6.1 auf 5.6.2, 5.5.3 auf 5.5.4, ältere Versionen über den manuellen Patch aus dem JTL-Releaseforum. Vorher Backup, danach Testbestellung und Mailversand prüfen.
Darüber hinaus lohnen sich vier weitere Schritte:
- Access-Logs seit dem 17.06.2026 auf ungewöhnliche Zugriffsmuster prüfen, im Zweifel deinen JTL-Servicepartner nach zusätzlichen Prüfhilfen fragen.
- Den Checkout im Entwicklerwerkzeug des Browsers öffnen und prüfen, welche Skripte und Event-Listener am Bestell-Button hängen.
- Die Datenbank auf Inhalte prüfen, die roh, ohne Escaping, in die Seite gerendert werden, der Einfallspunkt für ein gespeichertes Skript ganz ohne Dateiänderung.
- Eine Content-Security-Policy setzen, eine Browser-Regel, die festlegt, welche fremden Adressen überhaupt ein Fenster wie das oben beschriebene öffnen dürfen (Parameter
frame-src), im Zweifel erstmal im Report-Only-Modus, der nur meldet statt sofort zu blockieren.
Zugangsdaten bei jedem Verdacht als kompromittiert behandeln: Datenbank, FTP, SMTP, Shop-Admin, alles rotieren.
Warum wir diesen Fall ernst nehmen
Aufgefallen ist der Fall nicht durch eine Firewall, sondern weil zwei Kunden sich unabhängig gemeldet haben, und weil jemand diese zwei E-Mails nebeneinander gelegt hat, statt jede für sich abzuhaken. Ein Argument dafür, wiederkehrende Checkout-Beschwerden nicht vorschnell auf Kundenfehler zu schieben, gerade wenn sich das Problem selbst nicht reproduzieren lässt.
Für uns ist Man in the Cart eine neue Angriffsart. Das Grundprinzip von Checkout-Overlays kennt die Sicherheitsforschung seit Jahren als Magecart, meist gegen Kartendaten. Die Umleitung auf eine gefälschte Echtzeitüberweisung, wie bei unserem Kunden, kennen weder wir noch jemand in unserem Umfeld aus einem anderen Fall. Ernst nehmen sollten Shopbetreiber den Fall trotzdem sofort, denn er setzt nicht am Server an, sondern an der Vertrauensbeziehung zwischen Shop und Kunde im Moment der Zahlung. Ein sauberes Dateisystem ist deshalb keine Entwarnung, der Checkout selbst muss geprüft werden, nicht nur der Server dahinter.
Wenn du einen JTL-Shop betreibst und nicht sicher bist, ob deiner sauber ist, oder wenn dir Kunden zuletzt von ähnlichen Zahlungsproblemen berichtet haben: melde dich bei uns. Wir schauen uns Checkout, Datenbank und Logs gemeinsam mit dir an und sagen dir ehrlich, wo du stehst.
