WP2Shell : ce que cette faille WordPress dit de la maintenance

🇬🇧 Read in English : WP2Shell: what this WordPress flaw says about maintenance

WP2Shell est une faille critique du cœur de WordPress, corrigée en urgence le vendredi 17 juillet 2026 dans les versions 6.9.5 et 7.0.2. Le problème n’est pas dans un plugin ni dans un thème : il est dans WordPress lui-même. Une installation nue, sans la moindre extension, suffit à être exposée — et WordPress fait tourner environ 43 % du web. La fondation a même déclenché des mises à jour automatiques forcées, mesure réservée aux failles les plus graves, tandis que les premiers codes de démonstration commencent à circuler. Mais si je prends la plume à chaud, ce n’est pas pour la faille elle-même. C’est pour ce qu’elle révèle : le vrai sujet n’a jamais été l’outil. C’est la maintenance.

  Attention

Cet article explique le risque et la protection, sans donner aucun mode opératoire d’attaque. Le but est de vous aider à mettre votre site en sécurité, pas d’outiller qui que ce soit.

Entre les deux cadenas, une seule différence : la mise à jour a été faite, ou pas. C'est tout l'enjeu de WP2Shell.

Ce qui vient de se passer  

WordPress a sorti un correctif d’urgence. Ça n’arrive pas tous les jours, et ça mérite qu’on s’arrête cinq minutes, même sans être technicien.

Des chercheurs en sécurité — Adam Kues, de l’équipe Assetnote (Searchlight Cyber) — ont trouvé un moyen de prendre la main sur un site WordPress à distance, sans compte, sans mot de passe, sans clic de votre part. Ils l’ont signalé à WordPress par la voie officielle, et la réaction a été rapide : correctifs publiés le vendredi 17 juillet, dans les versions 6.9.5 et 7.0.2. La branche plus ancienne 6.8.x a reçu son propre correctif en 6.8.6.

Techniquement, WP2Shell chaîne deux défauts distincts. Le premier (CVE-2026-63030) est une confusion de route dans l’API REST « batch » de WordPress, apparue avec la version 6.9. Le second (CVE-2026-60137) est une injection SQL logée dans le moteur de requêtes, présente depuis la 6.8. Séparément, ils sont déjà sérieux. Chaînés, ils ouvrent la porte à l’exécution de code à distance non authentifiée. Les versions saines sont 6.9.5, 7.0.2 et 6.8.6 ; les branches 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1 sont exposées à la chaîne complète.

Signe que WordPress prend la chose au sérieux : la fondation a déclenché des mises à jour automatiques forcées, une mesure qu’elle réserve aux failles les plus graves. Beaucoup de sites ont donc été rustinés tout seuls. Beaucoup — pas tous. J’y reviens.

WP2Shell : une faille du cœur, pas d’un plugin  

La fissure est dans la fondation, pas dans les pièces ajoutées : changer les plugins n'y change rien.

C’est le point à retenir, et il casse un réflexe très répandu.

On associe souvent les piratages WordPress à une extension gratuite mal codée, installée un soir puis oubliée. Ici, ce n’est pas ça. WP2Shell vise le cœur de WordPress — le logiciel lui-même, celui que tout le monde installe à l’identique. Ni votre thème ni vos extensions ne sont en cause. C’est la version de WordPress qui fait tourner votre site, et le seul fait qu’elle soit corrigée ou non.

  Astuce

« Mes plugins sont à jour, je suis tranquille » ne tient pas ici. La faille est dans le cœur de WordPress. Un site propre, minimal, sans fioritures, reste exposé s’il tourne sur une version touchée sans correctif. Ce qui compte, ce n’est pas la qualité de votre installation de départ, c’est sa mise à jour.

Ce déplacement du problème est important, parce qu’il change complètement la question qu’on doit se poser. Ce n’est plus « ai-je installé quelque chose de risqué ? », mais « qui s’assure que mon WordPress reste à jour, semaine après semaine ? ». Gardez cette question en tête : c’est le cœur de cet article.

La mise à jour forcée ne suffit pas  

La vague de correctifs verrouille les sites sur son passage — mais glisse sur ceux qui ont coupé l'auto-update.

La mise à jour automatique forcée déclenchée par WordPress a sauvé énormément de sites. Mais elle a un angle mort, et il est de taille.

Elle ne fonctionne que si l’auto-update est active. Or beaucoup d’hébergeurs et d’administrateurs la désactivent volontairement, pour garder la main sur les versions et éviter qu’une mise à jour ne casse un site en production. C’est un choix légitime — mais il a un revers : ces sites-là n’ont reçu aucun correctif automatique. Ils attendent une main humaine. Et cette main humaine, encore faut-il que quelqu’un ait pour mission de la lever.

Le tempo n’aide pas. Des premiers codes de démonstration partiels commencent à circuler publiquement. Les chercheurs ont volontairement gardé le dernier maillon vers la prise de contrôle complète pour laisser aux sites le temps de se mettre à jour — mais ça ne retiendra pas longtemps les plus motivés, et les scans automatisés qui cherchent les sites en retard démarrent déjà. Autrement dit, la fenêtre entre « le correctif existe » et « les robots passent » est en train de se refermer.

Le vrai sujet, c’est la maintenance — le paradoxe Wix  

Même logiciel des deux côtés : ce qui les sépare, c'est qu'un site est tenu à jour et l'autre laissé à l'abandon.

Voilà pourquoi j’écris cet article, et pourquoi il ne ressemblera pas aux autres.

WP2Shell n’est pas un accident de WordPress. C’est une démonstration. Une faille du cœur, sur un site propre, qui ne devient un danger que si personne ne met à jour : ça dit tout. Le problème n’est pas l’outil. C’est le mode d’exploitation. Et pour l’illustrer, il y a un contraste que nous mesurons chez Kimoun, et qui prend tout son sens aujourd’hui — je l’appelle le paradoxe Wix.

Wix, comme les autres plateformes no-code, a une mauvaise réputation chez les puristes : moins ouvert, moins souple, dépendant d’un tiers. Tout cela est vrai. Mais un site Wix se met à jour tout seul. Le chiffrement, les en-têtes de sécurité, les correctifs du moteur : c’est la plateforme qui les impose, sans que le propriétaire ait à y penser. Un WordPress auto-hébergé, lui, attend qu’un humain fasse le travail. Face à une faille comme WP2Shell, cette différence n’est pas théorique — c’est celle qui sépare un site déjà corrigé d’un site resté vulnérable tout un week-end.

C’est exactement ce que révèlent nos mesures. Nos données de secteur indiquent que WordPress équipe la moitié du web professionnel ultramarin — jusqu’à 64 % à La Réunion. Et notre prochaine étude de secteur montre que cette moitié affiche aussi la pire hygiène de sécurité du panel. La sécurité HTTP est l’axe le plus faible mesuré : un grade médian D, et près des deux tiers des sites classés D ou F. Les installations WordPress y tiennent le bas du tableau, avec un score de sécurité médian nettement inférieur à celui des sites no-code. Sur notre indice global, l’écart se retrouve : les WordPress mesurés tournent en moyenne autour de 58 sur 100, contre près de 64 pour les sites Wix du même panel. Et 87 % du secteur reste sous la barre des 70 sur 100.

  Remarque

Le paradoxe, en une phrase : la plateforme qu’on juge « fermée » protège mieux ses utilisateurs qu’un WordPress libre laissé sans maintenance. Non parce que le no-code serait supérieur, mais parce qu’il retire à l’humain une tâche que beaucoup n’assument pas. L’outil ne fait pas le niveau. La maintenance, si.

Nos mesures montrent aussi que dette technique et faiblesse de sécurité vont de pair : le site aux composants obsolètes est le même que celui aux en-têtes absents. C’est précisément le profil que WP2Shell vient faucher. Un site abandonné après sa mise en ligne accumule les deux à la fois — et le jour où une faille du cœur tombe, il est en première ligne.

Un mot sur ces chiffres, en toute transparence : ils sont agrégés, jamais nominatifs. Nous ne pointons personne du doigt. L’observatoire mesure un état du secteur, pas des coupables. Personne d’autre en Guadeloupe ne publie cette mesure locale — c’est notre rôle, et c’est aussi ce qui donne du poids à ce que j’écris ici : ce n’est pas une intuition, c’est un relevé.

Que faire maintenant  

Trois gestes, dans l'ordre : lire sa version, appliquer le correctif, puis garder un œil dessus.

Pas de panique, mais pas de délai non plus. Dans l’ordre :

1. Regardez votre version. Tableau de bord WordPress, en bas de page. Si vous voyez 6.9.5, 7.0.2 ou 6.8.6, la partie « correctif » est faite. Sinon, passez à l’étape suivante.
2. Mettez à jour. Passez en 6.9.5 ou 7.0.2 selon votre branche (6.8.6 si vous êtes resté sur la 6.8). C’est la seule vraie protection de fond.
3. Vérifiez que c’est bien appliqué, même avec l’auto-update. La mise à jour forcée n’atteint que les sites dont l’auto-update est active. Ne présumez pas : ouvrez le tableau de bord et lisez le numéro affiché.
4. Si vous ne pouvez pas mettre à jour tout de suite, une mesure d’attente existe : bloquer l’accès anonyme à l’endpoint « batch » de l’API REST, au niveau du pare-feu applicatif (WAF) ou d’un plugin de sécurité. Attention à un piège : cet endpoint répond sous deux formes, /wp-json/batch/v1 et ?rest_route=/batch/v1. N’en bloquer qu’une seule ne sert à rien. Cloudflare propose par ailleurs des règles prêtes à l’emploi pour les sites qui passent par son réseau.
5. Utilisez le testeur officiel. Les découvreurs ont mis en ligne un outil à l’adresse wp2shell.com qui indique si une installation est vulnérable. Préférez-le à un « scanner » trouvé au hasard : dans un moment comme celui-ci, les faux outils douteux se multiplient.

  Important

La mise à jour reste la priorité. Le blocage de l’endpoint est un rustinage temporaire pour tenir quelques heures — pas un substitut au correctif. Une fois à jour, on peut lever la mesure.

Et si tout cela vous paraît obscur, c’est normal : ce n’est pas votre métier. Une précision utile au passage — héberger un site et le tenir à jour sont deux choses différentes, et beaucoup de propriétaires croient à tort que leur hébergeur s’occupe du second. Chez Kimoun, nous pouvons vérifier rapidement l’état de votre site — version, correctif appliqué, exposition de l’endpoint — et vous dire noir sur blanc où vous en êtes. Une simple vérification, pas un devis.

WP2Shell rappelle une chose simple : un site n’est pas un objet qu’on installe puis qu’on oublie. L’observatoire mesure l’exposition du secteur ; l’expert corrige les sites, un par un. Mettre à jour aujourd’hui protège l’avenir — et le jour où la prochaine faille tombera, c’est la maintenance, pas l’outil, qui fera la différence. Nous revenons en détail sur les enseignements de cette faille — et sur ce qui sépare héberger un site de le tenir dans la durée — dans un article dédié à WP2Shell.