Le détournement du checkout HulkApps : comment des apps Shopify de confiance sont devenues un entonnoir de phishing

En bref : le détournement du checkout HulkApps sur Shopify

• Ce qui s'est passé : à partir du 2026-10-10, les acheteurs de plusieurs boutiques Shopify qui cliquaient sur Checkout étaient envoyés vers une fausse page de paiement sur biliing[.]top, qui récupérait leurs données de carte puis les renvoyait vers le vrai checkout.
• Comment c'est entré : le fichier de l'app Hulk Product Options sur cdn.shopify.com était sain. Le code d'attaque revenait de l'API de configuration de HulkApps dans un champ JavaScript personnalisé et était injecté à l'exécution. Swym Wishlist Plus et Selleasy ont été touchées de la même façon.
• Pourquoi personne ne l'a vu : il ne se déclenchait que sur un vrai clic sur Checkout, une fois par session de navigateur, vers des domaines inconnus des listes de blocage. Les scanners, CSP et la plupart des tests manuels voyaient une boutique normale.

Peu de temps ? Découvrez la surveillance des scripts côté client de cside. Tout ce qui suit y est couvert en un seul déploiement.

Le 2026-10-10, le développeur Roman Zipp faisait des achats sur une boutique Shopify populaire. Il a ajouté un clavier à son panier, cliqué sur Checkout et atterri sur ce qui ressemblait à un checkout Shopify normal. Le seul indice : son gestionnaire de mots de passe lui proposait de remplir le champ « Prénom » avec le nom figurant sur sa carte bancaire. Il a regardé la barre d'adresse : biliing[.]top/check-out/.

La commande serait passée. Une fois les données de carte récupérées, la fausse page l'envoyait directement vers le véritable checkout de la boutique. La carte aurait été compromise, et rien dans les données de commande du marchand n'aurait semblé anormal.

Le code ne se trouvait pas dans le thème de la boutique, et le checkout de Shopify lui-même n'a jamais été touché. Il est arrivé via Hulk Product Options, une app de personnalisation de produits très installée éditée par HulkApps, sous la forme d'un bloc de « JavaScript personnalisé » renvoyé par l'API de l'éditeur. En quelques jours, des marchands qui n'avaient jamais installé de produit HulkApps signalaient le même faux checkout, remonté jusqu'aux apps d'autres éditeurs. C'est une attaque de la chaîne d'approvisionnement côté client dans sa forme la plus pure : un tiers que les marchands avaient légitimement autorisé dans les navigateurs de leurs clients est devenu le canal de diffusion.

Comment l'attaque fonctionnait

Chaque maillon de cette chaîne paraissait légitime pris isolément. Zipp l'a retracé étape par étape dans Chrome DevTools.

1. Un fichier de confiance se charge. Hulk Product Options fournit une extension de thème qui charge hulkcode.js sur les pages de la boutique. Le fichier est servi depuis cdn.shopify.com dans le paquet de l'extension. Il n'a pas été modifié.
2. Le fichier demande sa configuration. Au chargement de la page, hulkcode.js envoie une requête POST à productoption.hulkapps.com/api/v2/store/get_all_relationships avec l'identifiant de la boutique et le produit consulté.
3. La configuration contient du code. La réponse JSON comprend un champ advanced_users.custom_js, une fonction qui permet aux marchands d'ajouter leur propre JavaScript. Sur les boutiques touchées, il contenait environ 22,7 Ko de code d'attaque non minifié.
4. Le code est injecté à l'exécution. L'app écrit cette chaîne dans la page sous forme de script. Dans DevTools, il apparaît comme un script VM anonyme sans fichier source, ce qui le rend justement difficile à repérer.
5. Le clic sur Checkout est détourné. Le script enregistre un écouteur de clics. Quand l'acheteur clique sur Checkout, une fonction nommée littéralement hijack annule la vraie navigation et redirige vers un faux checkout sur un domaine de l'attaquant.
6. Le faux checkout récupère la carte. La page factice imite un checkout Shopify et demande les données de paiement et personnelles.
7. Les données partent. Le formulaire envoie tout vers /api/submissions sur le domaine de l'attaquant, qui répond avec un identifiant d'enregistrement.
8. L'acheteur est renvoyé. La fausse page renvoie l'acheteur vers le véritable checkout Shopify, où la commande se termine normalement. Le script enregistre aussi __ctf_shim_handoff_done_v1 dans le stockage de session pour ne jamais se déclencher deux fois dans la même session.

Les étapes 1 et 2 sont exactement ce que l'app fait sur toutes les boutiques, tous les jours. Toute l'attaque se trouvait dans les données renvoyées par l'API de l'éditeur.

Ces choix de conception sont délibérés. Ne rediriger qu'au clic sur Checkout rend les chargements de page passifs propres. Ne se déclencher qu'une fois par session fait que le marchand, l'éditeur de l'app et quiconque examine une plainte client voient en général un checkout normal en essayant de reproduire le problème. Et comme la commande volée se termine sur le vrai checkout, les tableaux de bord de revenus ne montrent rien d'inhabituel.

Ce n'était pas seulement HulkApps

HulkApps a été le premier nom associé à cette campagne, mais l'histoire ne s'arrête pas là. Plusieurs apps populaires de différents éditeurs ont diffusé la même redirection vers la même famille de domaines, et dans chaque cas la charge se trouvait dans des données de configuration que l'app récupérait sur les serveurs de son éditeur.

Il est tentant d'y voir la brèche d'un seul éditeur. Les éléments pointent vers quelque chose de plus inconfortable : quelqu'un qui passe systématiquement en revue les apps Shopify permettant à des données de configuration de devenir du code exécutable dans la boutique. On ne sait pas encore si cela passe par une faiblesse commune, des identifiants volés ou plusieurs intrusions distinctes. Au 2026-10-16, les fiches App Store de Hulk Product Options, Swym Wishlist Plus et Selleasy étaient indiquées comme indisponibles, et une marchande australienne a déclaré à iTnews que Shopify lui avait conseillé de garder sa boutique fermée.

Pourquoi l'attaque a échappé aux défenses habituelles

L'attaque n'était pas un code sophistiqué. C'était un placement sophistiqué. Presque tous les contrôles sur lesquels un marchand aurait pu compter regardaient la mauvaise couche.

• Le fichier du script n'a jamais changé. hulkcode.js arrivait de cdn.shopify.com avec le même contenu que d'habitude. Les vérifications d'empreinte et Subresource Integrity auraient réussi, car la partie malveillante arrivait sous forme de données, pas de fichier.
• Les origines étaient déjà de confiance. Le CDN et l'API de l'éditeur sont exactement les hôtes que la Content Security Policy d'une boutique autoriserait. Rien de nouveau n'apparaissait dans les listes de scripts ou de connexions. Autoriser ces hôtes ne suffit pas, à lui seul, pour qu'une boutique exécute une chaîne de code récupérée d'une API : un script-src strict sans 'unsafe-inline' ni 'unsafe-eval' l'aurait refusée. Mais les thèmes et les apps de boutique s'appuient beaucoup sur des scripts inline, si bien que peu de boutiques peuvent appliquer une politique aussi stricte.
• Le vol avait lieu hors du site. Le formulaire de carte se trouvait sur le domaine de l'attaquant, donc aucune donnée ne quittait la page de la boutique. CSP ne régit pas la navigation de premier niveau, et le connect-src de la boutique n'a jamais vu la requête d'exfiltration.
• Le déclencheur exigeait un vrai clic. Les scanners synthétiques qui parcourent les pages, voire chargent le panier, ne cliquent pas sur Checkout comme un acheteur. Pour eux, la charge restait inactive.
• Il s'exécutait une fois par session. Les tests manuels des marchands et des équipes support revenaient souvent propres, ce qui a retardé les signalements et fait passer les premières plaintes pour des cas isolés.
• Les listes de blocage ont été lentes. Le 2026-10-10, aucun des trois domaines trouvés par Zipp ne figurait sur Google Safe Browsing ni sur URLhaus, et ses bloqueurs de publicité et filtres DNS les ont laissés passer. Un message sur Reddit avait signalé le même domaine environ 18 jours plus tôt.
• Le checkout de Shopify allait bien. Le checkout de Shopify n'a jamais été compromis, et c'est tout l'enjeu. L'attaque s'exécutait sur la boutique, avant la page de paiement, là où les protections de la plateforme n'arrivent pas.

Le seul endroit fiable pour voir cette attaque est là où elle s'exécutait réellement : dans le navigateur d'un vrai acheteur, au moment où le script recâblait le bouton de checkout.

Indicateurs de compromission

Les domaines sont neutralisés. Ne les visitez pas.

Si vous trouvez une clé __ctf_ dans le stockage de session de votre boutique, considérez-la comme une détection confirmée de cette campagne.

Ce que les marchands doivent faire maintenant

Si vous exploitez une boutique Shopify avec des apps tierces, partez du principe que vous devez vérifier, même si vous n'avez jamais installé de produit HulkApps.

1. Testez le checkout dans une nouvelle session, plusieurs fois. Ouvrez une nouvelle fenêtre privée, ajoutez un produit, cliquez sur le bouton Checkout standard et surveillez la barre d'adresse. Fermez la fenêtre et recommencez. Faites-le aussi depuis le tiroir du panier et sur un téléphone. Votre checkout doit rester sur votre propre domaine ou votre adresse myshopify.com.
2. Cherchez le marqueur de session. Après un test, ouvrez DevTools, allez dans Application puis Session storage, et cherchez les clés commençant par __ctf_.
3. Auditez les paramètres d'apps qui acceptent du code. Toute app dotée d'un champ « JavaScript personnalisé » ou « HTML personnalisé » est un endroit où du code peut se cacher. Ouvrez chacun et vérifiez que vous reconnaissez tout ce qu'il contient.
4. Inventoriez vos app embeds. Dans l'éditeur de thème, listez chaque app embed activé. Désactivez et désinstallez ce dont vous ne vous servez pas activement, puis vérifiez le thème pour d'éventuels extraits résiduels.
5. Renouvelez vos identifiants. Changez votre mot de passe Shopify et celui du tableau de bord de chaque éditeur d'app, et activez l'authentification à deux facteurs partout où elle est proposée. Revoyez les accès des collaborateurs.
6. Si vous le trouvez, conservez d'abord les preuves. Faites une capture de la fausse page avec l'URL visible, enregistrez un fichier HAR depuis l'onglet Network et notez l'heure. Ensuite, désactivez l'app, contactez l'éditeur par écrit, ouvrez un dossier auprès du support Shopify et prévenez votre prestataire de paiement.
7. Faites-vous conseiller sur la notification. Des données de carte saisies sur une fausse page atteinte depuis votre boutique peuvent créer des obligations envers les clients ou les réseaux de cartes. Parlez-en à votre prestataire et à votre conseil juridique.

Une mise en garde des marchands touchés dans le fil de la Shopify Community : la confirmation par l'éditeur que le code a disparu n'a pas toujours suffi pour que Shopify autorise la réouverture d'une boutique. Gardez tout par écrit.

L'angle PCI DSS 4.0.1

Les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 existent précisément pour ce type d'attaque. La 6.4.3 demande aux marchands d'inventorier chaque script des pages de paiement, de justifier chacun et de confirmer qu'il est autorisé et intact. La 11.6.1 exige un mécanisme qui détecte les modifications non autorisées de ces pages telles que les reçoit le navigateur de l'acheteur. Les deux sont obligatoires depuis le 2025-03-31.

Beaucoup de marchands Shopify pensent que ces exigences relèvent de Shopify. Pour le checkout lui-même, c'est largement le cas, comme nous l'avons expliqué dans Shopify vous rend-il conforme PCI ?. Mais depuis janvier 2025, les marchands qui valident avec le SAQ A doivent confirmer que leur site n'est pas exposé aux attaques par scripts susceptibles d'affecter leurs systèmes e-commerce. Un script de boutique qui remplace silencieusement votre checkout par celui d'un autre en est l'exemple même. Vérifiez auprès de votre acquéreur quelles obligations s'appliquent à vous.

Cet incident montre aussi pourquoi un inventaire statique de scripts ne suffit pas à lui seul. L'inventaire aurait listé hulkcode.js, à juste titre, comme autorisé. C'est son comportement qui a changé : il a récupéré du nouveau code, l'a injecté, a attaché un gestionnaire de clic et envoyé l'acheteur vers un domaine jamais utilisé par la boutique. Le voir exige d'observer ce que font réellement les scripts dans de vraies sessions, pas seulement quels fichiers se chargent.

Comment cside aborde ce type d'attaque

De vraies sessions, pas des explorations synthétiques. cside surveille les scripts tiers dans de vraies sessions d'acheteurs plutôt que de s'appuyer sur une analyse périodique. Une charge qui ne se déclenche que sur un vrai clic sur Checkout, une fois par session, s'exécute quand même sous nos yeux.

Le comportement, pas seulement l'origine. Nous suivons ce que fait chaque script : le code qu'il injecte, les écouteurs qu'il attache, les données qu'il lit et où il les envoie. Un script d'app de confiance qui écrit soudain du nouveau code dans la page et envoie les acheteurs vers un domaine que votre boutique n'a jamais utilisé est un signal en soi, pas quelque chose de caché derrière un hôte autorisé.

Arrêté dans la session. Avec Script Method, cside récupère chaque script tiers côté serveur pour en calculer l'empreinte, l'archiver et l'analyser, et les blocages sont appliqués à l'exécution dans le navigateur, aux côtés de CSP. Un script non autorisé, ou une capacité précise qu'il tente d'utiliser, est arrêté dans la session au lieu d'être signalé après coup.

Aucun contrôle isolé n'aurait arrêté toutes les variantes de cette campagne. Mais la leçon est la même chez tous les éditeurs touchés : si du code tiers s'exécute dans les navigateurs de vos clients, il vous faut de la visibilité dans les navigateurs de vos clients. C'est la même leçon que l'attaque de la chaîne d'approvisionnement de Polymarket plus tôt cette année, par un autre éditeur et contre un autre type de victime.

Ce que nous ne savons pas encore

• Comment les attaquants sont entrés. HulkApps parle d'un exploit et Logbase d'un accès à un outil interne. Aucun n'a publié de cause racine.
• Si les incidents sont liés. Les domaines communs et les marqueurs __ctf_ identiques suggèrent le même opérateur, mais ni les éditeurs ni Shopify ne l'ont confirmé.
• Combien de boutiques et d'acheteurs ont été touchés. Shopify n'a publié aucun chiffre.

Nous mettrons cet article à jour à mesure que les éditeurs et Shopify publieront davantage d'informations. Le mérite de la découverte, de la rétro-ingénierie et de la chronologie publique revient à Roman Zipp.

Les informations ci-dessus reflètent les sources publiques et les déclarations des éditeurs au 2026-10-16.

Vous voulez voir ce qui s'exécute réellement dans les navigateurs de vos acheteurs ? Commencez gratuitement ou réservez une démo pour échanger avec notre équipe.