WordPress, npm : quand l'uniformisation du web transforme une faille en menace de masse

Le 17 juillet 2026, la fondation WordPress publiait un correctif d'urgence pour une faille surnommée wp2shell. Le 4 août, un ver se propageait sur l'écosystème npm via un paquet que presque personne n'installe volontairement. Deux incidents sans rapport technique, à trois semaines d'intervalle, qui racontent pourtant exactement la même chose.

Aucun des deux ne vient d'une erreur de configuration ni d'un développeur négligent. Les deux viennent du fait que le même code tourne aujourd'hui partout, chez tout le monde, en même temps.

Autant poser le cadre tout de suite : une sécurité à 100 % n'existe pas. La question n'est pas de savoir si votre site sera un jour concerné par une vulnérabilité. Il le sera. La question est de savoir quelle part de votre exposition vous avez réellement choisie, et qui s'en occupe le jour où ça arrive.

Cet article décortique la mécanique précise de ces deux incidents, ce qu'ils révèlent sur le coût réel de l'uniformisation technique, et ce qu'un dirigeant peut en tirer avant de lancer son prochain projet.

wp2shell : une faille dans le cœur de WordPress, pas dans un plugin

wp2shell désigne une chaîne de vulnérabilités corrigée en urgence dans le cœur de WordPress le 17 juillet 2026. Elle combine une confusion de route sur l'endpoint REST /wp-json/batch/v1 et une injection SQL, et permet l'exécution de code à distance sans aucune authentification.

Ce point mérite d'être répété, parce que c'est ce qui rend l'incident inhabituel : aucun plugin n'était nécessaire, aucun thème particulier, aucun compte utilisateur. Une installation par défaut exposée sur internet suffisait. Les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1 étaient concernées, corrigées respectivement en 6.8.6, 6.9.5 et 7.0.2.

Selon Wordfence, il s'agit de la première faille critique de ce type dans le core depuis près de dix ans. Le mécanisme d'API concerné, lui, était en place depuis WordPress 5.6, publié en 2020.

Six ans. Dans ce qui est probablement la base de code PHP la plus déployée et la plus lue au monde. Et personne ne l'avait vue.

La manière dont elle a fini par être trouvée est le vrai signal de cet incident. Le chercheur Adam Kues, d'Assetnote, a pointé un modèle d'IA sur une copie propre du core, sans accès aux changelogs ni à l'historique du dépôt. Le modèle a identifié l'injection SQL, puis reconstruit la chaîne d'exploitation complète. Environ dix heures de calcul, pour un coût d'à peu près 25 dollars.

Le coût de découverte d'une faille dormante vient de s'effondrer. Ce qui demandait une équipe de chercheurs et des semaines de travail tient désormais dans le budget café d'une PME. Ce n'est pas une critique de WordPress : c'est vrai pour toutes les bases de code partagées, et le phénomène ne fait que commencer. Un mécanisme comparable se retrouve d'ailleurs dans l'utilisation détournée d'outils IA à des fins d'attaque, où des agents autonomes deviennent des vecteurs offensifs.

Le corollaire est simple : plus une base de code est partagée, plus le rendement d'une recherche de faille est élevé. Une même vulnérabilité ne concerne pas un site, elle en concerne des centaines de millions.

keyv : quand l'exposition s'hérite au lieu de se choisir

Le second incident illustre la même logique sous un angle inversé. Le 4 août 2026, le compte GitHub du mainteneur des paquets keyv et cacheable a été compromis. Du code malveillant a été poussé sur la branche principale, puis une nouvelle version a été publiée dans la foulée.

Le détail qui compte : les archives publiées sur npm portaient une provenance cryptographique parfaitement valide, signée par GitHub Actions. Toutes les vérifications automatiques passaient. Le système attestait correctement l'origine d'un build dont la source était déjà corrompue.

Le code malveillant s'exécutait via un script preinstall, c'est à dire avant même que le projet du développeur ne soit compilé. Il téléchargeait un runtime alternatif, puis collectait les jetons d'accès trouvés sur la machine ou le serveur d'intégration : npm, GitHub, fournisseurs cloud, coffres à secrets. Avec ces jetons, il se propageait seul vers les paquets suivants. D'où le terme de ver.

Maintenant, la partie qui concerne directement une PME. Voici une chaîne de dépendances typique :

eslint → file-entry-cache → flat-cache → keyv

Un développeur installe un outil de vérification de code, parce que c'est une bonne pratique. Trois niveaux plus bas, un paquet de stockage clé-valeur arrive avec, sans avoir jamais été demandé. Personne n'a choisi keyv. Personne ne connaît son mainteneur. Personne n'a lu son code.

Ce type d'incident porte un nom : attaque de la chaîne d'approvisionnement logicielle. Il ne s'agit pas d'exploiter une erreur de programmation, mais de compromettre un maillon de confiance dans un écosystème où la confiance est implicite et transitive.

Un dernier élément mérite l'attention, parce qu'il est nouveau. L'attaquant avait également ajouté au dépôt des fichiers de configuration destinés aux éditeurs de code et aux assistants IA. Ouvrir simplement le projet dans son environnement de développement pouvait suffire à déclencher le code. La surface d'attaque inclut désormais l'outillage lui-même.

Fait révélateur : selon les sources, le nombre de paquets touchés varie de 79 à plus de 800. Cette incapacité collective à seulement compter l'étendue de l'incident est en soi le meilleur résumé du problème.

Le vrai problème : l'uniformisation crée une surface d'attaque partagée

WordPress propulse environ 43 % des sites web dans le monde. npm héberge plus de 2 millions de paquets. Ces chiffres sont habituellement présentés comme des preuves de succès. Ils sont aussi la mesure exacte du risque partagé.

Il faut ici faire une distinction que beaucoup d'articles négligent. Le web est standardisé, et c'est une excellente chose : HTTP, TLS, HTML sont des normes ouvertes qui permettent à des implémentations différentes de fonctionner ensemble. Standardiser l'écartement des rails permet à dix constructeurs de faire circuler leurs trains sur le même réseau.

Ce qui s'est passé depuis quinze ans est autre chose. On n'a pas seulement standardisé l'écartement : on a décidé que tout le monde achèterait le même train, sorti de la même usine. C'est de l'uniformisation, et elle produit trois effets bien identifiés.

Le rendement de l'attaque. Les attaquants ne ciblent pas votre site. Ils écrivent une requête générique et l'envoient à des centaines de millions d'adresses qui répondent toutes de la même façon. Une faille dans un composant présent sur 500 000 sites ne crée pas 500 000 problèmes individuels : elle crée un seul problème industriel, exploitable par script.

La concentration de la confiance. Un dépôt, un compte de mainteneur, une clé de signature. Le cas keyv montre qu'un seul accès compromis suffit à contaminer une portion entière de l'écosystème, sans qu'aucun mécanisme de vérification ne se déclenche.

L'exposition héritée. C'est le point le plus difficile à percevoir pour un dirigeant. Vous n'avez pas choisi la majorité de ce qui s'exécute sur votre site. Vous avez choisi un CMS, ou un framework, ou un prestataire. Le reste est arrivé avec.

À ces trois effets s'ajoute une croyance qui ne tient plus. On a longtemps admis qu'un composant très utilisé était un composant très relu. C'était la promesse de l'open source, formulée en 1997 par Eric Raymond : « avec suffisamment d'yeux, tous les bugs sont superficiels ». Six ans d'existence pour l'endpoint de wp2shell suffisent à en montrer la limite. Le nombre d'utilisateurs n'a jamais eu de corrélation avec le nombre d'auditeurs. On a confondu diffusion et relecture.

J'ai détaillé ailleurs les coûts réels d'un WordPress en 2026, et il faut être clair : le sujet ici n'est pas la qualité de WordPress, qui est un projet sérieux et bien tenu. Le sujet est l'échelle. À 43 % du web, n'importe quel logiciel devient une infrastructure critique, avec les propriétés d'une infrastructure critique.

Réduire son exposition : ce qui marche, et ce qui ne suffit pas

La réponse n'est pas de fuir WordPress ou npm. Ces outils sont légitimes, et leurs alternatives ont exactement les mêmes propriétés dès qu'elles atteignent la même échelle. La réponse est de réduire la part de ce qui s'exécute chez vous sans que vous l'ayez décidé.

Suivez le nombre d'extensions installées comme un indicateur dans le temps : chaque extension est un éditeur supplémentaire dont vous dépendez sans le connaître, et désactiver ne suffit pas, il faut désinstaller. Enfin, disposez d'une sauvegarde dont la restauration a déjà été testée au moins une fois. Sans ce test, ce n'est pas une sauvegarde, c'est une croyance.

Si votre site ou votre application repose sur un développement moderne. Le fichier de verrouillage des versions doit être versionné et relu en revue de code, pas seulement présent. Les scripts d'installation automatiques doivent être désactivés sur les serveurs d'intégration, puisque c'est précisément le vecteur utilisé par le ver npm. Un délai volontaire de quelques jours avant d'adopter une version fraîchement publiée laisse le temps aux chercheurs de faire leur travail. Et le nombre de dépendances transitives d'une bibliothèque devrait peser dans le choix de cette bibliothèque, au même titre que ses fonctionnalités.

Dans tous les cas. Vous devez pouvoir répondre à trois questions : qu'est-ce qui fait tourner mon site, en quelle version, et qui le surveille. La majorité des dirigeants de TPE et PME ne le peuvent pas. Ce n'est pas une lacune technique, c'est une question de propriété.

Ces mesures fonctionnent. Elles ont toutes un point commun : elles travaillent à l'intérieur d'un périmètre décidé ailleurs.

Ce que ces incidents changent au moment de décider

Un audit vous dit ce que vous avez. Il ne change pas ce que vous avez. On peut réduire le nombre d'extensions, verrouiller les versions, surveiller les fichiers, et il faut le faire. Mais la seule fenêtre où votre surface d'exposition se décide vraiment, c'est au moment où le site est conçu. Après, on ne fait plus que la gérer.

C'est pour cette raison que la conversation la plus utile n'a pas lieu après un incident, mais avant le premier commit. Le périmètre technique choisi au départ engage le niveau de risque sur toute la durée de vie du projet, et il est bien plus coûteux à corriger ensuite qu'à cadrer au début.

Pour une vitrine simple ou un site associatif, un CMS correctement maintenu reste un choix raisonnable et je le dis sans réserve. Le développement sur mesure prend son sens ailleurs : quand l'outil numérique est au centre de l'activité, quand les données manipulées sont sensibles, ou quand la surface d'attaque standard d'une solution généraliste est disproportionnée par rapport au bénéfice réel. Il ne rend pas invulnérable, et ce serait malhonnête de le prétendre. Il fait autre chose : il réduit la part de votre site qui est identique à des centaines de milliers d'autres, et il désigne quelqu'un pour s'en occuper.

Trois questions méritent d'être posées avant de lancer un projet, plutôt qu'après :

• Combien de composants tiers ce site va-t-il embarquer, et lesquels sont réellement indispensables au besoin exprimé ?
• Qu'est-ce qui sera écrit spécifiquement pour moi, et qu'est-ce qui sera assemblé à partir de briques partagées avec des centaines de milliers d'autres sites ?
• Qui applique un correctif critique après la livraison, sous quel délai, et comment je sais qu'il a été appliqué ?

Si ces questions restent sans réponse claire, le projet porte un risque invisible qui finira par se matérialiser.

La sécurité n'est pas un état, c'est un processus continu. Et dans un web de plus en plus uniforme, la différenciation technique n'est pas un luxe esthétique. C'est une décision de conception, prise une fois, qui produit ses effets pendant des années.

Votre stack technique actuelle est-elle un choix assumé, ou un héritage que personne n'a jamais remis en question ?

Sources : Wordfence - wp2shell Aftermath: The First Critical Unauthenticated WordPress Core RCE in Nearly a Decade Datadog Security Labs - npm Worm Compromises Popular npm Packages