Côté sécurité Shopify, la faille PHP2Shell d'octobre 2026 ne touche pas votre boutique : Shopify ne tourne pas sur PHP et il n'y a rien à mettre à jour de votre côté. Le vrai risque du mois est ailleurs. Entre le 10 et le 20 octobre, des attaquants ont détourné au moins trois applications tierces pour envoyer des acheteurs vers de faux checkouts et voler leurs cartes bancaires, sans jamais toucher à la plateforme. La sécurité d'une boutique Shopify ne se joue donc plus sur le serveur, elle se joue dans la liste de vos apps. Article mis à jour le 28 octobre 2026.
En bref
- Faille PHP2Shell : deux failles critiques (notées 9,2 sur 10) dans PHP lui-même, corrigées le 21 octobre et désormais exploitées par des attaquants. Elles menacent tout serveur PHP non corrigé, donc les sites WordPress, WooCommerce, PrestaShop ou Magento qui n'ont pas été mis à jour.
- Votre boutique Shopify : non concernée. Le cœur de Shopify repose sur Ruby on Rails, le rendu sur Liquid, et Shopify gère seul ses serveurs.
- Ce qui reste à vérifier : vos applications tierces, vos connecteurs sur mesure et tout site annexe (blog WordPress, outil de réservation) qui peuvent, eux, tourner en PHP.
- Le vrai incident Shopify d'octobre : trois éditeurs (Hulk Product Options, Selleasy, Swym Wishlist Plus) ont confirmé qu'un tiers avait injecté via leur app un script de redirection vers un faux checkout.
- Le checkout Shopify a tenu : l'attaque s'exécutait sur la boutique, un clic avant le paiement.
- Notre position d'agence : chaque app installée est un prestataire qui a les clés de votre vitrine. Moins d'apps, plus de natif, et un test de checkout en navigation privée à chaque alerte.
Sommaire
Octobre 2026 : deux incidents, pas un seul
Deux histoires se sont télescopées la même semaine, et la plupart des alertes que vous avez lues les mélangent. D'un côté, une faille dans le langage PHP, qui fait tourner une grande partie du web. De l'autre, une campagne de piratage visant des applications Shopify. Elles n'ont ni la même cause, ni les mêmes victimes, ni les mêmes réponses. Les séparer est la première étape pour savoir ce que vous avez réellement à faire.
La faille PHP2Shell : un défaut dans le moteur, pas dans votre site
Le 21 octobre 2026, l'équipe PHP a publié en urgence des correctifs pour deux failles critiques, référencées CVE-2026-109618 et CVE-2026-109619 et surnommées PHP2Shell. Toutes deux sont notées 9,2 sur 10 et permettent à un attaquant d'exécuter du code sur un serveur sans identifiant ni mot de passe. Elles ont été mises au jour à la mi-août par des chercheurs de Calif et de Wiz, avec l'aide de modèles d'intelligence artificielle.
Le calendrier explique l'inquiétude. Les identifiants des failles ont fuité la veille du correctif, Amazon a repéré une première tentative d'exploitation dès le 17 octobre, soit quatre jours avant la publication, et l'agence américaine de cybersécurité (CISA) a ajouté PHP2Shell le 26 octobre à son catalogue des vulnérabilités activement exploitées, après des cas confirmés d'exécution de code.
Le point clé pour un e-commerçant : la faille se trouve dans PHP lui-même, pas dans WordPress, WooCommerce ou PrestaShop. Mettre à jour votre CMS ou vos modules ne corrige rien. Seule la mise à jour de PHP sur le serveur, en 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ferme la porte. Les versions 7.4, 8.0 et 8.1 n'ont reçu que des correctifs minimaux de code source, et les versions plus anciennes rien du tout.
Le détournement d'apps : un faux checkout un clic avant le vrai
Le 10 octobre, un développeur allemand, Roman Zipp, achète un clavier sur une boutique Shopify. Il clique sur « Paiement » et atterrit sur une page de paiement qui ressemble trait pour trait à un checkout Shopify, mais hébergée sur un domaine inconnu en .top. Il remonte la piste jusqu'à une application installée sur la boutique : Hulk Product Options.
Dans les jours qui suivent, trois éditeurs confirment un incident de leur côté :
- Hulk Product Options (HulkApps), le 10 octobre : une configuration non autorisée injectée dans l'extension de thème de l'app.
- Selleasy (Logbase), le 13 octobre : un tiers a accédé à un outil interne de l'éditeur et ajouté un script dans le réglage « Custom JS » de plusieurs boutiques.
- Swym Wishlist Plus, le 14 octobre, puis une seconde vague le 18 octobre qui utilisait les accès de l'app elle-même. Swym a suspendu son application pour tous les marchands, révoqué ses accès Shopify le 20 octobre, et rétablit le service par étapes depuis le 23 octobre.
Le mode opératoire est redoutable. La fausse page récupère le nom, l'adresse et la carte de l'acheteur, puis le renvoie vers le vrai checkout pour qu'il paie normalement. La commande aboutit, votre back-office ne montre rien d'anormal, votre taux de conversion non plus. Le script ne se déclenchait qu'une fois par session de navigation : un marchand qui testait deux fois son propre checkout voyait une page parfaitement propre la seconde fois.
« Chaque app installée est un prestataire qui a les clés de votre vitrine. La wishlist en est le meilleur exemple : sur une boutique à catalogue réduit, nous la déconseillons parce qu'elle apporte peu de ventes pour beaucoup de code chargé sur chaque page. En octobre, c'est précisément une app de wishlist qui a servi de porte d'entrée. »
Volkier Bentinck, co-fondateur de Stellar Projects
Shopify utilise-t-il PHP ?
Non, pas pour faire tourner votre boutique. Le cœur de Shopify est développé en Ruby on Rails, vos pages sont générées avec Liquid, le langage de templates de Shopify, et la plateforme héberge et met à jour elle-même ses serveurs. Il n'existe aucune version de PHP à corriger dans votre admin. Au 27 octobre, Shopify n'avait d'ailleurs publié aucune déclaration sur PHP2Shell, ce qui est cohérent : la plateforme n'a rien à corriger de ce côté.
La réponse complète est plus nuancée, parce que PHP n'a pas disparu de l'écosystème qui gravite autour de votre boutique. Shopify publie même depuis le 26 août 2026 un package officiel pour développer des applications en PHP, compatible Laravel et Symfony. Chaque éditeur d'app choisit sa technologie, et certains l'assument publiquement : Qikify a confirmé que ses apps tournent en PHP sur ses propres serveurs, et les a corrigées dans les jours qui ont suivi.
| Brique | Qui l'héberge et la met à jour | PHP possible ? | Qui agit en cas de faille |
|---|---|---|---|
| Boutique et checkout Shopify | Shopify | Non | Shopify, sans action de votre part |
| Applications de l'App Store | Chaque éditeur, sur ses serveurs | Oui, selon l'éditeur | L'éditeur, à qui vous pouvez demander confirmation |
| App ou connecteur sur mesure (ERP, logisticien, middleware) | Vous ou votre agence | Oui, fréquent | Vous ou votre agence |
| Site annexe (blog WordPress, page d'atterrissage, outil de réservation) | Votre hébergeur ou votre agence | Oui, très fréquent | Votre hébergeur ou votre agence |
Si vous avez gardé un blog WordPress à côté de votre boutique, c'est lui qu'il faut vérifier cette semaine, pas Shopify. Notre comparatif Shopify ou WordPress revient sur ce que chaque solution laisse à votre charge.
Sécurité Shopify : le vrai risque vient des apps
Ce qu'octobre a montré, c'est que la surface d'attaque d'une boutique Shopify s'est déplacée. Le serveur est bien gardé par Shopify. Les applications, elles, injectent du code sur chacune de vos pages, et ce code dépend de la sécurité de leur éditeur. C'est un constat que nous partageons avec nos clients depuis longtemps, pour des raisons de performance d'abord, de sécurité désormais.
Comment le code malveillant est entré
Les applications ajoutent du code sur votre boutique via les « app embeds », activés dans l'éditeur de thème. Ce code est servi depuis le CDN de Shopify, et dans le cas de HulkApps, le fichier lui-même n'avait pas changé d'un octet. La partie malveillante arrivait sous forme de données de configuration, chargées depuis les serveurs de l'éditeur à chaque affichage de page, puis exécutées dans le navigateur de l'acheteur.
Conséquence directe : une recherche dans les fichiers de votre thème n'aurait rien trouvé. Les audits de code « propres » de la mi-octobre ne prouvaient rien. Seul un test réel du parcours d'achat, dans une session de navigation neuve, permettait de voir la redirection.
Pourquoi le checkout a tenu, et pourquoi cela n'a pas suffi
Le checkout Shopify n'a jamais été compromis. Les extensions qui le personnalisent tournent dans un environnement isolé, sans accès à la page ni aux données de paiement. C'est une vraie protection, et c'est pour cela que les attaquants ne l'ont pas visé. Ils ont simplement intercepté le clic sur le bouton « Paiement », sur la boutique, avant que l'acheteur n'arrive dans cet espace protégé.
Retenez la nuance : Shopify sécurise le paiement, pas ce que vos apps font sur vos pages produit et votre panier. Cette zone-là relève de vos choix d'applications. Notre sélection des apps Shopify qui rapportent vraiment part de ce principe de sobriété.
Ce que Shopify a changé après les apps piratées
À notre connaissance, Shopify n'a publié ni liste des apps touchées ni de nombre de boutiques concernées. Un porte-parole a indiqué le 17 octobre que la plateforme pouvait retirer une app de l'App Store pour protéger les marchands. Mais la réaction s'est surtout lue dans ses notes de version.
- 15 octobre : nouvelle commande shopify app security check dans le CLI, qui permet aux développeurs d'analyser leur app à la recherche des failles les plus courantes.
- 20 octobre : Shopify demande à tous les développeurs d'apps d'agir « cette semaine » : analyse de sécurité, passage à des jetons d'accès qui expirent (bientôt obligatoires pour les apps publiques), double authentification partout, revue des journaux d'API. La plateforme annonce aussi un resserrement des règles pour le code que les apps chargent sur les boutiques.
- 20 puis 23 octobre : nouvelle protection contre les redirections inattendues. Depuis la mise à jour du 23 octobre, votre boutique bloque les liens vers les sites que Shopify a identifiés comme malveillants et demande une confirmation à l'acheteur pour les sites suspects. Les autres liens fonctionnent normalement, et les domaines connectés à votre boutique ne déclenchent pas de message.
Un point de vigilance sur les chiffres qui circulent : Revenue Shield, éditeur d'une solution de surveillance de checkout, a compté 478 apps retirées de l'App Store entre le 14 et le 22 octobre. Shopify n'a ni confirmé ce chiffre ni expliqué la plupart de ces retraits, et une app retirée n'est pas forcément une app piratée. À l'inverse, une app retirée continue de tourner sur les boutiques qui l'avaient déjà installée : le retrait ne vous protège pas automatiquement.
Shopify, PrestaShop, WooCommerce : qui corrige quoi ?
PHP2Shell a rendu visible une différence que l'on oublie quand tout va bien : sur une plateforme hébergée, la plateforme corrige ; sur une solution auto-hébergée, quelqu'un doit le faire, et vite. WooCommerce comme PrestaShop ont rappelé dès le 21 octobre qu'aucune mise à jour de leur logiciel ne corrigeait la faille.
| Plateforme | Qui met PHP à jour | Ce que PHP2Shell vous demandait |
|---|---|---|
| Shopify | Personne : pas de PHP à mettre à jour | Rien sur la boutique, vérifier les briques annexes |
| WooCommerce (WordPress) | Votre hébergeur ou votre agence | Obtenir la confirmation écrite de la version corrigée et du redémarrage des services |
| PrestaShop | Votre hébergeur ou votre agence | Idem, et monter de version si le site tourne encore en PHP 8.1 ou antérieur |
| Magento / Adobe Commerce | Votre hébergeur ou votre intégrateur | Idem, en vérifiant la compatibilité de la version de PHP avec votre version de Magento |
Pour être juste, PHP2Shell ne justifie pas à lui seul de changer de plateforme. Un hébergeur réactif a déployé le correctif dans les jours qui ont suivi. Mais une boutique PrestaShop restée en PHP 7.4 n'a reçu qu'un correctif minimal de code source, et la mise à niveau devient un chantier subi au lieu d'être planifié. Notre analyse PrestaShop ou Shopify chiffre ce coût de maintenance, et notre guide de migration vers Shopify détaille comment basculer sans perdre votre référencement.
Vérifier votre boutique en 30 minutes
Voici la vérification que nous recommandons aux boutiques que nous accompagnons. Elle ne demande aucune compétence technique pour les cinq premières étapes.
- Testez le parcours d'achat dans une session neuve. Ouvrez une fenêtre de navigation privée, sur mobile puis sur ordinateur, ajoutez un produit et cliquez sur « Paiement ». L'adresse doit rester sur votre domaine ou sur un domaine Shopify. Fermez la fenêtre entre deux tests : le script d'octobre ne se déclenchait qu'une fois par session.
- Listez vos app embeds, pas seulement vos apps. Dans l'éditeur de thème, ouvrez l'onglet des intégrations d'applications et notez tout ce qui est actif. C'est là que le code des apps entre sur vos pages.
- Désinstallez ce qui ne sert plus. Une app installée et oubliée reste une porte ouverte. Vérifiez aussi qu'aucun script ne subsiste après désinstallation.
- Relisez les autorisations de chaque app. Une app de wishlist n'a aucune raison de pouvoir modifier vos commandes ou vos fichiers de thème. Si les droits demandés dépassent l'usage, remplacez l'app.
- Auditez les comptes collaborateurs. Retirez les accès des anciens prestataires et activez la double authentification sur tous les comptes, y compris ceux de vos apps quand elles ont leur propre interface.
- Recensez vos briques en PHP. Blog, page d'atterrissage, connecteur ERP, outil de réservation : demandez par écrit à votre hébergeur ou à votre agence la version de PHP utilisée et la date du correctif PHP2Shell.
- Interrogez les éditeurs de vos apps critiques. Une question suffit : « Votre app tourne-t-elle en PHP, et le correctif PHP2Shell est-il appliqué ? » Un éditeur sérieux répond clairement et vite.
Si vous trouvez une redirection
Désactivez immédiatement l'app embed suspect dans l'éditeur de thème, prévenez le support Shopify et l'éditeur de l'app, puis faites le point avec votre prestataire de paiement et votre conseil sur vos obligations de notification, notamment auprès de la CNIL si des données personnelles ont pu être collectées. Côté support, notre article sur le support Shopify explique comment obtenir une réponse rapide.
Moins d'apps, plus de natif : notre position
Notre conviction ne date pas d'octobre, mais octobre lui donne un argument de plus. Avant d'installer une application, nous vérifions toujours si Shopify ne fait pas déjà le travail en natif. Bien souvent, un workflow Shopify Flow, des métaobjets ou une Shopify Function remplacent une app payante, sans ajouter une ligne de code tiers sur vos pages.
Même logique pour les sauvegardes : nous ne recommandons pas d'app de sauvegarde sur Shopify. La plateforme gère la disponibilité de vos données, et quand un export complet est utile, Matrixify le fait ponctuellement, sans accès permanent à votre boutique.
Concrètement, trois règles guident nos recommandations :
- Le natif d'abord. Une fonction Shopify ne dépend que de la sécurité de Shopify.
- Une app, un usage mesuré. Si personne ne sait dire ce qu'une app rapporte, elle doit partir.
- Une revue annuelle du parc d'apps, au même titre qu'une revue de vos contrats fournisseurs : qui a accès à quoi, et pourquoi.
C'est aussi ce que couvre notre offre de maintenance Shopify : surveiller, alléger et tester, plutôt qu'empiler.
Faire le point sur votre boutique
Vous ne savez pas combien d'apps tournent réellement sur votre boutique, ni lesquelles ont accès à quoi ? C'est exactement le type d'audit que nous menons pour nos clients, avec une liste claire de ce qu'il faut garder, remplacer ou supprimer. Parlons de votre boutique, nous répondons sous 24 heures.
