Magecart-Skimmer missbraucht Stripe und Google Tag Manager im Checkout

Stellen Sie sich vor, ein Krimineller steht direkt neben der Kasse Ihres Onlineshops und liest jede Kreditkartennummer mit, die Ihre Kunden eintippen – und niemand bemerkt ihn, weil er die Uniform eines vertrauenswürdigen Zahlungsdienstleisters trägt. Genau das passiert derzeit bei einer neuen Angriffswelle auf Magento- und Adobe-Commerce-Shops. Ein raffinierter Skimmer stiehlt vollständige Zahlungsdaten – und missbraucht dafür ausgerechnet Google Tag Manager und die Stripe-API, also zwei Dienste, denen praktisch jeder Onlineshop bedingungslos vertraut.

Das Perfide: Klassische Schutzmechanismen wie Firewalls, Netzwerkfilter oder Content Security Policies laufen komplett ins Leere. Für Shopbetreiber in Deutschland – immerhin dem zweitgrößten Magento-Markt weltweit – ist das ein ernstes Problem. Wir erklären, was passiert ist, wie der Angriff funktioniert, wie Sie prüfen, ob Sie betroffen sind, und was Sie jetzt konkret tun müssen.

Was ist passiert?

Sicherheitsforscher der Firma Sansec haben Anfang Juni 2026 einen neuartigen Magecart-Skimmer öffentlich dokumentiert. Magecart ist ein Sammelbegriff für Schadcode, der direkt im Browser der Kunden Zahlungsdaten auf Checkout-Seiten abgreift („Web-Skimming"). Diese neue Variante – von den Forschern „Stripe-Hosted Skimmer" genannt – hebt das Ganze auf ein neues Level.

Der Skimmer versteckt seinen Schadcode in einem gefälschten Stripe-Kundendatensatz und liefert ihn über einen kompromittierten Google-Tag-Manager-Container an die Checkout-Seite aus. Google Tag Manager (kurz GTM) ist ein weit verbreitetes Werkzeug, mit dem Marketing-Teams ohne Programmierkenntnisse Skripte wie Tracking- oder Analyse-Codes auf einer Website einbinden können. Genau diese Flexibilität wird hier gegen die Shops verwendet.

Erfasst werden nicht nur Kreditkartennummer, CVV-Prüfziffer und Ablaufdatum, sondern auch Name, Rechnungsadresse, E-Mail-Adresse und Telefonnummer – also ein kompletter Datensatz, der für Identitätsdiebstahl und Kreditkartenbetrug ausreicht. Die Kampagne läuft nachweislich mindestens seit dem 24. Dezember 2025, also über ein halbes Jahr, bevor sie überhaupt öffentlich bekannt wurde. Das zeigt, wie lautlos dieser Angriff arbeitet.

Der technische Hintergrund – verständlich erklärt

Der gesamte Angriff läuft im Browser des Kunden ab (man spricht von einem „clientseitigen" Angriff) und gliedert sich in drei Phasen.

1. Code-Auslieferung (Code Delivery)

Ein manipulierter Google-Tag-Manager-Container – beispielsweise mit der ID GTM-P6KZMF63 – wird auf der Checkout-Seite geladen. Dieser ruft über die Stripe-API (api.stripe.com) die Metadaten eines vom Angreifer kontrollierten Kundendatensatzes ab. In diesen Metadaten steckt – in kleine Stücke zerteilt – der eigentliche JavaScript-Schadcode. Dieser wird im Browser wieder zusammengesetzt und über den Befehl new Function() ausgeführt. Anders gesagt: Der Skimmer lädt seinen Code aus einem Ort, dem der Shop vertraut, statt von einer verdächtigen fremden Domain.

2. Datensammlung (Harvest)

Der ausgeführte Code klinkt sich in den Bezahl-Button ein. Sobald der Kunde auf „Kaufen" klickt, liest der Skimmer die Formulardaten aus: Kartennummer, CVV, Ablaufdatum, Name, Adresse. Sind alle Kartendaten vorhanden, verschlüsselt er den Datensatz mit einem sogenannten XOR-Schlüssel (eine einfache Verschlüsselungsmethode, z. B. EGAU3X9PAMJ8RYRNJSPV) und legt ihn kurzzeitig im lokalen Speicher des Browsers ab – dem localStorage unter dem Schlüssel cus_customer_id.

3. Datenabfluss (Exfiltration)

Eine separate Routine prüft regelmäßig diesen lokalen Speicher. Gefundene Daten werden in zwei Hälften geteilt und über einen POST-Request an api.stripe.com/v1/customers als neuer, gefälschter Kunde hochgeladen. Die gestohlenen Daten landen dabei in den Metadaten-Feldern customer_id und device_id. Anschließend wird der lokale Eintrag gelöscht, um Spuren zu verwischen. Eine Variante des Angriffs nutzt statt Stripe den Dienst Google Firestore für denselben Zweck.

Weil jede einzelne Kommunikation über Domains läuft, denen der Shop ohnehin vertraut, schlägt keine Firewall und keine CSP-Allowlist an. Das Sansec-Team fasst es so zusammen:

„Der Skimmer lädt niemals von einer Domain, die der Angreifer kontrolliert. Sowohl die Payload als auch die gestohlenen Karten fließen durch zwei Domains, denen jeder Shop bereits vertraut: Google Tag Manager und Stripe. [...] Stores erlauben diese Domain standardmäßig, sodass der Skimmer Content Security Policy-Regeln und Netzwerkfilter umgeht." – Sansec Forensics Team

Reflectiz bringt die eigentliche Erkenntnis auf den Punkt: Die falsche Frage lautet, wohin der Datenverkehr geht.

„Die Frage war nie ‚Wohin geht dieser Traffic?'. Eine vertrauenswürdige Domain besteht diesen Test immer. Die Frage, die dies tatsächlich aufdeckt, lautet: ‚Was macht dieses Skript gerade jetzt, unabhängig davon, wo es gehostet wird?'." – Reflectiz

Wer ist betroffen?

Betroffen sind grundsätzlich alle Magento- und Adobe-Commerce-Shops, die Google Tag Manager und Stripe einsetzen – unabhängig von der Version. Es handelt sich nicht um eine klassische Software-Lücke im Magento-Kern, für die es einen einfachen Patch gäbe, sondern um den Missbrauch legitimer Dienste.

Die Zahlen verdeutlichen die Reichweite: Im ersten Quartal 2026 gibt es weltweit rund 111.495 aktive Magento-Shops, davon über 7.100 in Deutschland – dem zweitgrößten Markt nach den USA. Magento hält global etwa 7–8 % Marktanteil, dominiert aber das Enterprise- und B2B-Segment. Sansec hat bis heute über 70.000 kompromittierte E-Commerce-Shops identifiziert, die Opfer von Web-Skimming-Angriffen wurden.

Wichtig: Auch kleinere Shops sind lukrative Ziele. Angreifer nutzen zunehmend automatisierte Werkzeuge, um serverseitige Schwachstellen – etwa CVE-2025-54236 („SessionReaper") – auszunutzen und darüber die manipulierten GTM-Tags einzuschleusen. Ein einmal kompromittierter Server ist häufig der erste Schritt zur Injektion des Skimmers.

So prüfen Sie, ob Sie betroffen sind

1. Container-IDs prüfen: Untersuchen Sie den Quellcode Ihrer Checkout-Seiten und Ihren Google Tag Manager auf verdächtige Container-IDs wie GTM-P6KZMF63, GTM-55976FLP, GTM-MSDHV3HG oder GTM-TV4CSHVN.
2. Nach Stripe Secret Keys suchen: Durchsuchen Sie das clientseitige JavaScript nach hartkodierten Stripe Secret Keys (beginnend mit sk_test_ oder sk_live_). Diese haben im Frontend nichts verloren.
3. localStorage kontrollieren: Prüfen Sie während eines Testkaufs den lokalen Browserspeicher auf verdächtige Schlüssel wie cus_customer_id oder _d_data_customer_.
4. Netzwerkverkehr analysieren: Achten Sie auf unerwartete POST-Requests an api.stripe.com/v1/customers oder firestore.googleapis.com, die nicht von Ihrem eigenen Backend ausgehen.
5. Malware-Scanner einsetzen: Nutzen Sie spezialisierte Scanner wie Sansec eComscan oder das kostenlose, offizielle Adobe Commerce Security Scan Tool, um Ihren Shop auf bekannte Skimmer-Signaturen zu prüfen.

Ein besonders klarer Warnhinweis kommt vom Sansec-Team:

„Keine legitime Integration liefert jemals einen Stripe Secret Key im clientseitigen JavaScript aus. Secret Keys gehören auf den Server. Einen in einem Browser-Skript zu finden, ist an sich schon ein Beweis für eine Kompromittierung." – Sansec Forensics Team

Das müssen Sie jetzt tun

1. Google Tag Manager auditieren: Sichten Sie alle Tags und Skripte in Ihrem GTM-Konto. Entfernen Sie sofort jeden Tag, der nicht autorisiert oder unbekannt ist.
2. Strikte Content Security Policy (CSP) umsetzen: Auch wenn eine CSP bei vertrauenswürdigen Domains an ihre Grenzen stößt, sollten Sie sie so streng wie möglich konfigurieren und die Ausführung von Inline-Skripten (unsafe-inline) einschränken.
3. PCI-DSS-Anforderungen erfüllen: Setzen Sie die Anforderungen 6.4.3 und 11.6.1 des PCI DSS v4.0.1 um. Führen Sie ein Inventar aller Skripte auf Zahlungsseiten und nutzen Sie Mechanismen zur Erkennung unautorisierter Änderungen, etwa Subresource Integrity (eine Technik, die prüft, ob ein Skript unverändert geladen wurde).
4. Clientseitige Schutzlösung einsetzen: Verwenden Sie Web-Skimming-Protection-Werkzeuge (z. B. Reflectiz oder Sansec Shield), die das Verhalten von Skripten in Echtzeit im Browser überwachen und blockieren, wenn diese unautorisiert auf Zahlungsfelder zugreifen.
5. Magento aktuell halten: Spielen Sie alle Sicherheitsupdates zeitnah ein. Adobe hat am 14. Juli 2026 das reguläre Sicherheitsupdate APSB26-73 für Adobe Commerce und Magento veröffentlicht. Solche Updates verhindern serverseitige Kompromittierungen (wie über die SessionReaper-Lücke CVE-2025-54236), die oft der erste Schritt zur Injektion der GTM-Tags sind.

Einordnung und DSGVO-Relevanz

Sollte Ihr Shop kompromittiert worden sein und wurden dabei Zahlungs- und Personendaten abgegriffen, liegt eine meldepflichtige Datenpanne vor. Nach Art. 33 DSGVO müssen Sie eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden an die zuständige Aufsichtsbehörde melden – es sei denn, es besteht voraussichtlich kein Risiko für die Betroffenen.

Da bei diesem Skimmer hochsensible Zahlungsdaten (Kreditkartennummer, CVV) zusammen mit Name, Adresse und E-Mail gestohlen werden, besteht ein hohes Risiko für Identitätsdiebstahl und finanziellen Betrug. Eine Meldung an die Behörde ist damit zwingend. Zusätzlich müssen Sie nach Art. 34 DSGVO auch die betroffenen Kunden unverzüglich benachrichtigen.

Bei Verstößen – insbesondere bei unzureichenden technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO zum Schutz der Zahlungsseiten – drohen Bußgelder von bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes. Wie teuer ein Magecart-Angriff werden kann, zeigt der Fall British Airways, bei dem das Bußgeld ursprünglich auf über 200 Millionen Euro angesetzt war.

Auch die reinen Folgekosten sind erheblich: Laut IBM Cost of a Data Breach Report 2024 belaufen sich die durchschnittlichen globalen Kosten einer Datenpanne auf 4,88 Millionen US-Dollar. Hinzu kommen Reputationsschäden, Haftungsansprüche der Zahlungsdienstleister und der drohende Verlust des PCI-DSS-Compliance-Status.

Fazit

Der Stripe-Hosted Skimmer markiert eine neue Qualität von Supply-Chain-Angriffen. Reflectiz formuliert es treffend:

„Dies ist Magecart, das sich über den Punkt hinaus entwickelt hat, an dem Allowlists helfen können. Anstatt eine verdächtige Domain zu kontaktieren, versteckt sich dieser Skimmer in zwei Diensten, die fast jeder E-Commerce-Shop als bedingungslos sicher behandelt: Stripe und Google Tag Manager." – Reflectiz

Die zentrale Lehre für Shopbetreiber: Es reicht nicht mehr, den Server abzusichern und vertrauenswürdige Domains freizugeben. Entscheidend ist, was ein Skript im Browser tatsächlich tut – unabhängig davon, wo es gehostet wird. Prüfen Sie noch heute Ihren Google Tag Manager und Ihre Checkout-Seiten, halten Sie Ihr Magento auf dem neuesten Stand und ziehen Sie eine clientseitige Schutzlösung in Betracht. Angesichts eines Angriffs, der über ein halbes Jahr lang unentdeckt lief, ist Wegschauen keine Option.