Faux checkout Shopify : ce que l’on sait de l’attaque et comment vérifier votre boutique

Note de transparence : Trafik Plus édite Snap Bundle, une application Shopify de bundles et d'upsell. Aucune des applications citées ici n'est la nôtre et nous ne sommes pas touchés, mais nous sommes du même côté que les éditeurs nommés plus bas. Cet article s'en tient à ce que disent les sources publiques, avec un lien pour chaque fait.

La réponse courte

Depuis le 10 octobre 2026, une attaque de phishing Shopify envoie des clients de vraies boutiques vers de fausses pages de paiement qui volent leur carte bancaire. La redirection vient d'un code injecté dans la configuration d'applications tierces (Hulk Product Options, Selleasy, Swym Wishlist Plus), pas d'une faille du checkout Shopify. Elle ne se déclenche qu'une fois par session, puis renvoie le client vers le vrai paiement : la commande passe et personne ne remarque rien.

Et ce n'est pas fini. Entre le 14 et le 18 octobre, Shopify a retiré 126 applications de l'App Store(ouvre dans un nouvel onglet), dont Privy, Rebuy, Upcart et Aftersell de Rokt, et plusieurs applications Bold. Le 19 octobre, les visiteurs d'une boutique étaient encore envoyés vers un faux checkout pendant une dizaine de minutes.

Si vous avez une boutique Shopify, prenez cinq minutes aujourd'hui : ouvrez-la en navigation privée, cliquez sur « Passer la commande » et regardez le domaine dans la barre d'adresse. La méthode est détaillée plus bas.

Ce qui s'est passé : chronologie de l'attaque de phishing Shopify

• 10 oct., 12:10. Le développeur Roman Zipp(ouvre dans un nouvel onglet) achète sur une boutique de claviers quand son gestionnaire de mots de passe propose de remplir le nom de sa carte dans un champ « Prénom » sur biliing[.]top. Le propriétaire d'une boutique de vape avait signalé ce même domaine sur Reddit 18 jours plus tôt.
• 10 oct., 15:27–16:37. Zipp prévient Shopify. Le signalement est escaladé à 16:21 et corrigé à 16:37. Shopify désactive temporairement l'extension de thème de Hulk Product Options.
• 13 oct. Selleasy, de Logbase, est touchée entre 07:47 et 15:00 UTC. Nous avons couvert les conséquences dans notre guide des alternatives à Selleasy.
• 14 oct. Swym confirme une modification non autorisée de la configuration de Wishlist Plus.
• 16 oct. Les fiches App Store de Hulk Product Options, Swym Wishlist Plus et Selleasy apparaissent indisponibles(ouvre dans un nouvel onglet).
• 14–18 oct. Shopify retire 126 applications(ouvre dans un nouvel onglet) de l'App Store, dont une centaine le 15 octobre. Privy, Boost AI Search & Filter et Rebuy suivent le 18 octobre. Privy est citée dans de nouveaux signalements ; son implication n'est pas confirmée.
• 19 oct. Le consultant CRO Kévin Miguet(ouvre dans un nouvel onglet) signale que pendant dix minutes, tous les visiteurs d'une boutique cliente ont été redirigés vers checkout-guard[.]top, un nouveau domaine, avant que la redirection ne disparaisse. D'autres marchands répondent avoir vu la même chose la veille.

Au 19 octobre, la cause racine reste inconnue et Shopify n'a publié aucune déclaration. L'entreprise a renvoyé Zipp vers son changelog et n'a pas pu dire combien de boutiques étaient touchées. Zipp comptait cinq à sept marchands au 15 octobre, un chiffre sûrement sous-estimé.

Comment fonctionne le faux checkout Shopify

L'attaque ne touche jamais le checkout de Shopify. Elle a lieu une étape plus tôt, sur la boutique, via du code qu'une application a le droit de charger.

1. Une application de confiance charge son script habituel. Dans le premier cas, c'était le fichier de Hulk Product Options, servi depuis cdn.shopify.com dans le cadre de son extension d'application de thème(ouvre dans un nouvel onglet).
2. Le script récupère ses réglages sur le serveur de l'éditeur. La réponse contenait un champ prévu pour les personnalisations du marchand, `custom_js`. L'attaquant y avait placé 22,7 Ko de JavaScript.
3. Le code injecté détourne le bouton de paiement. Au clic, le client arrive sur une copie de la page de paiement Shopify, sur un domaine comme biliing[.]top, checkout-confirm[.]top, order-confirm[.]top ou checkout-guard[.]top. Le logo est souvent faux.
4. La fausse page récupère la carte, l'envoie au serveur de l'attaquant, puis renvoie le client vers le vrai checkout.
5. Elle ne se déclenche qu'une fois par session.(ouvre dans un nouvel onglet) Des clés de session commençant par `__ctf_` l'empêchent de tourner deux fois : un marchand qui teste deux fois dans le même onglet ne voit rien.

Ni les bloqueurs de publicité ni les filtres DNS n'ont bloqué ces domaines. L'attaquant n'a pas eu besoin de pirater Shopify : il lui suffisait d'un accès en écriture à la configuration d'une application. Comment il l'a obtenu reste inconnu. Zipp avance quatre pistes : un compte marchand compromis, un compte d'employé de l'éditeur compromis, une compromission de l'éditeur lui-même, ou une autre application malveillante.

Quelles applications sont concernées

La vague de retraits de l'App Store

Les cas confirmés ne sont que la partie visible. Voici les plus grosses applications parmi les 126 retirées entre le 14 et le 18 octobre(ouvre dans un nouvel onglet), classées par nombre d'avis :

À lire avec prudence. Shopify n'a pas expliqué chaque retrait, et sa propre application Shopify Product Network figure dans la liste : un retrait n'est pas la preuve d'un piratage. Le point commun de la plupart de ces applications, c'est qu'elles exécutent du code sur la boutique : paniers latéraux, upsells, filtres, pop-ups, options produit. Et un retrait ne supprime que la fiche de l'App Store : une application déjà installée continue de tourner sur votre boutique tant que vous ne la désactivez pas.

Deux précautions avec ce tableau. D'abord, il ne liste que les applications citées publiquement ; l'attaquant a réutilisé la même méthode chez plusieurs éditeurs, une autre peut suivre. Ensuite, une boutique sur le forum Shopify(ouvre dans un nouvel onglet) a été touchée le 13 octobre sans aucune application HulkApps installée : « je n'utilise pas Hulk » ne dispense pas du test.

Ce que disent les éditeurs, d'après les déclarations rassemblées par Roman Zipp(ouvre dans un nouvel onglet) :

• HulkApps parle d'une faille ayant introduit des configurations non autorisées : « an exploit introduced unauthorized configurations into Hulk Product Options ». Aucune autre application Hulk n'est touchée, et l'entreprise a fait appel à un cabinet de sécurité externe.
• Logbase (Selleasy) décrit « a deliberate, planned cyber attack », une attaque délibérée et planifiée : un tiers a obtenu l'accès à un outil interne de Selleasy. Le réglage Custom JS est désormais verrouillé.
• Swym évoque « an unauthorized change to the app's configuration » et précise que l'application ne collecte, ne traite ni ne stocke aucune donnée de carte.

Le scénario n'est pas nouveau. Qikify(ouvre dans un nouvel onglet) a signalé une injection similaire en juillet, qu'il attribue à un identifiant compromis, « most likely leaked from outside their own systems » (probablement fuité hors de ses propres systèmes).

Le paiement sécurisé Shopify est-il fiable ?

Oui, le checkout lui-même l'est. Shopify se dit « certified Level 1 PCI DSS compliant »(ouvre dans un nouvel onglet), soit le plus haut niveau de la norme des cartes bancaires, et depuis 2017 la page de paiement tourne sur le domaine de votre boutique(ouvre dans un nouvel onglet) ou sur myshopify.com. Les extensions d'interface du checkout(ouvre dans un nouvel onglet) s'exécutent dans un bac à sable isolé et ne peuvent pas lire les champs de carte.

Le point faible, c'est tout ce qui précède le paiement : le thème et les applications qui y injectent des scripts. Une extension d'application de thème peut ajouter du code dans le head ou le body de chaque page de la boutique. C'est ainsi que fonctionnent les bundles, les wishlists et les options produit, et c'est aussi ainsi qu'a fonctionné cette attaque.

Le PCI Security Standards Council l'avait anticipé : « Scripts running in consumers' browsers are now a significant target for attackers. »(ouvre dans un nouvel onglet) La norme PCI DSS 4.0 a rendu obligatoires, depuis le 31 mars 2025, l'inventaire des scripts (exigence 6.4.3) et la détection des modifications sur les pages de paiement (11.6.1).

La bonne question n'est donc pas « la page de paiement Shopify est-elle sécurisée ? » mais « chaque clic sur le bouton de paiement de ma boutique arrive-t-il bien sur le checkout Shopify ? »

Comment vérifier si votre boutique est touchée

1. Ouvrez votre boutique dans une nouvelle fenêtre de navigation privée. Elle doit être neuve, car la redirection ne se déclenche qu'une fois par session.
2. Ajoutez un produit au panier et cliquez sur le bouton Passer la commande classique, pas sur Shop Pay ni sur un bouton de paiement express.
3. Regardez la barre d'adresse. Vous devez voir votre propre domaine ou checkout.shopify.com. Un domaine en .top, ou tout autre domaine inconnu, signifie que votre boutique est touchée.
4. Fermez la fenêtre et recommencez depuis le panier latéral, depuis la page panier, puis sur un téléphone en 4G/5G.
5. Ouvrez les outils de développement avant de cliquer. Dans Application > Session storage, cherchez des clés commençant par `__ctf_`. Dans l'onglet Network, filtrez sur `.top`.
6. Comparez vos applications installées à la liste des applications retirées(ouvre dans un nouvel onglet). Pour chaque correspondance, refaites le test et demandez par écrit à l'éditeur si sa configuration a été modifiée.

Regardez ensuite les signaux dont vous disposez déjà : e-mails de clients au sujet d'une page de paiement étrange, signalements de fraude à la carte après un achat, et entrées bizarres dans vos paniers abandonnés(ouvre dans un nouvel onglet).

Que faire si votre boutique a été touchée

1. Conservez les preuves avant de modifier quoi que ce soit : captures d'écran, URL de la fausse page, export HAR depuis les outils de développement, et une copie de votre thème en ligne.
2. Coupez le script. Désactivez l'intégration de l'application dans l'éditeur de thème (voir intégrations d'applications(ouvre dans un nouvel onglet)) ou désinstallez l'application(ouvre dans un nouvel onglet). Vérifiez les fichiers du thème pour repérer le code laissé par l'application.
3. Obtenez la version de l'éditeur par écrit : ce qui a été injecté, quand, et ce qu'il a changé.
4. Contactez le support Shopify et votre prestataire de paiement. Le prestataire peut surveiller les cartes utilisées pendant la fenêtre d'incident.
5. Verrouillez les accès. Changez les mots de passe, activez la validation en deux étapes(ouvre dans un nouvel onglet) pour chaque compte employé, et passez en revue les comptes collaborateurs(ouvre dans un nouvel onglet) et les outils d'IA qui ont accès à votre boutique.
6. Signalez le domaine à Google Safe Browsing(ouvre dans un nouvel onglet), à URLhaus(ouvre dans un nouvel onglet) et, en France, à Cybermalveillance.gouv.fr(ouvre dans un nouvel onglet).
7. Demandez à un avocat si vous devez prévenir vos clients et la CNIL. Cela dépend de votre situation et de celle de vos clients.

Comment protéger votre boutique de la prochaine attaque

• Passez en revue chaque réglage « custom JS » ou « custom HTML » de vos applications. C'est la porte par laquelle cette attaque est entrée. Si vous ne l'utilisez pas, demandez à l'éditeur s'il peut la désactiver.
• Moins d'applications, moins de portes. Chaque application qui injecte du code sur la boutique est un fournisseur qui a la main sur votre bouton de paiement. Désinstallez celles que vous n'utilisez plus et supprimez leur code résiduel.
• Faites du test de paiement une habitude : après chaque installation ou mise à jour d'application, et une fois par semaine en haute saison.
• Tenez un inventaire des scripts chargés sur votre boutique et de leur propriétaire. C'est ce que demande PCI 6.4.3, et un outil de surveillance des scripts couvre 11.6.1.
• Préférez les applications qui travaillent dans les surfaces de Shopify (extensions du checkout, Shopify Functions) plutôt que celles qui réécrivent votre boutique avec du code distant.
• Lisez la page sécurité de l'éditeur avant d'installer. Un éditeur qui publie ses incidents, comme l'a fait Qikify, inspire plus confiance qu'un éditeur qui se tait.

Questions fréquentes