Les failles logicielles sont découvertes plus vite que jamais, et les attaquants les exploitent plus vite aussi. En 2025, le programme CVE a publié 48 185 fiches de vulnérabilité, soit 20,6 % de plus que l'année précédente, selon une analyse des données NVD et de la liste CVE. Mandiant, filiale de Google, mesure le délai moyen d'exploitation d'une vulnérabilité, compté à partir de la sortie de son correctif : il est passé de 63 jours en 2018 et 2019 à cinq jours en 2023 (Mandiant).
Les failles de sécurité e-commerce sont des défauts dans les logiciels qui font tourner une boutique, de la plateforme et ses plugins jusqu'à PHP et la base de données, qui permettent à un attaquant de voler des données de carte ou de clients, de prendre le contrôle de l'administration ou de modifier des commandes et des prix. La réponse pratique tient en peu de mots : savoir exactement ce que ta boutique fait tourner, y compris chaque plugin et sa version, être prévenu en quelques heures et non en quelques semaines des problèmes qui touchent ces versions, et avoir une routine pour appliquer le correctif. Cet article présente les types de vulnérabilités qui frappent les boutiques, pourquoi le rythme s'accélère, où se situe le risque et comment mettre en place cette routine sans équipe sécurité.
Failles de sécurité e-commerce : les sept points faibles que visent les attaquants
Le Top 10 OWASP classe les risques les plus critiques pour les applications web, avec le contrôle d'accès défaillant en tête de l'édition 2025. Dans une boutique en ligne, ces risques prennent généralement sept formes :
- Vulnérabilités connues non corrigées : une faille publiée dans la plateforme, un plugin, un thème ou PHP, que la boutique n'a jamais mise à jour. Les attaquants les recherchent automatiquement.
- Skimming au checkout : du JavaScript injecté sur la page de paiement copie les données de carte pendant que le client les saisit. Il entre généralement par l'une des autres failles de cette liste.
- Contrôle d'accès défaillant : un endpoint de plugin qui permet à n'importe qui, ou à un compte aux droits limités, de lire les commandes, de modifier des réglages ou de créer un utilisateur administrateur.
- Injection : une saisie de formulaire ou d'URL qui atteint la base de données ou le serveur sous forme de code (l'injection SQL est le cas classique), souvent utilisée pour copier les tables clients.
- Cross-site scripting (XSS) : un script enregistré dans un avis, une note de commande ou un réglage de plugin, qui s'exécute dans le navigateur d'un administrateur et peut prendre le contrôle de sa session.
- Connexions admin faibles : mots de passe réutilisés, pas d'authentification à deux facteurs et comptes d'agence partagés, que les attaques par credential stuffing testent à grande échelle.
- Failles de logique métier : codes promo cumulés, quantités négatives ou prix modifié dans la requête du panier, pour qu'une personne paie moins que le vrai prix.
Un propriétaire de boutique ne peut pas tester la plupart de ces failles seul : c'est le travail d'un développeur ou d'un pentesteur. Le premier point est différent. Savoir ce qui tourne sur ta boutique et le garder à jour, c'est à la portée de chaque propriétaire, et un plugin vulnérable est souvent la porte d'entrée des autres types de failles. La suite de cet article se concentre là-dessus.
Les chiffres derrière l'accélération des vulnérabilités
Trois sources, qui mesurent de façons différentes, vont dans le même sens. Chaque année, davantage de vulnérabilités sont publiées, davantage sont exploitées avant ou peu après l'existence d'un correctif, et l'écosystème WordPress, qui fait tourner de nombreuses boutiques WooCommerce, recense des milliers de nouveaux problèmes par an.
À quelle vitesse les vulnérabilités sont trouvées et exploitées
| Fiches CVE publiées par an | 39,962 (2024) | 48,185 (2025) | Analyse NVD et liste CVE |
|---|---|---|---|
| Délai moyen d'exploitation | 63 jours (2018 à 2019) | 5 jours (2023) | Mandiant |
| Nouvelles vulnérabilités dans l'écosystème WordPress | Non comparé | 11,334 (2025) | Patchstack |
| Vulnérabilités WordPress sans correctif lors de leur divulgation | Non comparé | 46% (2025) | Patchstack |
Mandiant précise que ses chiffres sont prudents, car il retient la date d'exploitation plausible la plus tardive quand la date réelle est inconnue. Il a aussi constaté que 97 des 138 vulnérabilités exploitées qu'il a suivies en 2023 ont été exploitées comme failles zero-day, avant qu'un correctif soit disponible.
Délai moyen d'exploitation, en jours
| Catégorie | Days |
|---|---|
| 2018 à 2019 | 63 jours |
| 2020 à début 2021 | 44 jours |
| 2021 à 2022 | 32 jours |
| 2023 | 5 jours |
L'AI change le rythme de découverte des failles
Une partie de cette hausse vient de meilleurs outils. Big Sleep, un agent AI de Google conçu par DeepMind et Project Zero, a signalé ses 20 premières vulnérabilités dans des logiciels open source en 2025, surtout dans la bibliothèque multimédia FFmpeg et dans ImageMagick. L'agent a trouvé et reproduit chacune d'elles, et un expert humain les a vérifiées avant leur signalement (TechCrunch). ImageMagick est le genre de bibliothèque qui redimensionne les images produit sur de nombreux serveurs web.
En mars 2026, Mozilla a expliqué comment la Frontier Red Team d'Anthropic a utilisé son modèle Claude pour chercher des bugs de sécurité dans Firefox. Ce travail a mis au jour 14 bugs de gravité élevée et donné lieu à 22 CVE, tous corrigés depuis (Mozilla). Mozilla s'attend à « un stock important de bugs désormais détectables » dans les logiciels largement déployés.
C'est une bonne nouvelle. Chaque faille trouvée par un chercheur peut être corrigée avant que des criminels la découvrent. Mais cela signifie aussi des mises à jour de sécurité plus nombreuses et plus fréquentes pour les plateformes et plugins dont dépend une boutique, et un propriétaire qui fait ses mises à jour une fois par trimestre prend un peu plus de retard chaque mois.
Pourquoi l'écart entre un correctif et une attaque ne cesse de se réduire
Dès qu'un correctif est publié, les attaquants peuvent comparer l'ancien et le nouveau code pour repérer ce qui était vulnérable, puis scanner Internet à la recherche de sites qui tournent encore sur l'ancienne version. Pour WordPress, Patchstack indique qu'environ la moitié des vulnérabilités à fort impact de 2025 ont été exploitées en moins de 24 heures, avec un délai médian pondéré de cinq heures avant la première exploitation (Patchstack).
Le catalogue Known Exploited Vulnerabilities de la CISA est le signal le plus clair qu'un problème n'est plus théorique : la CISA y recense les vulnérabilités dont l'exploitation réelle est avérée et conseille aux organisations de s'en servir pour fixer leurs priorités. Quand une vulnérabilité de ta stack y apparaît, elle mérite ton attention le jour même.
Plugins et thèmes concentrent l'essentiel du risque sur WordPress et WooCommerce
Une boutique WooCommerce, c'est WordPress plus une pile de plugins : paiement, livraison, SEO, page builders, formulaires et cache. Patchstack a recensé 11 334 nouvelles vulnérabilités dans l'écosystème WordPress en 2025, soit 42 % de plus qu'en 2024. Parmi elles, 91 % concernaient des plugins et 9 % des thèmes, tandis que le cœur de WordPress en comptait six (Patchstack).
Deux détails comptent pour les propriétaires de boutique. D'abord, 46 % de ces vulnérabilités n'avaient aucun correctif du développeur au moment de leur divulgation : mettre à jour ne suffit donc pas toujours, et la bonne décision consiste parfois à désactiver ou remplacer un plugin jusqu'à la sortie d'un correctif. Ensuite, les noms de plugins ne sont pas uniques. Beaucoup de plugins ont des noms commerciaux similaires, si bien que le seul identifiant fiable est le slug du plugin sur wordpress.org, comme elementor ou contact-form-7, associé à la version exacte installée.
Ce que CosmicSting a montré aux boutiques Magento et Adobe Commerce
En 2024, une vulnérabilité surnommée CosmicSting (CVE-2024-34102) a frappé les boutiques Adobe Commerce et Magento. Sansec a recensé 4 275 boutiques piratées, attaquées par sept groupes distincts, dans les mois qui ont suivi la publication de la vulnérabilité le 11 juin. Selon ses calculs, environ 5 % de toutes les boutiques Adobe Commerce et Magento se sont retrouvées avec un skimmer de paiement sur la page de checkout cet été-là (Sansec).
La leçon allait au-delà du correctif. Sansec a conseillé aux marchands de faire la mise à niveau, mais aussi de changer la clé de chiffrement secrète de la boutique et de retirer l'ancienne, de réinitialiser les mots de passe admin et de supprimer les intégrations API qu'ils ne reconnaissaient pas. Le correctif bouche le trou, mais un attaquant qui a déjà volé une clé peut continuer à s'en servir. Une bonne alerte te dit à la fois quoi mettre à jour et quoi nettoyer.
Les anciennes versions logicielles restent sur la liste pendant des années
Une vulnérabilité n'expire pas. Une fois publiée, elle reste pertinente pour chaque boutique qui tourne encore sur une version concernée, et les anciennes versions accumulent toutes les failles trouvées depuis leur sortie. Une boutique qu'on n'a pas touchée depuis trois ans peut être exposée à des problèmes corrigés, documentés et activement recherchés par les scanners depuis longtemps.
La fin de vie aggrave la situation. Quand un projet cesse de maintenir une version, les nouvelles failles qu'on y trouve ne sont plus corrigées du tout. PHP en est un bon exemple pour les boutiques WooCommerce et Magento : selon le projet PHP, PHP 8.1 et les versions antérieures ne reçoivent plus de correctifs de sécurité, et le support de sécurité de PHP 8.2 prend fin le 31 décembre 2026. Un serveur sous PHP 8.1 fait tourner du code qui restera vulnérable à tout ce qui sera découvert désormais, quels que soient les plugins que tu mets à jour.
La liste de ce que tu fais tourner doit donc aussi inclure les couches ennuyeuses : la version de PHP, la base de données et le logiciel serveur, pas seulement la plateforme de la boutique. Beaucoup de propriétaires ne connaissent pas ces numéros de version, parce que l'hébergeur les a configurés il y a des années. Ça vaut la peine de poser la question une fois à ton hébergeur et de noter les réponses.
Une routine hebdomadaire pour ne pas prendre de retard sur les mises à jour de sécurité
Tu n'as pas besoin d'une équipe sécurité pour rester à jour, mais il te faut une routine et une liste complète. Voici une routine qu'une petite équipe e-commerce peut suivre en moins d'une heure par semaine, avec un développeur ou un partenaire d'hébergement pour les mises à jour elles-mêmes. Si une agence ou un freelance gère la boutique, décide avec ce partenaire qui est responsable de chaque étape, car une routine qui n'appartient à personne s'arrête au bout de deux semaines.
Routine de sécurité hebdomadaire pour ta boutique
Ce que doit te dire une alerte de sécurité utile
La plupart des fiches de vulnérabilité sont écrites pour des chercheurs en sécurité. Une alerte qui aide un propriétaire de boutique à agir doit répondre à quelques questions simples, dans cet ordre :
- Est-ce que cela touche la version que j'utilise, ou seulement des versions que je n'utilise pas ?
- Est-ce que quelqu'un l'exploite en ce moment, par exemple parce qu'elle figure dans le catalogue de la CISA ?
- Qu'est-ce qu'un attaquant peut en faire : lire les données clients, prendre le contrôle de l'administration, ou quelque chose de moins grave ?
- Quelle version la corrige, et existe-t-il seulement un correctif ?
- Y a-t-il quelque chose à nettoyer après la mise à jour, comme des clés ou des mots de passe ?
Si une alerte ne peut pas répondre à la première question, c'est du bruit : tu finis par lire des alertes sur des failles dans des logiciels que tu n'utilises pas. C'est pourquoi les versions exactes comptent plus que tout le reste de la configuration.
Noter les versions exactes pour qu'une alerte puisse t'atteindre
Chaque rapport de vulnérabilité nomme un produit et une plage de versions concernées. Que tu sois concerné dépend entièrement de la version que tu utilises, donc une liste qui indique « WooCommerce » ou « dernière version » ne permet de rien confirmer. Note la version exacte, l'endroit où tu l'as lue et, pour les plugins, le slug wordpress.org. Voici où trouver chacune :
- WordPress, PHP et base de données : WooCommerce > État dans l'administration WordPress ouvre le rapport État du système, qui indique la version de WordPress, la version de PHP et la version de MySQL ou MariaDB.
- Plugins : la partie Extensions actives du même rapport, ou l'écran Extensions de WordPress, affiche la version de chaque plugin. Le slug est la dernière partie de l'adresse du plugin sur wordpress.org.
- Magento et Adobe Commerce : lance bin/magento --version sur le serveur, ou lis la version du paquet magento/product-community-edition dans composer.lock.
- Couche d'hébergement : le logiciel du serveur web et tout ce que les rapports ci-dessus n'affichent pas, tu les obtiens via ton panneau d'hébergement ou le support de ton hébergeur.
Si ta boutique est connectée à WISEPIM via WooCommerce, la connexion remonte WordPress, WooCommerce, PHP, la base de données et chaque plugin actif avec sa version, si bien que la liste reste à jour sans travail manuel. Pour Magento 2 et la plupart des autres plateformes, la connexion ne peut pas lire toutes les versions : tu enregistres donc toi-même la plateforme et sa version, et tu la mets à jour après une mise à niveau.
Comment Security watchtower veille sur ta boutique
Nous avons créé Security watchtower parce que la plupart des propriétaires de boutique n'ont personne pour lire les bulletins de sécurité chaque matin. Il tient une base de données de plus de 55 000 vulnérabilités connues dans les plateformes e-commerce, les plugins, les thèmes et les logiciels sous-jacents, remontant jusqu'à 1996, et vérifie les nouveaux signalements toutes les 15 minutes. Il les rapproche des versions enregistrées pour ta boutique et explique chacune en langage clair, en trois parties : ce que c'est, ce qui pourrait arriver et ce qu'il faut faire. Chaque vulnérabilité est étiquetée selon qu'elle touche ta version, qu'elle demande encore une vérification ou qu'elle est activement exploitée.
Une personne relit et valide chaque alerte avant son envoi par e-mail, pour que tu reçoives un avertissement clair plutôt que du bruit, et Security watchtower est inclus dans chaque offre, y compris l'offre gratuite présentée sur la page des tarifs. C'est un service d'alerte précoce, pas un test d'intrusion, ni une garantie que la boutique est sécurisée : ton développeur ou ton partenaire d'hébergement applique toujours le correctif. Pour le sujet plus large de la protection des données de ton catalogue, consulte l'entrée du dictionnaire sur la sécurité des données produit.
