Magecart 2026: Checkout-Skimming erkennen und abwehren

Der Checkout ist die sensibelste Seite eines jeden Online-Shops: Genau hier geben Kundinnen und Kunden ihre Kartennummer, Adresse und Zahlungsdaten ein - und genau hier setzen Magecart-Gruppen an. Beim sogenannten Web-Skimming schleusen Angreifer wenige Zeilen JavaScript in die Zahlungsseite ein, die jede Eingabe unbemerkt mitlesen und an eine fremde Domain ausleiten. Die Zahl der Angriffe steigt: Sicherheitsforscher erfassen inzwischen rund 30 neue Skimmer-Signaturen pro Tag (Sansec). Dieser Beitrag zeigt, wie ein Skimmer in den Checkout gelangt, woran Sie eine Kompromittierung erkennen und wie Sie die Integrität Ihrer Zahlungsseite mit Skript-Inventar, Content-Security-Policy und Subresource Integrity dauerhaft absichern.

Was Magecart und Web-Skimming genau sind

Magecart ist kein einzelnes Werkzeug, sondern ein Sammelbegriff für zahlreiche kriminelle Gruppen, die seit rund einem Jahrzehnt Zahlungsdaten direkt aus dem Browser der Käufer stehlen. Die Methode heißt Web-Skimming oder Formjacking: Angreifer platzieren manipuliertes JavaScript auf der Checkout- oder Bezahlseite, das die eingegebenen Karten- und Adressdaten in Echtzeit mitliest und an einen von ihnen kontrollierten Server sendet. Der Begriff spielt auf die klassischen Kartenleser an Geldautomaten an - nur passiert das Abgreifen hier rein digital und für den Kunden völlig unsichtbar.

Der entscheidende Unterschied zu vielen anderen Angriffen liegt darin, dass Web-Skimming ein clientseitiger Angriff ist. Der Schadcode wird nicht auf Ihrem Server ausgeführt, sondern im Browser des Besuchers. Ein serverseitiger Virenscan oder eine Firewall bemerkt davon oft nichts, weil die eigentliche Datenabführung erst auf dem Endgerät des Kunden stattfindet. Genau deshalb bleiben Skimmer häufig wochen- oder monatelang unentdeckt: In einer im Januar 2026 aufgedeckten Kampagne war ein Skimming-Netzwerk seit 2022 unbemerkt aktiv und griff Karten von sechs großen Zahlungsnetzwerken ab (Silent Push/Malwarebytes).

Warum die Bedrohung 2026 deutlich zunimmt

Web-Skimming ist keine Randerscheinung mehr, sondern ein industriell betriebenes Geschäftsmodell. Die Angriffszahlen sind zuletzt deutlich gestiegen. Der Sicherheitsdienstleister Sansec fügt seinem Scanner täglich durchschnittlich 30 neue Skimmer-Signaturen hinzu (Sansec) - ein Maß für die Geschwindigkeit, mit der die Angreifer ihren Schadcode variieren und tarnen. Für 2025 wurden mehr als 10.500 aktive Skimming-Infektionen gezählt, über die mehr als 23 Millionen Transaktionen kompromittiert wurden (Recorded Future).

Der Anstieg hat mehrere Ursachen. Erstens stützen sich Shops immer stärker auf Drittanbieter-Skripte, die aus dem laufenden Betrieb schwer wegzudenken sind - jede dieser Einbindungen ist ein möglicher Einstiegspunkt. Zweitens sind Skimming-Baukästen günstig zu haben und leicht zu bedienen. Drittens werden die Angriffe technisch raffinierter: Kampagnen tarnen ihren Code in unsichtbaren Grafiken, imitieren legitime Zahlungsanbieter oder nutzen fremde Cloud-Infrastruktur als Tarnung. Wer den Cyber Resilience Act und seine Pflichten im Blick behält, erkennt schnell, dass Produktsicherheit über die reine Serverkonfiguration hinausgeht.

Wie ein Skimmer in den Checkout gelangt

Ein wirksames Abwehrkonzept beginnt mit dem Verständnis der Einfallstore. In der Praxis nutzen Angreifer immer wieder dieselben Wege, um ihren Schadcode auf die Zahlungsseite zu bringen:

• Kompromittierte Fremd-Skripte: Analyse-Werkzeuge, Chat-Widgets, Tag-Manager oder Werbe-Snippets werden von einer externen Domain geladen. Wird der Anbieter oder das ausgelieferte Skript manipuliert, gelangt der Skimmer ohne eigenen Einbruch in Ihren Shop. In einer Kampagne im April 2026 versteckten Angreifer den Schadcode in unsichtbaren SVG-Elementen und blendeten auf 99 Shops eine gefälschte Checkout-Ebene ein, die Daten an sechs Angreifer-Domains ausleitete (Sansec).
• Veraltete Shop-Software und ungepatchte Erweiterungen: Bekannte Lücken in alten Versionen oder Plugins sind ein Standard-Einfallstor. Über eine einzige Schwachstelle wurden im März 2026 471 Shops in nur einer Stunde kompromittiert (Sansec). Wer noch auf einer abgekündigten Version arbeitet, sollte die Migration weg von Shopware 5 nicht aufschieben.
• Gestohlene Zugänge und Lieferkette: Erbeutete Administrator-Passwörter oder eine manipulierte Abhängigkeit erlauben es, Code direkt einzuschleusen. Angriffe über die Software-Lieferkette treffen mit einem Schlag viele Shops gleichzeitig.
• Gefälschte Zahlungs-Infrastruktur: Manche Kampagnen missbrauchen die Namen und Schnittstellen echter Zahlungsdienste, um seriös zu wirken. Ein Skimmer-Netzwerk betrieb dazu über 4.800 gefälschte Shop-Storefronts unter .shop-Domains, die bekannte Marken imitierten (Sansec).

Auffällig ist, dass viele dieser Wege gar keinen direkten Einbruch in den Shop-Server voraussetzen. Der Skimmer kommt über ein Drittsystem - und lebt anschließend im Browser des Kunden. Genau deshalb greifen klassische, rein serverseitige Schutzmaßnahmen hier zu kurz.

Anzeichen: Woran Sie einen kompromittierten Checkout erkennen

Weil der Schadcode im Browser ausgeführt wird, ist die Überwachung der ausgelieferten Seite entscheidend. Ein reiner Server-Scan reicht nicht, weil das schädliche Fremd-Skript oft gar nicht auf Ihrem Server liegt. Diese Signale deuten auf eine Kompromittierung hin:

• Unerwartete ausgehende Verbindungen: Die Zahlungsseite kontaktiert eine unbekannte Domain, die zuvor nie eingebunden war.
• Veränderte Skript-Inhalte: Der Prüfwert (Hash) eines eingebundenen Skripts weicht plötzlich von der freigegebenen Fassung ab.
• Neue oder unbekannte Skript-Tags im Quelltext des Checkouts, die niemand bewusst hinzugefügt hat.
• Verstöße gegen die Content-Security-Policy, die im Browser oder in Ihren Protokollen auftauchen.
• Häufung von Betrugsmeldungen: Kundinnen und Kunden berichten über missbräuchliche Kartenabbuchungen kurz nach dem Einkauf. Ein systematisches Betrugserkennungs-Konzept macht solche Muster früher sichtbar.

Schutz mit Skript-Inventar, CSP und SRI

Gegen Web-Skimming greift keine einzelne Maßnahme, sondern ein Zusammenspiel mehrerer Bausteine. Sie verfolgen alle dasselbe Ziel: Nur ausdrücklich freigegebene Skripte dürfen im Checkout laufen, und jede unautorisierte Änderung fällt sofort auf.

Content-Security-Policy und Subresource Integrity sind Standardmechanismen moderner Browser und lassen sich schrittweise einführen. Wichtig ist eine saubere Pflege: Ändert ein Zahlungsanbieter sein Skript, muss der hinterlegte Hash mitgezogen werden. In der Programmierung und Weiterentwicklung Ihres Shops gehören diese Regeln daher fest in den Freigabeprozess. Ein Beispiel für eine restriktive Richtlinie und eine per Hash abgesicherte Einbindung:

<!-- CSP-Header: nur eigene und ausdrücklich erlaubte Quellen -->
<!-- Content-Security-Policy:
     default-src 'self';
     script-src 'self' https://js.zahlungsanbieter.example;
     connect-src 'self' https://api.zahlungsanbieter.example -->

<!-- Externes Skript per Subresource Integrity abgesichert -->
<script src="https://js.zahlungsanbieter.example/checkout.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K9dEXamplEhaSh"
        crossorigin="anonymous"></script>

Ergänzend hilft es, die Zahl der Fremd-Skripte grundsätzlich klein zu halten. Jedes Skript, das nicht geladen wird, kann auch nicht kompromittiert werden. Wer seinen Shop von unnötigen Drittanbieter-Skripten entschlackt, verbessert damit zugleich die Ladezeit und die Sicherheit des Checkouts.

PCI DSS 6.4.3 und 11.6.1: Checkout-Integrität ist Pflicht

Der Schutz der Zahlungsseite ist nicht nur eine gute Idee, sondern für Händler, die Kartendaten verarbeiten, eine verbindliche Vorgabe. Der Sicherheitsstandard PCI DSS 4.0 hat dafür zwei neue Anforderungen eingeführt, die seit dem 31. März 2025 verpflichtend sind (PCI SSC).

Anforderung 6.4.3 verlangt, dass jedes auf der Zahlungsseite ausgeführte Skript autorisiert ist, seine Integrität sichergestellt wird und ein vollständiges, begründetes Inventar aller Skripte geführt wird (PCI SSC). Anforderung 11.6.1 verlangt einen Mechanismus, der eine unautorisierte Änderung der im Browser empfangenen Zahlungsseite oder ihrer HTTP-Header erkennt und meldet - und der mindestens alle sieben Tage ausgeführt wird (PCI SSC). Die eine Regel definiert den Soll-Zustand, die andere überwacht die Abweichung.

Ein Abwehrkonzept Schritt für Schritt

Aus den einzelnen Bausteinen wird ein belastbarer Schutz, wenn sie in einer festen Reihenfolge umgesetzt und laufend gepflegt werden. Die folgende Abfolge hat sich in der Praxis bewährt:

1. Inventarisieren: Alle Skripte auf Checkout- und Zahlungsseiten erfassen und je Eintrag begründen, warum er nötig ist.
2. Minimieren: Nicht mehr benötigte oder doppelte Skripte entfernen und die Zahl externer Einbindungen bewusst klein halten.
3. CSP einführen: Eine restriktive Content-Security-Policy setzen, die nur freigegebene Quellen für Skripte und Datenziele erlaubt.
4. SRI setzen: Externe Skripte per Subresource-Integrity-Hash absichern und den Hash bei jeder Aktualisierung mitziehen.
5. Überwachen: Ein Tamper-Monitoring einrichten, das Änderungen an Skripten und Seiteninhalten im ausgelieferten Zustand meldet.
6. Patchen: Shop-System und Erweiterungen aktuell halten; eine erfahrene Shopware-Agentur kann Updates planbar und getestet einspielen.
7. Reagieren: Einen Ablauf für den Ernstfall festlegen - vom Isolieren der Zahlungsseite bis zur sauberen Wiederherstellung aus einem geprüften Backup.

Kein einzelner Schritt ersetzt die anderen. Erst das Zusammenspiel aus Reduktion, Regelwerk und Überwachung macht den Checkout widerstandsfähig. Und weil sich Angriffe und eingebundene Dienste laufend ändern, ist Sicherheit kein einmaliges Projekt, sondern ein fortlaufender Betriebsprozess - vergleichbar mit dem kontinuierlichen Shop-Monitoring für Verfügbarkeit und Leistung.

Checkout-Sicherheit jetzt im Betrieb verankern

Web-Skimming trifft nicht nur große Marken - im Gegenteil, kleinere Shops geraten ins Visier, weil sie seltener über eigene Sicherheitsprozesse verfügen. Die gute Nachricht ist, dass sich der Checkout mit überschaubaren, bewährten Maßnahmen deutlich härten lässt. Entscheidend ist, dass Skript-Inventar, CSP, SRI und Überwachung fest im laufenden Betrieb verankert sind und nicht als einmalige Aktion verpuffen.

Ob manipuliertes Fremd-Skript, veraltete Erweiterung oder gefälschte Zahlungsseite: Entscheidend ist, dass die Integrität Ihres Checkouts laufend geprüft wird, bevor Kartendaten verloren gehen. Auch behördliche und automatisierte Prüfungen nehmen zu - wer die technische Sorgfalt ernst nimmt, ist zugleich auf Kontrollen wie den automatisierten BFSG-Scan besser vorbereitet. Wir prüfen den aktuellen Stand Ihrer Zahlungsseite, richten CSP, SRI und ein Skript-Inventar ein und etablieren eine passende Überwachung. Sprechen Sie unser Team an, um die Checkout-Sicherheit Ihres Shops planbar aufzusetzen.