Shopify Checkout Phishing-Angriff: Was passiert ist und wie du deinen Shop prüfst

Die Shopify Checkout Phishing-Attacke ist eine Kampagne, über die erstmals am 10. Oktober 2026 berichtet wurde. Dabei wurden Drittanbieter-Storefront-Apps dazu gebracht, Code zu laden, der Käufer, die auf Checkout geklickt haben, auf eine gefälschte Checkout-Seite weiterleitete. Die gefälschte Seite erfasste ihre Kartendaten und leitete sie dann an den echten Checkout des Stores weiter.

Status, geprüft am 19. Oktober 2026: Erst am 18. Oktober wurden neue Aktivitäten gemeldet. Swym gab in einem FAQ an, dass unbefugte Aktivitäten ab 21:17 UTC den Zugriff der Wishlist Plus-App nutzten, um Skripte zu einigen Stores hinzuzufügen, weshalb die App für alle Händler deaktiviert und ihre Shopify-Anmeldedaten widerrufen wurden. Swym hat dieses FAQ inzwischen offline genommen und die Statusseite listet weiterhin einen laufenden Vorfall auf. Die App Store-Einträge für Hulk Product Options, Swym Wishlist Plus, Selleasy, Boost AI Search & Filter und Privy zeigen alle „derzeit nicht verfügbar“ an. Boost und Privy haben ihre Einträge nicht mit der Kampagne in Verbindung gebracht.¹²³

Wichtigste Erkenntnisse

• Seit mindestens dem 10. Oktober 2026 wurde einigen Käufern, die auf Checkout klickten, ein nachgebauter Checkout angezeigt, der ihre Kartendaten an einen Angreifer sendete und sie dann zum echten weiterleitete.
• HulkApps, Selleasy und Swym haben bestätigt, dass eine unbefugte Partei geändert hat, was ihre Apps auf einigen Storefronts geladen haben. Keiner hat eine vollständige Ursache veröffentlicht.
• Keine Quelle besagt, dass Shopifys eigener Checkout oder die Systeme gehackt wurden. Der Code lief auf den Storefront-Seiten, bevor der Checkout geladen wurde.
• In der ersten Welle kam der Code innerhalb der App-Einstellungen an, nicht in Theme-Dateien, weshalb eine Code-Suche ihn nicht gefunden hätte. Der Live-Checkout-Test ist die Prüfung, auf die es ankommt.
• Jede App, die Code in deiner Storefront lädt, ist Code, den jemand anderes ändern kann. Diejenigen zu entfernen, die du nicht brauchst, verringert das Risiko dauerhaft.

Warum du uns vertrauen kannst

Jacques hat mehr als 15 Jahre Entwicklungserfahrung und wir haben über vier Jahre lang in Shopify-Themes für Hunderte von Händlern gearbeitet. Wir entwickeln Fudge, den KI-Operator für Shopify-Stores, mit einer 4.9-Bewertung im Shopify App Store. Es liest den echten Theme-Code eines Stores und kann eine Live-Storefront in einem echten Browser testen.

Dies ist kein forensischer Bericht. Jede Behauptung unten ist mit einer Aussage des Anbieters, der Shopify-Dokumentation oder dem Entwickler verknüpft, der den Angriff gefunden hat. Wir weisen darauf hin, wenn eine Behauptung auf dem Bericht einer einzelnen Person beruht.

Was ist beim Shopify Checkout Phishing-Angriff passiert?

Der Entwickler Roman Zipp entdeckte es durch Zufall am 10. Oktober. Er kaufte im Shopify-Store eines Tastaturhändlers ein, klickte auf Checkout, und sein Passwort-Manager versuchte, die falschen Felder auf einer Seite auszufüllen, die wie der Checkout von Shopify aussah. Die Adressleiste zeigte eine Domain, die er nicht kannte.⁴

Er wiederholte das Ganze in einem privaten Fenster mit Testdaten. Das Formular sendete diese an den Server des Angreifers, der mit einer Datensatznummer antwortete, und die Seite leitete ihn dann zum echten Checkout des Shops weiter.⁴

Er verfolgte den Code zurück zu Hulk Product Options und meldete ihn. Seine Timeline zeigt, dass der Hijack 16 Minuten, nachdem Shopify ihn intern eskaliert hatte, aus diesem Shop verschwunden war. Innerhalb weniger Tage meldeten Händler, die nie eine HulkApps-App installiert hatten, denselben Fake-Checkout, und Selleasy sowie Swym bestätigten eigene Vorfälle.⁴⁵⁶⁷

Zeitlicher Ablauf

Wie funktionierte der Fake-Checkout-Redirect?

Die Angreifer haben den Checkout von Shopify nie angerührt. Sie haben den Klick, der dorthin führt, gekapert.

Apps fügen über App Embeds Code zu deiner Storefront hinzu, den Shopify kurz vor dem schließenden </head>- oder </body>-Tag jeder Seite einschleust.¹¹ Der Checkout ist eine andere Welt: Apps, die ihn erweitern, laufen in einer isolierten Sandbox ohne Zugriff auf die Checkout-Seite oder auf Zahlungsdaten.¹² Wir behandeln diese Sandbox in unserem Guide zur Shopify Checkout Extensibility.

Der Code lief also auf der Produkt- und Warenkorbseite, wartete auf einen Klick auf Checkout und schickte den Käufer woanders hin, bevor der Checkout von Shopify überhaupt laden konnte.

Weg 1: Code versteckt in App-Einstellungen

Viele Storefront-Apps bringen ein kleines Skript mit, das bei jedem Seitenaufruf die Server des Anbieters nach den Einstellungen dieses Shops fragt. In der ersten Welle waren genau diese Einstellungen der Payload.

• HulkApps: Das app-eigene Skript kam vom Shopify-CDN und war sauber. Zipp fand etwa 22,7 KB an zusätzlichem JavaScript in einem Custom-Code-Feld der Einstellungen, die von der HulkApps-API heruntergeladen wurden.⁴
• Selleasy: In der Mitteilung an die Händler heißt es, ein Außenstehender sei in eines der internen Tools von Selleasy eingedrungen und habe ein Skript in den Selleasy-Einstellungen mehrerer Shops platziert.⁵
• Swym (14. Oktober): Swym beschreibt eine unbefugte Änderung an der App-Konfiguration. Der Entwickler Dan Sutherland, der einen betroffenen Shop untersuchte, berichtet, dass der Angriffs-String dort saß, wo eigentlich die Beschriftung des „Zur Wunschliste hinzufügen“-Buttons hätte sein sollen.⁷¹³
• Qikify (Juli): Code wurde in anpassbare HTML-Felder der App-Einstellungen gepflanzt, und laut Qikify wurde nichts in die Themes der Händler geschrieben.⁸

Eine Suche im Theme-Code hätte keinen davon gefunden. Der Code lag auf den Servern der Anbieter und tauchte nur im Browser des Käufers auf.

Weg 2: Nutzung des App-Zugriffs auf den Shop

Der Vorfall bei Swym vom 18. Oktober ist anders. Swym sagt, die Aktivität nutzte den eigenen Zugriff der Wishlist Plus-App auf die Shops, nicht die Mitarbeiter-Accounts der Händler, um Skripte hinzuzufügen, die versuchten, Käufer umzuleiten. Sie raten den Händlern, ihre Theme-Dateien auf Änderungen durch die Swym-App zu überprüfen und nach checkout-guard zu suchen.¹

Damit lohnt sich nun auch eine Theme-Suche. Wir zeigen dir unten, wie das geht.

Was der Code im Browser des Käufers machte

Aus dem von Zipp abgefangenen Code:⁴

1. Er hat auf das Antippen oder den Klick auf Checkout gewartet.
2. Er hat einen nachgemachten Checkout auf einer fremden Domain geladen.
3. Die Kartendaten gingen an den Server des Angreifers.
4. Der Käufer wurde an den echten Checkout weitergeleitet, um erneut zu bezahlen, sodass die Bestellung trotzdem durchging.
5. Er hat __ctf_shim_handoff_done_v1 im Session Storage gesetzt, damit er nicht zweimal beim selben Käufer ausgelöst wurde.

HulkApps fügt hinzu, dass der Redirect bei manchen Besuchen fehlschlug und einige Browser ihn blockierten.⁹ Alles in allem konnte ein Shopbetreiber, der seinen eigenen Checkout testete, leicht überhaupt nichts bemerken.

Bisher genannte Domains

Besuche diese Domains nicht. Jede ist in eckigen Klammern geschrieben, damit man nicht darauf klicken kann.

Wie kamen die Angreifer rein?

Niemand hat das öffentlich gesagt. HulkApps nennt es „einen Exploit“. Selleasy nennt ein internes Tool. Swym beschreibt eine unbefugte Änderung und dann die Nutzung des App-Zugriffs.⁹⁵¹

Zipp listet vier Möglichkeiten für den HulkApps-Fall auf und hat keine davon bestätigt: der HulkApps-Account eines Händlers, der Account eines HulkApps-Mitarbeiters, HulkApps selbst oder eine andere App, die die Konfiguration ändert.⁴

Welche Shopify-Apps waren beteiligt?

Es gibt keine Beweise dafür, dass einer dieser Anbieter den schädlichen Code geschrieben hat. HulkApps, Selleasy, Swym und Qikify sagen, dass Angreifer ihre Apps zur Auslieferung genutzt haben.

Wurde Hulk Product Options gehackt? Was HulkApps sagt

Laut HulkApps hat ein Exploit am 10. Oktober unbefugte Konfigurationen in Hulk Product Options eingeschleust, im Rahmen eines breiteren Angriffs auf mehrere Shopify-Apps. HulkApps führt jeden Redirect, der mit seinen Apps in Verbindung steht, auf einen einzigen Ort zurück: die Hulk Product Options Theme-Erweiterung (Theme App Extension). Shopify hat diese Erweiterung sicherheitshalber abgeschaltet und später wiederhergestellt.⁹

Sie haben eine unabhängige Sicherheitsfirma beauftragt, die Authentifizierung verstärkt und den Händlern mitgeteilt, dass sie die App nicht deinstallieren müssen. Der Eintrag im App Store wurde am 19. Oktober noch als nicht verfügbar angezeigt.⁹³

Selleasy (Logbase)

Logbase bezeichnet den 13. Oktober als einen gezielten, geplanten Angriff, bei dem ein Skript in einige der von Selleasy bedienten Shops eingeschleust wurde. Es wurden keine Beweise für einen Hack des Backends oder der Datenbank gefunden, und Logbase sagt, Shopify habe bestätigt, dass der Code am selben Tag entfernt wurde.⁶

Die Mitteilung an betroffene Händler ergänzt das Zeitfenster (07:47 bis 15:00 UTC) und besagt, dass die Custom-JS-Einstellung gesperrt wurde, sodass kein Tool oder API sie mehr ändern kann.⁵

Swym Wishlist Plus (Swym)

Swym hat zwei Vorfälle veröffentlicht:

1. 14. Oktober: Durch eine Konfigurationsänderung wurde auf einigen Storefronts ein Skript geladen, das Käufer möglicherweise auf einen gefälschten Checkout weitergeleitet hat. Swym hat seine API-Secrets rotiert und Bereinigungsregeln (Sanitization Rules) hinzugefügt. Händler werden gebeten, alles zu melden, was ihnen zwischen 10:06 und 16:32 UTC aufgefallen ist.⁷
2. 18. Oktober: Bei neuen Aktivitäten wurde der Zugriff der App genutzt, um Skripte zu einigen Shops hinzuzufügen. Swym hat die App für jeden Händler abgeschaltet, die Shopify-Anmeldedaten widerrufen und sagt, dass sie Auswirkungen auf Käufer derzeit weder bestätigen noch dementieren können.¹

Swym hat die Details zum 18. Oktober am 19. Oktober in einem FAQ veröffentlicht und dieses später am selben Tag wieder entfernt. Die Statusseite beschreibt weiterhin einen laufenden Vorfall und besagte am 19. Oktober um 15:30 UTC, dass Swym Maßnahmen zur Schadensbegrenzung (Mitigations) vorbereitet.¹²

Nicht bestätigt: Boost AI Search & Filter und Privy

Keiner der beiden Anbieter hat seine Probleme mit dieser Kampagne in Verbindung gebracht, und ein nicht verfügbarer App Store-Eintrag beweist nicht, dass eine App kompromittiert wurde. Beide Einträge waren am 19. Oktober nicht verfügbar.³

• Boost: Auf der Statusseite steht, dass die Theme App Extension am 17. Oktober für alle Shops abgeschaltet wurde und Shopify sie am nächsten Tag wieder aktiviert hat. Es wird ein Vorfall beschrieben, der die App-Funktionalität betrifft, Sicherheit wird nicht erwähnt.¹⁴ Ein Kommentator im Shopify-Community-Thread schreibt, dass derselbe Redirect am 17. Oktober in einem Shop, an dem er arbeitet, über die Boost-App aufgetreten sei.⁵
• Privy: Die Statusseite meldet einen Ausfall der On-Site-Displays vom 17. bis 18. Oktober, ohne Erwähnung von Sicherheit.¹⁵ Ein Kommentator unter Zipps Beitrag nennt Privy als Quelle in seinen Shops.⁴

Früher: Der Qikify-Vorfall im Juli

Qikifys eigene Mitteilung bezieht sich auf den 22. Juli 2026, als einige Checkouts aus ihren „Sticky Add to Cart“- und „Mega Menu“-Apps über die Einstellungsfelder der Apps auf eine betrügerische Seite umgeleitet wurden. Qikify hat die Authentifizierung über alle seine Apps hinweg am 29. Juli zurückgesetzt, und beide waren am 21. August wieder im App Store.⁸

Zipps Beitrag listet auch einen Fall bei Hextom im August auf. Hextom hat keine Mitteilung veröffentlicht, und wir konnten dies nicht verifizieren.

Wurde Shopify gehackt? Was Shopify gesagt hat

Nichts, was bisher veröffentlicht wurde, deutet darauf hin. Weder Shopify noch irgendeine Erklärung der Anbieter beschreibt einen Hack von Shopifys eigenen Systemen.

Shopify hat bis zum 19. Oktober keinen Beitrag oder Changelog-Eintrag über die Kampagne veröffentlicht. Ein Sprecher sagte gegenüber iTnews: „Wenn eine App Mängel aufweist, handeln wir.“ Shopify erklärt, dass dies die Entfernung der App (Delisting) bedeuten kann, und in diesen Fällen werden die App-Entwickler aufgefordert, betroffene Händler direkt zu kontaktieren.¹⁰ Auf der Seite mit den Richtlinien für Partner werden auch drastischere Maßnahmen aufgeführt, darunter das Entfernen einer App aus den Shops der Händler und das Kappen des API-Zugriffs.¹⁶

Shopify hat auf einzelne Meldungen reagiert. Einer australischen Händlerin, die über Selleasy betroffen war, wurde geraten, ihren Shop geschlossen zu halten, während Shopify die Sache untersuchte. Am 19. Oktober sagte sie gegenüber iTnews, dass Shopify ihr mitgeteilt habe, sie könne wieder öffnen.¹⁰⁵

Wie überprüfst du deinen Shop auf den Fake-Checkout-Redirect?

Dupliziere dein Live-Theme, bevor du irgendetwas änderst (Onlineshop, das …-Menü bei deinem Theme, Duplizieren). Gehe diese Schritte dann der Reihe nach durch.

1. Führe den Fünf-Minuten-Checkout-Test durch

Das ist die Prüfung, die die erste Welle erwischt hätte.

• Öffne ein neues privates Fenster (Inkognito-Modus). Es startet mit leerem Browser-Speicher, was gleich aus zwei Gründen wichtig ist: Das Skript löste nur einmal pro Session aus, und ein Entwickler berichtet, dass Swyms Einstellungen im Browser gecached wurden und den Payload am Leben halten konnten, selbst nachdem die App abgeschaltet war.¹³
• Lege ein Produkt in den Warenkorb und benutze den normalen Checkout-Button (bzw. Zur Kasse) anstelle einer Express-Option wie Shop Pay oder PayPal.
• Lies dir die Adressleiste in dem Moment durch, in dem die Checkout-Seite erscheint. Der Checkout von Shopify läuft auf deiner eigenen Domain oder auf deiner myshopify.com-Adresse, falls du keine eigene Domain verknüpft hast. Shopify hat ihn 2017 dorthin verlegt.¹⁷ Jede andere Domain zu diesem Zeitpunkt ist ein rotes Tuch. Gib keine Kartendaten ein. Behandle es als echten Vorfall.
• Schließe das Fenster, öffne ein neues und wiederhole das Ganze aus dem Warenkorb-Drawer (Cart Drawer). Qikify sagt, dass ihr „Sticky Add to Cart“-Redirect auslöste, wenn Käufer im Warenkorb-Drawer auf Checkout klickten.⁸
• Wiederhole es noch einmal auf deinem Handy.

Karten-Seiten deines Zahlungsanbieters oder deiner Bank, wie z.B. 3-D Secure, können im späteren Verlauf des Checkouts auftauchen. Das Alarmsignal ist eine andere Domain genau zu dem Zeitpunkt, an dem die Checkout-Seite zum ersten Mal lädt.

2. Finde jede App, die Code auf deinen Seiten ausführen kann

• Einstellungen > Apps listet deine installierten Apps auf.¹⁸ Achte auf Hulk Product Options, Swym Wishlist Plus und Selleasy (bestätigte Vorfälle), und ob du Boost AI Search & Filter oder Privy nutzt. Öffne eine beliebige App, um ihre Erweiterungen-Karte (Extensions) zu sehen, die anzeigt, was wo aktiv ist.¹⁸
• Onlineshop > Theme bearbeiten und dann das App Embeds-Icon in der Seitenleiste zeigt dir jedes eingeschaltete Embed.¹⁹ Jedes davon kann Code auf jeder Seite laden.

3. Durchsuche dein Theme nach bekannten Markern

Gehe zu Onlineshop, öffne das …-Menü bei deinem Live-Theme und wähle Code bearbeiten. Der Suchen-Button in der linken Seitenleiste durchsucht alle Theme-Dateien auf einmal.²⁰ Eine Führung durch den Editor findest du unter Wie man sein Shopify-Theme bearbeitet.

Suche nach:

• Jeder Domain aus der Tabelle oben, ohne die eckigen Klammern (zum Beispiel biliing.top)
• checkout-guard, wonach Swym Händler zu suchen bittet¹
• __ctf_, dem Präfix der Storage-Keys, die Zipp gefunden hat⁴

Wenn du nur nach .top suchst, wirst du mit harmlosen CSS- und JavaScript-Treffern überschwemmt.

Eine saubere Suche deckt nur das Theme ab. Code, der innerhalb der Einstellungen einer App ankommt, taucht dort nie auf.

4. Optional: Schau in die Entwicklertools des Browsers

Wenn du dich mit den Chrome DevTools auskennst, öffne sie während eines Test-Checkouts. Suche unter Application > Session storage nach __ctf_-Keys. Prüfe im Network-Tab jede Domain, die deine Produkt- und Warenkorbseiten kontaktieren, und stelle sicher, dass du den Inhaber jeder einzelnen Domain benennen kannst.

5. Hör auf deine Kunden

Weil die gefälschte Seite Käufer an den echten Checkout weitergeleitet hat, können Bestellungen völlig normal aussehen. Die Warnsignale kommen stattdessen von den Kunden: eine Support-E-Mail über eine seltsam aussehende Zahlungsseite oder eine Meldung über Kreditkartenbetrug kurz nach einer Bestellung bei dir.

Kann Fudge meinen Shop auf den Checkout-Phishing-Redirect prüfen?

Teilweise. Fudge kann den Live-Checkout-Test durchführen, der die erste Welle erwischt hätte, und dein Theme nach den Markern vom 18. Oktober durchsuchen. Es kann weder Server von Anbietern einsehen noch beweisen, dass keine Karte gestohlen wurde.

Was Fudge prüfen kann

• Der Live-Test, in einem echten Browser. Fudge öffnet deinen veröffentlichten Shop, fügt ein Produkt hinzu, klickt auf der Warenkorb-Seite und im Cart-Drawer auf Checkout und zeichnet jede Seite auf, auf der es landet, jede Domain, die die Seite kontaktiert, und was diese Requests zurückgeben. Genau da fällt Code auf, der in App-Einstellungen versteckt ist. Das ist dieselbe Technik, die auch hinter unserem Checkout-Flow-Walkthrough steckt.
• Die Theme-Suche. Fudge kann jede Datei in deinem veröffentlichten Theme nach den oben genannten Domains und Markern durchsuchen und die aktivierten App-Embeds auflisten. Siehe dir dazu unsere Theme-Code-Untersuchung an.
• Ein Test im Entwurf. Es kann ein verdächtiges Embed in einer Entwurfskopie deines Themes zu Testzwecken deaktivieren. Wenn du bereits einen Redirect bemerkt hast, warte nicht auf einen Entwurf: Schalte das Embed sofort in deinem Live-Theme ab.

Was ein Fudge-Check nicht beweisen kann

• Es kann deine installierten Apps nicht auflisten oder die Einstellungen im eigenen Adminbereich einer App lesen.
• Es kann keine Server von Anbietern oder Logs einsehen und dir nicht sagen, ob eine Karte abgegriffen wurde.
• Es läuft über einen Cloud-Browser an einem einzigen Standort. Niemand weiß, ob dieser Code automatisierte Browser oder bestimmte Länder ignoriert hat, und er ist bei manchen Besuchen ohnehin schon fehlgeschlagen.
• Es kann die Reaktion darauf nicht für dich übernehmen: den Shopify-Support, deinen Zahlungsanbieter und deine Kunden.

Das ehrliche Ergebnis eines sauberen Durchlaufs lautet also: Bei diesem Test wurde zu diesem Zeitpunkt kein Redirect oder bekannter Marker gefunden. Es heißt nicht: Dein Shop war niemals betroffen.

Prompt: Bitte Fudge, den Check durchzuführen

Kopiere das hier in Fudge:

Führe einen schreibgeschützten (read-only) Sicherheitscheck meines veröffentlichten Shopify-Shops auf den Checkout-Phishing-Redirect vom Oktober 2026 durch. Bearbeite, erstelle oder veröffentliche nichts. Gib keine Zahlungsdaten ein und sende kein Formular auf einer Seite außerhalb der Domain meines Shops ab.

1. Nutze in meinem veröffentlichten Shop für jeden Durchlauf einen separaten Browser-Agent, damit jeder mit leerem Speicher startet. Öffne bei mobilen und Desktop-Größen eine Produktseite, lege das Produkt in den Warenkorb und klicke auf den Haupt-Checkout-Button – einmal von der Warenkorbseite und einmal aus dem Warenkorb-Drawer. Berichte über jede URL, auf der der Browser landet, und sag mir sofort Bescheid, wenn er die Domain meines Shops oder die myshopify.com-Adresse verlässt, bevor die Checkout-Seite lädt.
2. Liste jede fremde Domain auf, die auf den Produkt- und Warenkorbseiten Skripte lädt oder Anfragen empfängt, gruppiert nach der App oder dem Dienst, zu dem sie gehört. Markiere jede Domain, die auf .top endet, und jede Antwort, die einen Redirect enthält.
3. Prüfe den Session Storage und Local Storage auf Keys, die mit __ctf_ beginnen, und, falls du das erkennen kannst, welches Skript sie gesetzt hat.
4. Durchsuche jede Datei in meinem veröffentlichten Theme nach biliing.top, checkout-confirm.top, order-confirm.top, account-confirm.top, billing-confirm.top, checkout-guard, checkout-secure.top und __ctf_, sowie nach jedem Skript, das Käufer auf eine andere Domain schickt, wenn sie auf Checkout klicken.
5. Liste die App Embeds auf, die in meinem veröffentlichten Theme eingeschaltet sind, und die App hinter jedem einzelnen.

Gib für jeden Fund die Datei oder URL an, was der Code tut und wie sicher du dir bist. Beende den Check mit einer Liste dessen, was er nicht sehen konnte.

Was solltest du tun, wenn dein Shop betroffen ist?

Erstens: Eindämmen

• Sichere die Beweise. Mach einen Screenshot der Fake-Seite mit sichtbarer Adresse, kopiere die vollständige URL und notiere dir die Uhrzeit. In den DevTools kannst du das Network-Log als HAR-Datei speichern. HAR-Dateien können deine Login-Cookies enthalten, teile sie also nur mit dem Shopify-Support oder dem App-Anbieter.
• Schalte den Code ab. Deaktiviere das App Embed unter App Embeds und speichere, oder deinstalliere die App.¹⁹ Durch eine Deinstallation wird nicht immer alles entfernt, was eine App zu deinem Theme hinzugefügt hat, also prüfe auch das Theme.²¹ Unser Guide zum Entfernen von übrig gebliebenem App-Code führt dich da Schritt für Schritt durch.
• Teste erneut in einem frischen privaten Fenster. Gecachete Einstellungen können die Abschaltung der App überdauern.¹³

Zweitens: Melden

• Dem App-Anbieter: Lass es dir schriftlich geben: was eingeschleust wurde, wann es auf deinem Shop live war und wie ihre öffentliche Stellungnahme lautet.
• Dem Shopify-Support: Sende deine Beweise ein und sei darauf vorbereitet, dass Shopify vorschlägt, den Shop während der Untersuchung zu schließen, wie sie es bei mindestens einem Händler getan haben.⁵
• Deinem Zahlungsanbieter (Payment Processor): Bei Shopify Payments erwähne es in deinem Support-Ticket. Bei jedem anderen Gateway kontaktiere sie direkt. Karten könnten selbst bei Bestellungen kopiert worden sein, die normal abgeschlossen wurden.
• Die Domain: Zipp hat die von ihm gefundenen Domains an Google Safe Browsing und URLhaus gemeldet, was Browsern hilft, Käufer rechtzeitig zu warnen.⁴

Drittens: Schotten dichtmachen

• Ändere dein Shopify-Passwort sowie das Passwort für jedes Dashboard der App-Anbieter und aktiviere die Zwei-Faktor-Authentifizierung.²²
• Unter Einstellungen > Benutzer (Users) filtere nach Mitarbeiter/Partner (Collaborators) und entferne alle Partnerzugriffe, die du nicht brauchst. Wenn du einen neuen Collaborator-Anfragecode generierst, wird der alte ungültig.²³
• Überprüfe, welche Apps und KI-Tools Zugriff auf deinen Shop haben, wie Zipp vorschlägt.⁴ Das schließt auch Fudge ein.
• Frag einen Anwalt und deinen Zahlungsanbieter, ob du Käufer oder Aufsichtsbehörden benachrichtigen musst. Swym verweist Händler auf Gesetze zur Meldung von Datenschutzverletzungen sowie auf ihren Vertrag mit dem Zahlungsanbieter.⁷ Dies ist keine Rechtsberatung.

Was du Kunden sagen kannst, die nachfragen: Dein echter Checkout liegt auf deiner eigenen Domain. Wenn sie beim Bezahlen eine andere Adresse gesehen haben, sollten sie sich wegen der Karte an ihre Bank (den Kartenaussteller) wenden. Halte dich mit Versprechen auf Rückerstattungen zurück, bis sich dein Zahlungsanbieter deinen Fall angesehen hat.

Wie reduzierst du das Risiko durch Storefront-Apps?

Jede App, die Code in deiner Storefront lädt, ist Code, den jemand anderes ändern kann. Das schließt auch Apps ein, denen du vertraust.

Wenn eine App ihre Einstellungen bei jedem Seitenaufruf von den Servern des Anbieters abruft, kann sich das, was in deinem Shop läuft, ändern, ohne dass auch nur eine einzige Anpassung an deinem Theme vorgenommen wird. Nichts davon taucht in deinen Theme-Dateien oder im Theme-Verlauf auf. Du findest es erst heraus, wenn ein Kunde es bemerkt.

Shopify schränkt ein, wie Apps Code laden können. Seit dem 1. Oktober 2026 können Apps keine neuen Script Tags mehr erstellen, und Shopify stoppt das Laden von Storefront-Script-Tags am 1. März 2027.²⁴ Damit bleiben App Embeds als primär unterstützter Weg, und diese kannst du in einem einzigen Panel überprüfen. Es hindert ein Embed aber nicht daran, neuen Code vom Anbieter nachzuladen, und eine App mit Theme-Zugriff kann weiterhin Theme-Dateien bearbeiten.

Stelle drei Fragen zu jedem App Embed

1. Nutzen wir es noch? Wenn nicht, deinstalliere es und räume die Überbleibsel auf.
2. Hat es eine Custom-JavaScript- oder Custom-HTML-Einstellung? Öffne sie und stelle sicher, dass du alles darin erkennst. Zipp fand den HulkApps-Payload in einem Custom-JavaScript-Feld, Selleasy sperrte seine Custom-JS-Einstellung nach dem Angriff, und Qikify nennt zwei HTML-Inhaltsfelder.⁴⁵⁸
3. Könnte dein Theme diese Aufgabe auch selbst erledigen?

Verlege ins Theme, was möglich ist

Einige der Aufgaben, die diese Apps erledigen, können stattdessen in dein Theme eingebaut werden. Nativer Code liegt in deinen Theme-Dateien, ändert sich nur, wenn jemand ihn bearbeitet, und jeder Entwickler kann ihn lesen. Er ist nicht immun: Eine App mit Theme-Zugriff kann ihn trotzdem bearbeiten, weshalb Swym Händler bittet, ihre Theme-Dateien zu überprüfen. Aber eine Änderung daran fällt bei einer Code-Suche auf.

• Produktoptionen (Product Options) wie Gravurtexte, Geschenknachrichten und Farbmuster (Swatches) können Varianten und Line Item Properties nutzen. Optionen, die den Preis ändern, benötigen Varianten oder ein separates Add-on-Produkt. Unser Produktkonfigurator-Guide behandelt die Bausteine.
• Cart Upsells und Cross-Sells können Shopifys eigene Produktempfehlungen in einer Cart-Sektion (Warenkorb-Bereich) verwenden. Sieh dir an, wie man Upsells im Shopify-Warenkorb hinzufügt.
• Bundles können oft Shopifys native Bundles nutzen. Wir haben die beiden in Native Shopify Bundles vs. Bundle Apps verglichen.

Einige Apps haben ihre Daseinsberechtigung. Eine Wishlist, die über mehrere Geräte synchronisiert, oder eine Suche über einen großen Katalog hinweg, braucht normalerweise ein Backend. Behalte diese, schalte alle Custom-Code-Einstellungen ab, die du nicht verwendest, und führe den Checkout-Test nach jedem Update erneut durch.

Mit Fudge beginnt der native Weg mit einem Prompt wie diesem (unsere Seite über die Apps, die Fudge ersetzt listet mehr dieser Aufgaben auf):

Hulk Product Options zeigt aktuell diese Optionen auf meinen Produktseiten: [Gravurtext, max 20 Zeichen; Geschenkverpackung ja/nein, +5$]. Wenn sie noch auf meiner Live-Produktseite gerendert werden, überprüfe sie auch dort. Baue sie als nativen Theme-Code nach und speichere jede Auswahl als Line Item Property, damit sie in der Bestellung angezeigt wird. Bei Optionen, die den Preis ändern, erkläre die Ansätze und Vor- und Nachteile, bevor du baust. Arbeite in einem Entwurfs-Theme (Draft Theme), damit ich es testen kann, bevor ich die App entferne.

Fudge ist ebenfalls eine App mit Zugriff auf dein Theme, daher gilt derselbe Rat auch für uns: Gewähre nur den Zugriff, den du nutzt, und überprüfe ihn. Die Änderungen, um die du Fudge bittest, fließen in eine Entwurfskopie (Draft) deines Themes, und keine davon erreicht deinen Live-Store, bis du sie im Shopify Store Editor überprüfst und veröffentlichst.

Deckt die PCI-Compliance von Shopify das ab?

Shopify ist nach Level 1 PCI DSS zertifiziert.²⁵ Nach unserem Verständnis bezieht sich diese Zertifizierung auf die Plattform und den Checkout von Shopify. Sie kann nicht dafür bürgen, was ein Drittanbieter-Skript auf deiner Produktseite anstellt, bevor der Käufer überhaupt am Checkout ankommt.

Das PCI Security Standards Council hat einen Namen für dieses Muster: Double-Entry Skimming – erst kommt ein gefälschtes Zahlungsformular, und der Käufer gibt seine Daten danach noch einmal in das echte ein.²⁶ Die Skript-Anforderungen für Zahlungsseiten (6.4.3 und 11.6.1) traten am 31. März 2025 in Kraft. Die FAQ des Councils besagen jedoch, dass die zugehörige SAQ A-Prüfung auf Händler abzielt, die ein Zahlungsformular auf ihren eigenen Seiten einbetten, nicht auf solche, die Käufer auf die Seite eines Anbieters weiterleiten.²⁷²⁸ Die FAQ erwähnen Shopify nicht namentlich. Frag also bei deinem Acquirer nach, wie ein von Shopify gehosteter Checkout für deinen Shop eingestuft wird.

FAQ