Im facebook-Forum gibt die Meldung von einem Nutzer über Skimming-Code-Angriffe augrund der Gambio Sicherheitsluecke Maerz 2026. Da nicht alle dort im Forum angemeldet sind für alle hier im Forum der Post: Wichtig: Dieser Fall als Folge der Gambio Sicherheitslücke vom März 2026 hat sich inzwischen als existenzbedrohende Krise für mich ausgeweitet: PRÜFT EURE SHOPS AUF DIESEN SKIMMING CODE: https://googtagmanager[.]com/GT-K5L8GCJW.js Achtung: Die Domain heißt googtagmanager (ohne „le") – also NICHT das echte googletagmanager.com. Nach dem Gambio-Hack war auf unserem Shop ein versteckter Skimmer aktiv, der beim Bezahlen Kartendaten abgreift. Aufgefallen ist er erst Monate später – über die Kartennetzwerke, die dann PayPal veranlasst haben, unser Konto zu sperren. Der genaue Schadcode war ein als Google Tag Manager getarntes Skript: Das ist die Fälschung. Bei uns war er nachweislich vom 4.–24. Juni aktiv. Prüft eure Shops (Seiten- und Checkout-Quelltext) auf Skripte, die von googtagmanager[.]com oder von unbekannten/euch nicht zuordenbaren Domains geladen werden – gerade wenn ihr von der Gambio-Lücke betroffen wart. So etwas kann monatelang unbemerkt laufen. Vielleicht war es mein Fehler aber im Glauben, alles richtig machen zu müssen, habe ich den Vorfall ausführlich an die Datenschutzbehörde gemeldet und außerdem eine Info Mail an alle Kundinnen und Kunden geschickt. Nun - ein halbes Jahr später hat die Firma MasterCard unseren Shop als Skimming Fall eingestuft und dies an PayPal gemeldet, was zur Folge hatte, dass PayPal mein Geschäftskonto gesperrt hat. Ich kommuniziere jetzt seit Wochen ausschließlich mit dem amerikanischen PayPal Service, da der deutsche Kundenservice keine derart weitreichenden Befugnisse hat. Ich musste einen unfassbar komplizierten Marathon an Sicherheitsdokumentationen, Fragebögen und extern laufenden Scans (auf eigene Kosten) und alles auf Englisch vorlegen, um mein Konto vorläufig wieder entsperren zu lassen. Doch obwohl ich inzwischen glücklicherweise bei Shopify bin (sonst wäre PayPal niemals wieder freigegeben worden) bleibt MasterCard hart und will uns in ein beinah 1000 Euro teures Monitoring Programm drängen, dass unseren Shop für die nächste Zeit überwacht und dokumentiert, dass wir keine Zahlungsdaten auf unsicheren Wegen verarbeiten. Das ganze hat inzwischen den Touch einer Gerichtsverhandlung, bei der ich als kleiner Shopbetreiber chancenlos bin. Ich zahle nun seit Wochen für Dokumentationen und stecke Stunden meiner Zeit da rein und trotzdem ist mein PayPal Konto nach wie vor nur vorläufig freigegeben mit einer ständigen 10 Tage Frist, die dann sporadisch wieder verlängert wird. Warum uns das getroffen hat, kann ich nicht sagen, aber die Ursache liegt zu 100% an der Sicherheitslücke, so wurde es mir mehrfach von PayPal und MasterCard bestätigt. Ich möchte, dass ihr euch der Gefahr bewusst seit, dass große Zahlungsanbieter bei diesen Themen 0% Toleranz zeigen und euch im Zweifelsfall PayPal für immer sperren. Das müsst ihr mit einpreisen, wenn ihr euch auf die Gambio Software verlasst.
Hallo zusammen, ich habe meinen Shop von codex auf Skimming-Code prüfen lassen Bei mir anscheinend keinen Hinweis auf https://googtagmanager[.]com/GT-K5L8GCJW.js Ist vielleicht für alle interessant, was geprüft wurde und was codex darüber hinaus angemerkt hat: Skimming-Code - Prüfung von codex: ich habe den Shop heute gezielt auf den aktuell diskutierten Skimming-Code im Zusammenhang mit der Gambio-Sicherheitsluecke vom Maerz 2026 geprueft. Konkret ging es um diesen als Google Tag Manager getarnten Schadcode: https://googtagmanager[.]com/GT-K5L8GCJW.js Wichtig: Das ist nicht die echte Google-Domain googletagmanager.com, sondern die Faelschung googtagmanager.com ohne "le". Ergebnis vorweg: Ich habe aktuell keinen Hinweis gefunden, dass dieser Skimmer im Shop aktiv ist oder in den geprueften Dateien/Datenbankinhalten vorhanden ist. Was ich geprueft habe: - Live-Shop von aussen: Startseite, Login, Gastkonto/Registrierung, Checkout-Seiten - Crawl von 80 oeffentlich erreichbaren Shop-Seiten - Die vom Shop ausgelieferten JavaScript-Dateien - Server-Dateien unter /var/www/html/www.dein-shop.de - Datenbank-Textfelder, in denen Script-/HTML-Inhalte liegen koennten - Webserver-Logs auf die genannten Indikatoren - Datei-Aenderungen im relevanten Juni-Zeitfenster Gefundene technische Ergebnisse: - googtagmanager: 0 Treffer - GT-K5L8GCJW.js: 0 Treffer - magecart / skimmer: 0 Treffer - Server-Dateiscan: 56.809 Dateien gesehen, 36.948 Textdateien geprueft, 0 Treffer auf die Skimming-Indikatoren - Datenbank: 0 Treffer auf die konkreten Skimming-Indikatoren - Webserver-Logs: 0 Treffer auf die konkreten Skimming-Indikatoren Ich habe auch den Zeitraum 01.06.2026 bis 25.06.2026 geprueft, weil in dem Hinweis ein aktiver Zeitraum im Juni genannt wurde. In diesem Zeitraum wurden im Shop 31 ausfuehrbare/template-artige Dateien geaendert. Diese gehoerten nach Pfad und Namen alle zum Gambio-Modul "OrderWithdrawalButton" und sehen nach einem normalen Gambio-/Modulbestandteil aus, nicht nach einem versteckten Checkout-Skimmer. Was ich ausserdem gesehen habe: - Die echte Domain www.googletagmanager.com kommt in alten Gambio-/Analytics-Dateien vor. Das ist nicht der gemeldete Schadcode. - In der Datenbank gibt es einige alte externe Script-/Widget-Domains, z.B. translate.google.com, paypal.com, youtube.com, revolvermaps/seitzeichen und aehnliche historische Inhalte. Das ist kein Treffer auf den Skimmer, aber ich wuerde bei Gelegenheit alte Drittanbieter-Widgets entfernen, wenn sie nicht mehr bewusst benoetigt werden. - Beim SSH-Zugriff ist aufgefallen, dass sich der gespeicherte SSH-Host-Key gegenueber dem bisher lokal bekannten Eintrag geaendert hat. Der aktuell vom Server gemeldete Fingerprint ist: SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Das kann nach Serverumzug/Neuinstallation normal sein, sollte aber der Vollstaendigkeit halber mit dem Hoster bestaetigt werden. Wichtig zur Einordnung: Die Pruefung ist eine gezielte Indikatorensuche auf den genannten Schadcode und typische Skimmer-Begriffe. Sie ist keine vollstaendige forensische Untersuchung mit Dateivergleich gegen ein sauberes Originalpaket, aber sie deckt die wichtigsten Stellen ab: Live-Ausgabe, Server-Dateien, Datenbankinhalte, Logs und relevante Aenderungszeitraeume. Ich habe auf dem Server keine dauerhaften Aenderungen gemacht. Fuer die Pruefung wurden nur temporaere Scan-Skripte nach /tmp hochgeladen, ausgefuehrt und danach wieder entfernt. Meine Empfehlung: - Aktuell sehe ich keinen Hinweis auf den konkret genannten Skimmer im Shop. - Trotzdem sollten wir den Shop weiter aktuell halten und die Gambio-Sicherheitsupdates im Blick behalten. - Alte externe Widgets/Scripte, die nicht mehr bewusst benoetigt werden, wuerde ich bei Gelegenheit bereinigen. - Den SSH-Host-Key-Wechsel sollten wir beim Hoster kurz bestaetigen lassen. Viele Gruesse Codex
Gibt auch von Rico schon ein Test-Script dazu https://www.orange-raven.de/kreditk...sperrt-der-betreiber-erfaehrt-es-als-letzter/
@michel aus löneberga War dein Shop im März betroffen? Es wäre sehr interessant, ob dies in allen betroffenen Shops zu finden ist.
Das würde mich auch interessieren. Ist es denn bei Cloudshops auch möglich? Also eigentlich wahrscheinlich ja, aber das wissen wir ja nicht wirklich.
Nö. Das Risiko musst du nur einpreisen wenn du Paypal oder andere amerikanische Zahlungsabwickler nutzt. Ich wüsste nicht wie ich mein Geschäftskonto der Deutschen Bank gesperrt bekommen sollte durch egal welchen Angriff auf den Shop. Im schlimmsten Fall würde jemand das hinterlegte Bankkonto ändern und die Zahlungen woanders hin umleiten. Das wäre komplett mein Problem, meiner Bank wäre das extrem egal.
Nur in aller Kürze. Es ist nicht bewiesen, dass das irgendwas mit den Attacken aus März zu tun hat. Es gibt dutzende Wege solchen Code in Shops zu bekommen. Natürlich ist ein Angriff und damit Zugang zu Shopdateien eine Möglichkeit. Es können aber ebenso geleakte Daten für den Admin Account sein. Ebenso SSH oder FTP Zugangsdaten oder ein Zugang über Fremdplugins. Ich kenne den betroffenen Shop (bzw. kannte) gut. In diesem Shop war sehr viel erweitert und gecoded wurden. Da war auch Code drin von Anbietern, die zumindest bedenklich waren und wo der ursprüngliche Anbieter irgendwann seinen Dienst eingestellt hatte. Das Problem mit solchen Codes ist schlicht, dass man sie nicht bemerkt. Und das kann einem in jedem System passieren. Steht dein Konto in Verdacht für illegale Aktivitäten verwendet zu werden, wird es dir die Bank auch erstmal sperren. Je nach Bank hast du dann auch Rennerei. Das gleiche wie oben kann einem auch mit Klarna oder anderen Anbietern passieren. Hier war schlicht das Pech, dass die Kreditkartenabwicklung scheinbar über PayPal passiert ist. Deswegen der Zusammenhang. Mit einem Onlineshop ist es nicht anders als mit einem Laden. Auch da musste man dafür sorgen, dass in der Ecke kein Crack Dealer steht und die Kunden abzieht oder jemand die Kreditkarte vom Kunden entwendet. Beim Shop halt etwas schwieriger zu finden, weil es Technik ist und man nicht im Laden steht. Gambio da jetzt pauschal verantwortlich zu machen ist Quatsch. Auch bei euch Shopbetreibern, verständlichermaßen, die Antennen dafür extra sensibel sind nach den letzten malen.
Wenn sich bei mehreren der damals gehackten Shops jetzt genau dieser Skimmer findet, wäre der Zusammenhang doch ziemlich schnell naheliegend (oder auch nicht). Genau das lässt sich durch eine Prüfung der betroffenen Shops klären. Nur: Sind die damaligen Betroffenen überhaupt noch hier im Forum...?
Sag mir mal ein Szenario bei dem durch einen Angriff auf meinen Shop mein Bankkonto in den Verdacht geraten soll für illegale Aktivitäten verwendet zu werden. Das ist doch gerade was ich gesagt habe, das ist unmöglich. Wenn jemand meinen Shop hackt und den SEPA QR-Code so verändert, dass die Zahlungen nicht auf meinem Konto bei der Deutschen Bank landen sondern auf einem N26 Konto von einem Money Mule merke ich das erstens innerhalb von wenigen Stunden, weil ich ja keine Zahlungen mehr erhalte. Und zweitens wo werden sich die Kunden dann Beschweren? Bei der Deutschen Bank? Woher sollen die Leute überhaupt wissen, dass unser Konto da war? Wie soll die Deutsche Bank irgendwie überhaupt Teil des ganzen Prozesses werden? Unser Konto wird dann nicht für illegale Aktivitäten verwendet, es wird dann gar nicht mehr verwendet. Ich bleibe dabei, es ist ein Risiko was allein bei Zahlungsabwicklern wie Paypal und Kreditkarten auftaucht. Das muss man schon klar so bennenen.
Das Risiko bei PayPal und Klarna ist real. Aber es ist nicht unmöglich, dass dir etwas vergleichbares mit deinem Konto passiert. Deine Fehlannahme hier ist, dass du der Meinung ist, dass deinem Konto Geld zu- oder abgeführt wird. Was übrigens auch im obrigen Fall nicht das Problem war. Das PayPal Konto wurde nicht gesperrt, weil da Geld in eine andere Richtung geleitet wurde, sondern weil über die Zahlungsabwicklung mit diesem Konto Kreditkartendaten abgegriffen wurden. Geschädigt wurde nicht der Gambio Shop betreiber direkt finanziell, sondern die Kunden die darüber mit Kreditkarte bezahlt haben....indem dann ihre Kreditkarte an anderer Stelle verwendet wird. Erstens kann dir das auch mit Zahlungsdaten bei SEPA Lastschrift passieren. Genau in dem Moment wo der Kunde seine Daten eingibt. Du bekommst dein Geld, merkst nichts davon und der Kunde ist geschädigt. Aber gut, das war ja nicht dein Argument. Es wird dann problematisch, wenn dein Konto als Money-Mule-Konto genutzt wird. Kunde hat Zugriff auf deinen Shop und hat Zahlungsdaten von Opfern. Er legt Bestellungen an, die dann z.B: per SEPA vom Opfer bezahlt werden. Versendet wird natürlich an den Betrüger. Wenn es dann Beschwerden von geprellten Kunden gibt, wird das Geld zurückgebucht. Du hast versendet und das Geld ist wieder weg. Wenn sich jetzt die Beschwerden der Kunden häufen, treten Complience Richtlinien in Kraft. Gibt es zahlreiche Abbuchungen ohne Bestellung von dir, wird die Bank dein Konto erstmal sperren. Die fragen dann nicht nach. Dein Konto ist dicht. Einziger Unterschied hier: Es ist wahrscheinlich deutlich einfacher das Konto zu entsperren. Damit das Problem natürlich geringer. Unmöglich ist es nicht.
Vielen Dank an Orange Raven. wie ist Suche Punkt 2 zu verstehen? "Script-/Config-Dateien in images/media/export/tmp – dort gehören sie normalerweise nicht hin, bitte prüfen:" all diese gelisteten php Dateien sind im OrginalGambio so drin. 2. Suche nach dem Schadcode in allen Shop-Dateien Gesucht wird die Domain googtagmanager (ohne "le") in Klartext und in allen gängigen Verschleierungen sowie Tag-IDs als Dateiname. Jeder Treffer hier ist ernst. 25608 Dateien im Scan-Baum, 72 Script-/Config-Dateien in übersprungenen Verzeichnissen (werden separat geprüft). grep-Durchlauf: 28 Rohtreffer. Script-/Config-Dateien in images/media/export/tmp – dort gehören sie normalerweise nicht hin, bitte prüfen: 2025-10-29 14:39 2216 images/config.php 2025-10-29 14:39 1104 images/manufacturers/config.php 2026-08-12 12:00 4883 images/placeholder.php 2021-01-29 13:50 1408 media/content/protected_shops_impressum.php 2021-01-29 13:50 1412 media/content/protected_shops_datenschutz.php 2021-01-29 13:50 797 media/content/janolaw_widerrufsformular.php 2021-10-19 15:38 2724 media/content/config.php 2026-08-12 11:51 3227 media/content/gm_callback_service.php 2021-01-29 13:50 96 media/content/itrk_impressum.php 2023-03-22 23:30 1297 media/content/sitemap.php 2021-01-29 13:50 1426 media/content/protected_shops_handlungsanleitung.php 2021-01-29 13:50 5440 media/content/trustedshops.php 2021-01-29 13:50 90 media/content/itrk_agb.php 2021-01-29 13:50 95 media/content/itrk_widerruf.php 2021-01-29 13:50 773 media/content/janolaw_agb.php 2021-01-29 13:50 1406 media/content/protected_shops_widerruf.php 2021-01-29 13:50 788 media/content/janolaw_impressum.php 2021-01-29 13:50 786 media/content/janolaw_widerruf.php 2021-01-29 13:50 1408 media/content/protected_shops_rueckgabe.php 2021-01-29 13:50 98 media/content/itrk_datenschutz.php 2021-01-29 13:50 1420 media/content/protected_shops_batteriegesetz.php 2021-01-29 13:50 1414 media/content/protected_shops_versandinfo.php 2021-01-29 13:50 788 media/content/janolaw_datenschutz.php 2021-01-29 13:50 1396 media/content/protected_shops_agb.php 2021-10-19 15:38 1734 media/config.php 2021-10-19 15:38 1712 media/products/config.php 2021-01-29 13:49 180 logfiles/.htaccess 2021-01-29 13:49 167 export/invoice/.htaccess 2021-01-29 13:49 167 export/sepa/.htaccess 2021-10-19 15:38 1691 export/config.php 2021-01-29 13:49 167 export/inventory/.htaccess 2021-01-29 13:49 167 export/packingslip/.htaccess Kein Schadcode in Dateien gefunden. Und Punkt 6. Auch diese Htaccess sind Orginal Gamio. Funde von einem Techniker prüfen lassen. 6. Versteckte Einträge in Server-Konfigurationsdateien Prüft .htaccess / .user.ini / php.ini auf Einträge, mit denen Angreifer sich dauerhaft festsetzen (z. B. auto_prepend_file). Funde von einem Techniker prüfen lassen. .htaccess mtime 2026-08-12 12:25 …edirects ## Example for category #RewriteCond %{REQUEST_URI} old-category #RewriteRule ^(.*)$ https://www.shop.com/new-category [L,R=301] ## Example for product #RewriteCond %{REQ… .htaccess mtime 2026-08-12 12:25 …xample for product #RewriteCond %{REQUEST_URI} old-category/old-product.html #RewriteRule ^(.*)$ https://www.shop.com/new-category/new-product-html [L,R=301] ## If you need GET parame… .htaccess mtime 2026-08-12 12:25 …this is a bad idea #RewriteCond %{REQUEST_URI} old-category/old-product.html #RewriteRule ^(.*)$ https://www.shop.com/new-category/new-product-html [QSA,L,R=301] # ------------------… gm/seo_boost_an/.htaccess mtime 2025-10-29 14:39 …edirects ## Example for category #RewriteCond %{REQUEST_URI} old-category #RewriteRule ^(.*)$ https://www.shop.com/new-category [L,R=301] ## Example for product #RewriteCond %{REQ… gm/seo_boost_an/.htaccess mtime 2025-10-29 14:39 …xample for product #RewriteCond %{REQUEST_URI} old-category/old-product.html #RewriteRule ^(.*)$ https://www.shop.com/new-category/new-product-html [L,R=301] ## If you need GET parame… gm/seo_boost_an/.htaccess mtime 2025-10-29 14:39 …this is a bad idea #RewriteCond %{REQUEST_URI} old-category/old-product.html #RewriteRule ^(.*)$ https://www.shop.com/new-category/new-product-html [QSA,L,R=301] # ------------------… 26 Config-Dateien geprüft. 6 Stellen mit Persistenz-Mustern – gegen bekannte, legitime Einträge abgleichen (Gambio-Root-.htaccess enthält normalerweise KEIN auto_prepend_file). sonst keine Auffälligkeiten selfhostet, Version 26.07.0 Danke Grüße Klaus
Danke für die Rückmeldung. Habe das skript nicht auf alle Versionen getestet und vieles auch erstmal breit angelegt. Werde die Rückmeldungen einarbeiten sobald Zeit ist um das Skript zu verbessern. Solange nix rot ist, ist erstmal nix bedenklich.
Habe es auch laufen lassen. Alles okay soweit. Nur Google meldet das Programm als rot solange Google mitm Shop verbunden ist.
Danke für die Rückmeldung. Du hast komplett recht. Habe die Ordner entsprechend hinzugefügt, sodass die nicht merh als bedenklich gemeldet werden.