WordPress : 72 heures entre le correctif et les premières attaques

🇬🇧 Read in English : WordPress: 72 hours between the patch and the first attacks

WP2Shell, c’est l’enchaînement de deux failles du cœur de WordPress qui laisse un inconnu prendre la main sur un site — sans compte, sans mot de passe, sans le moindre plugin tiers. L’équipe WordPress a publié le correctif en urgence, les versions 6.9.5 et 7.0.2, le vendredi 17 juillet 2026. Le lundi 20, l’exploitation réelle était constatée sur les pièges de plusieurs sociétés de sécurité, avec des portes dérobées installées de façon persistante. Le 21, l’agence américaine CISA a inscrit les deux failles à son catalogue des vulnérabilités activement exploitées. Entre le correctif et les premières attaques observées à grande échelle : environ 72 heures — un week-end. Cet article ne parle pas tant de la faille que de ce qu’elle révèle sur la façon dont un site est tenu.

  Remarque

Mise à jour du 23 juillet 2026. Cet article intègre la chronologie consolidée au 23 juillet : correctif du 17, exploitation constatée le 20, inscription CISA le 21, détails techniques complets publiés le 22 par les découvreurs. Il explique le risque et la protection, sans détailler aucun mode opératoire d’attaque : le but est de vous aider à protéger votre site, pas d’outiller qui que ce soit.

Même faille, deux issues : ce qui départage les deux sites, ce n'est pas WordPress, c'est qui le tient à jour.

Ce qui s’est passé, heure par heure  

Du correctif du vendredi à l'exploitation du lundi : un week-end suffisait pour trouver un site laissé sans surveillance.

Le correctif est sorti un vendredi de fin de journée ; l’exploitation à grande échelle a été observée le lundi. Le délai de réaction utile ne se comptait pas en semaines — il se comptait en heures. Voici la chronologie, telle qu’elle s’est déroulée. Les heures sont à situer sur notre fuseau : quand WordPress publie en fin de journée en Europe, il est encore début d’après-midi en Guadeloupe (UTC-4).

Ce que recouvrent les « 72 heures » du titre, précisément. Elles mesurent le délai entre le correctif du vendredi 17 et l’exploitation à grande échelle constatée le lundi 20. C’est un repère volontairement honnête, et il mérite une nuance qu’on ne lit nulle part ailleurs : les premiers outils d’attaque partiels sont apparus en quelques heures, pas en 72. Autrement dit, le délai de réaction réellement utile — celui pendant lequel un site pouvait encore être mis à jour avant que les robots ne le trouvent — était inférieur à 72 heures. Un éditeur a même mesuré les toutes premières sondes contre ses capteurs environ 90 minutes après la publication du correctif. Le chiffre de 72 heures n’est donc pas un délai de grâce : c’est la mesure d’une fenêtre qui s’est refermée bien plus vite qu’il n’y paraît.

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

WP2Shell n’est pas un bug isolé. C’est l’enchaînement de deux défauts distincts du cœur de WordPress qui, pris ensemble, permettent à un attaquant non authentifié d’exécuter du code à distance sur une installation standard. Prendre la main sur le site sans jamais s’y connecter.

La première faille (CVE-2026-63030) est une confusion de route dans l’API REST « batch » de WordPress, l’interface qui permet de grouper plusieurs requêtes en une seule. Elle a été introduite avec la version 6.9. La seconde (CVE-2026-60137) est une injection SQL logée dans un paramètre du moteur de requêtes, présente depuis la 6.8. Séparément, elles sont déjà sérieuses. Chaînées, elles ouvrent la porte à l’exécution de code à distance non authentifiée : ni compte, ni clic, ni plugin, ni thème tiers requis.

  Astuce

WP2Shell ne vient pas d’un plugin douteux : la faille est dans le cœur de WordPress. Même une installation propre et minimale est exposée si elle n’est pas à jour. La seule vraie protection, c’est la mise à jour — puis la vérification qu’aucun intrus n’était déjà entré.

C’est un renversement important. On associe souvent les piratages WordPress à une extension gratuite mal codée, installée puis oubliée. Ici, le problème est ailleurs : dans le logiciel lui-même. Un site « bien rangé », sans fioritures, reste vulnérable s’il tourne sur une version touchée sans correctif. Le sujet n’est donc pas la qualité de votre installation de départ. C’est sa maintenance dans le temps.

La découverte revient à Adam Kues, de l’équipe Assetnote (Searchlight Cyber), remontée via le programme de sécurité officiel de WordPress sur HackerOne. WordPress fait tourner environ 43 % du web selon les décomptes courants — la surface d’attaque est donc immense, à l’échelle de la planète comme à celle de nos îles.

Un score n’est pas une priorité  

Un détail utile pour ne pas se laisser tromper par les étiquettes. L’avis de sécurité officiel classe la faille de l’API batch comme critique, mais son score CVSS technique est de 7,5, une valeur qui correspond au niveau « élevé », pas « critique », dans le barème standard. Les deux ne se contredisent pas : le score CVSS mesure des caractéristiques techniques, tandis que le classement « critique » traduit l’impact réel et la facilité d’exploitation.

Ce qui doit décider de votre priorité, ce n’est pas le chiffre. C’est le fait que l’exploitation est constatée et que la faille a été inscrite au catalogue KEV de la CISA. Un score modéré sur une faille activement exploitée reste une urgence absolue.

Êtes-vous concerné ? Comment lire votre version sans rien casser  

Voici l’essentiel pour situer votre propre site.

Pour connaître votre version sans prendre de risque : elle s’affiche dans le tableau de bord WordPress, en bas à droite de l’écran d’accueil, ou dans la rubrique « À propos ». Ne sollicitez pas vous-même l’endpoint batch pour « tester » votre site, et surtout jamais celui d’un site tiers : c’est inutile pour un diagnostic et cela ressemble à une attaque. Si vous voulez une vérification externe, passez par les outils de contrôle officiels déjà existants, ou demandez à votre prestataire — pas par un test maison contre l’interface vulnérable.

  Attention

Si votre site vous semble déjà anormal, ne vous fiez pas au numéro de version affiché dans le tableau de bord : un intrus peut l’avoir modifié pour masquer sa présence. Dans ce cas, la version réelle se lit sur les fichiers du serveur, pas dans l’interface d’administration.

Combien de sites concernés, ici, en Guadeloupe  

La faille n'est pas un sujet lointain : une bonne part des sites guadeloupéens tourne sous WordPress, donc était concernée.

Pour poser un chiffre local plutôt que de rester dans l’abstrait, nous avons regardé notre propre panel. Sur les 293 sites WordPress guadeloupéens que suit l’Observatoire Kimoun, relevés le 22 juillet 2026, 47 sites (16 %) exposaient encore publiquement une version du cœur antérieure à 6.9.5 — donc potentiellement vulnérables.

Ce chiffre est un plancher, et la méthode mérite d’être dite honnêtement. La détection est passive : nous lisons la version affichée par le site lui-même (balise « generator », empreintes de fichiers publics), sans jamais solliciter l’endpoint batch ni tester quoi que ce soit d’agressif, et sans nommer aucun site. Or seuls 154 sites du panel (52,6 %) laissent voir leur version. Rapporté à ce sous-ensemble « versions visibles », la part vulnérable grimpe à 30,5 % — près d’un tiers. Les 139 sites qui masquent leur version ne sont pas présumés à jour pour autant : ne pas exposer sa version n’est pas une preuve de mise à jour, juste une absence d’information. Le vrai nombre de sites exposés est donc, au minimum, celui-là — probablement davantage.

Le piège de la mise à jour automatique  

C’est le cœur du sujet, et le point que les autres articles ratent. La mise à jour automatique forcée déclenchée par WordPress a sauvé énormément de sites. Mais elle n’est pas une politique de maintenance : c’est un filet de sécurité dont on ne sait ni s’il s’est déployé, ni s’il est arrivé à temps, ni s’il a nettoyé ce qui avait déjà été installé. Trois angles morts, dans l’ordre d’importance croissante.

Un. La mise à jour forcée n’atteint pas tout le monde. WordPress ne peut rustiner d’office que les sites où 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. Ces sites-là n’ont reçu aucun correctif automatique. Ils attendent une main humaine.

Deux, et c’est le plus important : patcher n’expulse pas un intrus déjà entré. Dès le lundi 20 juillet, les attaquants installaient des portes dérobées persistantes — des webshells, des comptes administrateurs cachés, des tâches planifiées. Appliquer le correctif après coup ferme la porte d’entrée, mais ne met pas dehors celui qui est déjà dans la maison. Un site mis à jour lundi soir peut très bien avoir été compromis lundi matin, et rester sous contrôle d’un tiers tout en affichant fièrement une version à jour. La mise à jour règle la vulnérabilité ; elle ne règle pas une compromission déjà survenue.

Trois, la fenêtre était un week-end. Le correctif est sorti vendredi en fin de journée européenne — début d’après-midi chez nous. Les premiers outils d’attaque ont circulé dans les heures qui ont suivi. L’exploitation à grande échelle a été observée le lundi. La question, pour beaucoup de sites, se résume à une phrase simple : quelqu’un regardait-il, samedi ? Un site qui n’est surveillé par personne le week-end est un site qui, ce week-end-là précisément, était livré à lui-même au pire moment.

Ce qu’il faut faire, dans cet ordre  

Voici la marche à suivre, du plus urgent au plus structurel. Rien d’ésotérique — ce sont les réflexes de base d’un site tenu sérieusement. Tout ce qui suit sert à se protéger, jamais à reproduire l’attaque.

1. Relevez votre version exacte. Dans le tableau de bord WordPress ou, si le site vous semble déjà suspect, directement sur les fichiers du serveur — ne vous fiez pas à l’affichage de l’interface dans ce cas.
2. Passez en 6.9.5 ou 7.0.2 selon votre branche, ou en 6.8.6 si vous êtes resté sur la branche 6.8. Faites une sauvegarde avant, par prudence.
3. Vérifiez que la mise à jour est réellement appliquée. Une mise à jour lancée n’est pas toujours une mise à jour aboutie : contrôlez la version affichée après coup, et que le site fonctionne normalement.
4. Bloquez l’endpoint batch au pare-feu applicatif (WAF) si vous ne pouvez pas patcher immédiatement. Point technique important : il faut bloquer les deux formes d’accès, la variante en chemin d’URL (/wp-json/batch/v1) et la variante en paramètre de requête (?rest_route=/batch/v1). Bloquer une seule des deux laisse la porte ouverte.
5. Cherchez la persistance. Fichiers PHP récents hors de l’arborescence habituelle, comptes administrateurs inconnus, tâches planifiées non prévues, fichiers du cœur modifiés. Ce sont les traces les plus courantes d’une porte dérobée.
6. En cas de doute sérieux, assumez le pire. Faites tourner les sels de sécurité et les identifiants de la base de données, restaurez depuis une sauvegarde antérieure au 17 juillet, puis remettez à jour. Restaurer une sauvegarde postérieure au 17 risque de réinstaller l’intrus avec.

Si votre site est resté exposé après le 20 juillet  

Verrouiller la porte après coup ne met pas dehors celui qui est déjà entré pendant le week-end.

Passé le 20 juillet sans mise à jour ni surveillance, la bonne posture n’est pas « je patche et je passe à autre chose », mais « je pars du principe qu’il a pu se passer quelque chose, et je vérifie ». C’est ce que les équipes de sécurité appellent la posture assume breach : plutôt que d’espérer que tout va bien, on suppose qu’une intrusion a pu avoir lieu et on cherche activement les traces. Ce n’est pas de la paranoïa. Sur une faille exploitée en masse dès le premier lundi, un site resté vulnérable tout le week-end fait partie de la population que les robots ont eu tout le temps de balayer.

La difficulté, on l’a dit, c’est qu’une compromission propre peut ne laisser aucune trace évidente. Sans journalisation activée en amont ni empreinte de référence des fichiers, on ne peut pas comparer l’état actuel à un état sain connu. C’est exactement là qu’un audit fait la différence : il ne se contente pas de regarder si le site « a l’air » normal, il compare les fichiers du cœur à leur version d’origine, inspecte les comptes et les tâches planifiées, et lève le doute. Notre audit de résilience numérique est conçu pour ce genre de situation : établir, factuellement, où en est un site.

Ce que nous avons fait, nous, ce week-end-là  

Notre week-end du 18-19 juillet : chaque site du parc relevé un par un, et les clients prévenus dès le 17.

Un article de conseil sur la sécurité n’a de valeur que si celui qui l’écrit s’applique à lui-même ce qu’il prêche. Voici donc, sobrement, ce qui s’est passé de notre côté.

Nous avons vérifié l’ensemble du parc que nous exploitons le week-end du 18-19 juillet, avant l’exploitation constatée du lundi. La méthode a été la même pour chaque site : relevé de la version exacte, contrôle que le correctif était réellement appliqué et non simplement déclenché, et blocage de l’endpoint batch là où c’était pertinent. Rien d’héroïque là-dedans : c’est le travail normal d’un prestataire qui tient des sites, fait au moment où il devait être fait.

Les clients concernés, eux, ont été prévenus dès le 17 juillet, avant même que cet article n’existe. C’est un point sur lequel nous tenons à être clairs : publier des conseils de sécurité sans avoir d’abord alerté son propre parc serait l’exact inverse de ce que nous défendons ici. L’ordre compte. On sécurise ce dont on a la charge, puis on partage ce qu’on en a appris.

  Remarque

Deux associations des Abymes, ce week-end-là. Deux sites que nous n’avions aucune obligation contractuelle de surveiller — autogérés par des bénévoles, hébergés en mutualisé, sans contrat de maintenance ni chez nous ni ailleurs. L’un tournait encore sur la branche 6.8 (donc concerné par l’injection SQL) : ses responsables ont mis à jour après notre appel. L’autre était déjà à jour, auto-updates activées — le filet a fonctionné pour lui. Les deux structures ont été très réactives, et aucune compromission n’a été constatée. Nous les avons prévenues bien qu’elles soient hors de notre périmètre, parce que l’ampleur du danger le justifiait. Le contraste dit tout : sur le premier site, rien n’a filtré le risque jusqu’à notre coup de fil ; sur le second, l’auto-update a joué son rôle de filet. C’est précisément la thèse de cet article, illustrée en vrai — l’auto-update est un filet, pas une politique.

Hébergement n’est pas infogérance  

Ranger un site en ligne et l'entretenir dans la durée sont deux métiers : c'est la nuance que WP2Shell rend visible.

Il faut le dire noir sur blanc, parce que c’est ce qui rend tout le reste crédible : héberger un site et le maintenir sont deux métiers différents, et nos conditions de service les distinguent. Sur un contrat d’hébergement, la mise à jour du CMS incombe au client. Sur un contrat d’infogérance, c’est nous qui la portons. Un site hébergé chez nous n’est donc pas automatiquement un site que nous tenons à jour : cela dépend de ce que le client a souscrit.

Le préciser n’affaiblit pas notre offre, au contraire. WordPress est souvent choisi pour sa facilité et son coût apparemment bas ; le vrai coût, invisible au départ, c’est la maintenance dans la durée — la veille, les correctifs, les sauvegardes testées, la surveillance. Quelqu’un doit la porter : soit le client en pleine autonomie, soit un prestataire sous contrat. WP2Shell aura au moins servi à rendre ce choix visible. C’est aussi un point que je développe, sous un autre angle, dans mon article sur la sécurité du code généré par IA : une technologie séduisante ou pratique ne dispense jamais du suivi.

Ce que WP2Shell change vraiment : le tempo  

Il y a un dernier fait, confirmé sur la publication des découvreurs, qui mérite qu’on s’y arrête — non pas pour crier au loup sur l’intelligence artificielle, mais parce qu’il éclaire la fenêtre de 72 heures d’un jour nouveau. Adam Kues n’a pas trouvé cette chaîne d’exploitation seul : il a piloté un modèle de langage (GPT-5.6 Sol), en lui donnant du code WordPress dépouillé de son historique pour l’empêcher de tricher, et en le laissant chercher un chemin d’attaque pendant une dizaine d’heures. Coût de l’opération, de son propre aveu : une dizaine d’heures et environ 25 dollars de calcul. Il l’a dit sans détour : aucun chercheur humain n’aurait bouclé cette chaîne en si peu de temps sans cette aide.

Ce qui change, ce n’est pas la nature des failles — WordPress en a connu d’autres. C’est le tempo. Quand découvrir une faille exploitable devient plus rapide et beaucoup moins cher, l’écart entre la publication d’un correctif et l’apparition d’un outil d’attaque se réduit. Les 90 minutes entre le correctif et les premières sondes, cette semaine, ne sont pas un accident : elles annoncent le rythme des prochaines fois. La conséquence pratique, pour un site guadeloupéen comme pour un autre, est simple : la question n’est plus « mon site sera-t-il patché un jour ? » mais « qui le patchera dans la journée, et qui vérifiera derrière ? ». Le filet automatique aide ; il ne remplace pas quelqu’un qui regarde.