Une faille rare : le cœur de WordPress touché, pas une extension
L'écrasante majorité des vulnérabilités WordPress découvertes chaque année concernent des extensions ou des thèmes tiers. Le cœur du logiciel (le « core »), lui, bénéficie d'un processus de revue rigoureux et d'une équipe de sécurité dédiée : les failles critiques y sont exceptionnelles. C'est ce qui rend l'événement notable, comme le souligne l'hébergeur spécialisé français LRob dans son analyse du 18 juillet : une faille du core touche potentiellement tous les sites exécutant les versions concernées, quels que soient les choix d'extensions de l'administrateur. La surface d'attaque n'est plus fonction de la configuration : elle est universelle. La découverte revient au chercheur Adam Kues, de l'équipe Assetnote de Searchlight Cyber, qui l'a signalée à WordPress via son programme HackerOne. Fait significatif : pour laisser aux administrateurs le temps de corriger, Searchlight n'a pas publié les détails techniques de la chaîne d'attaque. L'entreprise a en revanche mis en ligne un outil public, wp2shell.com, qui permet de vérifier en quelques secondes si une installation reste exposée — un réflexe à la portée de n'importe quel dirigeant de PME, sans compétence technique.Comment l'attaque fonctionne — et pourquoi « sans mot de passe » n'est pas une exagération
wp2shell est le chaînage de deux failles. La première, CVE-2026-63030, est une confusion de routage dans l'API REST de WordPress, au niveau du point d'entrée des requêtes groupées (/wp-json/batch/v1), apparu avec la version 6.9. La seconde, CVE-2026-60137, est une injection SQL logée dans le paramètre author__not_in de la fonction WP_Query. Prises isolément, elles sont déjà sérieuses ; combinées, elles permettent à un attaquant anonyme — sans compte, sans identifiant, sans extension installée — d'exécuter du code arbitraire sur le serveur. En clair : prendre le contrôle du site, y déposer ce qu'il veut, lire ce qu'il veut.
Searchlight Cyber résume la situation sans détour : « l'attaque n'a aucune précondition et peut être exploitée par un utilisateur anonyme sur une installation standard de WordPress, sans extension ». Malgré la rétention des détails techniques, plusieurs preuves de concept circulent déjà sur GitHub, relève Clubic — certaines extraient d'abord les empreintes de mots de passe via l'injection SQL avant de casser le compte administrateur, d'autres obtiennent une exécution de code directe. Et les premières attaques réelles ont commencé : Benjamin Harris, le patron de la société de sécurité watchTowr, a confirmé des signes d'exploitation observés sur le terrain. Le CERT-FR, dans son alerte CERTFR-2026-ALE-007 publiée ce 20 juillet, dit s'attendre à des tentatives d'exploitation « en masse » — le sort habituel des failles WordPress industrialisables, scannées en continu par des botnets.
Êtes-vous concerné ? Les versions touchées, noir sur blanc
Le périmètre est précisément documenté par WordPress et le CERT-FR. La chaîne complète — celle qui permet la prise de contrôle sans authentification — touche les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Les versions 6.8.x ne sont vulnérables qu'à l'injection SQL (corrigée en 6.8.6) : c'est grave, mais sans la prise de contrôle directe. Les versions antérieures à 6.8 ne sont pas concernées. À noter : selon W3Techs, la branche 7 équipe déjà environ la moitié du parc WordPress — autrement dit, le cœur de cible de wp2shell est aussi la population la plus nombreuse.wp2shell en chiffres
- 2 vulnérabilités chaînées : CVE-2026-63030 (confusion de route API REST) + CVE-2026-60137 (injection SQL)
- 17 juillet 2026 : correctifs 7.0.2, 6.9.5 et 6.8.6, avec mises à jour automatiques forcées
- 20 juillet 2026 : bulletin d'alerte CERT-FR (CERTFR-2026-ALE-007), preuve de concept publique, exploitation de masse anticipée
- Versions vulnérables à la prise de contrôle : 6.9.0 → 6.9.4 et 7.0.0 → 7.0.1 (6.8.x : injection SQL seule)
- ~41 % des sites web mondiaux fonctionnent sous WordPress (W3Techs) ; plus de 500 millions de sites selon l'estimation de Searchlight Cyber
- ~50 % du parc WordPress est déjà en branche 7, la plus exposée (W3Techs)
La mise à jour forcée ne protège pas tout le monde
Face à la gravité, l'équipe WordPress.org a déclenché une procédure réservée aux cas extrêmes : la mise à jour automatique forcée. Les sites vulnérables reçoivent la version corrigée sans intervention de leur administrateur. Bonne nouvelle — mais elle ne doit pas endormir la vigilance, pour trois raisons. Un, la mise à jour forcée ne passe pas partout : sites dont les mises à jour automatiques ont été désactivées (un choix fréquent des agences pour éviter les régressions), installations gérées par des outils de déploiement, hébergements exotiques ou vieillissants. Deux, entre la divulgation et le passage effectif du correctif, il existe une fenêtre pendant laquelle le site a pu être compromis : être à jour aujourd'hui ne prouve pas qu'on n'a pas été visité hier. Trois, un site cloué sur une version antérieure à 6.9 pour cause de thème ou d'extensions incompatibles reste exposé à l'injection SQL s'il n'est pas passé en 6.8.6. Pour ceux qui ne peuvent pas mettre à jour immédiatement, le CERT-FR relaie les mesures de contournement des chercheurs : bloquer l'accès non authentifié à l'API REST, ou couper via un pare-feu applicatif (WAF) le chemin/wp-json/batch/v1 et les requêtes contenant le paramètre rest_route=/batch/v1 — les deux motifs doivent être bloqués. Searchlight propose aussi un mini-plugin à déposer sur le serveur, qui exige une authentification pour toute requête groupée vers l'API. Des solutions de quelques minutes pour un prestataire — et un excellent test, au passage, de la réactivité du vôtre.
Pourquoi c'est un sujet Hauts-de-France : le site vitrine oublié est une porte d'entrée
Rien ne distingue techniquement un site lillois d'un site lyonnais — les botnets qui scannent le web ne lisent pas les plaques d'immatriculation. Mais le tissu économique régional, dense en TPE, artisans, commerces et PME industrielles, cumule deux facteurs de risque bien documentés. D'abord, le site « posé puis oublié » : réalisé par une agence ou un indépendant il y a trois, cinq, huit ans, sans contrat de maintenance, jamais mis à jour depuis. Ces sites-là ne recevront pas forcément la mise à jour forcée, et personne ne s'en apercevra avant que le site ne serve à héberger du phishing, à rediriger les visiteurs ou à spammer — avec, à la clé, un déréférencement Google et une image de marque abîmée. Ensuite, le calendrier : mi-juillet, une partie des entreprises tournent en effectif réduit, et l'ANSSI rappelle régulièrement que les périodes de congés sont propices aux compromissions détectées tardivement. Son dernier Panorama de la cybermenace confirme d'ailleurs que TPE, PME et ETI restent les premières victimes des attaques traitées par l'agence. Il y a enfin une dimension réglementaire qui monte. Comme nous le racontions dans notre dossier sur la saisine de la CJUE, la France est sous pression européenne pour transposer la directive NIS2, qui imposera des exigences de sécurité à des milliers d'entités — et la sécurité des sites web exposés sur Internet fait partie des fondamentaux exigés. Un site WordPress compromis peut aussi devenir le point de départ d'une fuite de données clients, avec les obligations RGPD que cela déclenche : notre dossier sur la fuite revendiquée chez SFR détaillait ce que valent ces données sur les marchés criminels. Et pour les entreprises qui branchent désormais des agents IA sur leurs outils, la leçon est la même que celle de notre enquête sur l'injection de prompt : la sécurité ne se joue pas au niveau de l'outil, mais de l'architecture et de la maintenance qui l'entourent.La check-list de ce lundi pour votre site WordPress
Que vous gériez votre site vous-même ou qu'un prestataire s'en occupe, voici les gestes concrets, dans l'ordre. La plupart prennent moins de dix minutes.- 1. Identifiez votre version. Tableau de bord WordPress → « Mises à jour ». Si vous voyez 7.0.2, 6.9.5 ou 6.8.6 (ou supérieur) : le correctif est en place. Sinon, mettez à jour immédiatement.
- 2. Testez votre exposition. L'outil wp2shell.com de Searchlight Cyber vérifie en quelques secondes si votre site répond aux motifs vulnérables.
- 3. Vous ne pouvez pas mettre à jour tout de suite ? Faites bloquer par votre WAF le chemin
/wp-json/batch/v1et le paramètrerest_route=/batch/v1, ou installez le plugin de contournement proposé par les chercheurs. - 4. Cherchez les signes de compromission. Comptes administrateurs inconnus, extensions ou fichiers récemment apparus, modifications de fichiers datées d'après le 17 juillet, pics de trafic sortant. En cas de doute, sauvegarde hors ligne puis analyse — le correctif ne désinfecte pas un site déjà compromis.
- 5. Votre site est géré par une agence ou un hébergeur ? Envoyez un message aujourd'hui : « Notre site est-il patché contre wp2shell (CVE-2026-63030) ? Les mises à jour automatiques sont-elles actives ? Avez-vous vérifié l'absence de compromission depuis le 17 juillet ? » La qualité de la réponse vous dira beaucoup sur votre contrat de maintenance.
- 6. Profitez-en pour assainir. Supprimez les extensions et thèmes inutilisés, activez les mises à jour automatiques au moins pour les versions de sécurité, vérifiez que vos sauvegardes existent réellement et qu'elles sont restaurables.
FAQ — wp2shell et votre site WordPress
Mon site WordPress est-il concerné par wp2shell ?Si votre site tourne en version 6.9.0 à 6.9.4 ou 7.0.0 à 7.0.1, il est vulnérable à la chaîne complète, qui permet une prise de contrôle sans mot de passe. Les versions 6.8.x sont exposées à la seule injection SQL (corrigée en 6.8.6). Les versions antérieures à 6.8 ne sont pas concernées. Vérifiez dans Tableau de bord → Mises à jour, ou via l'outil wp2shell.com. La mise à jour automatique forcée m'a-t-elle déjà protégé ?
Probablement, mais pas certainement. WordPress.org a poussé les versions corrigées sur les sites concernés dès le 17 juillet, sauf si les mises à jour automatiques ont été désactivées — un réglage fréquent sur les sites gérés par des agences ou déployés par des outils techniques. Vérifiez le numéro de version affiché : c'est la seule preuve qui compte. Comment savoir si mon site a déjà été piraté ?
Cherchez des comptes administrateurs que vous n'avez pas créés, des extensions ou fichiers inconnus, des modifications de fichiers postérieures au 17 juillet, des redirections étranges ou des alertes de Google Search Console. Attention : appliquer le correctif ne nettoie pas un site déjà compromis. En cas de doute, faites appel à un professionnel et conservez une sauvegarde pour analyse. Je ne peux pas mettre à jour tout de suite. Que faire en attendant ?
Le CERT-FR relaie deux contournements : bloquer via un pare-feu applicatif le chemin /wp-json/batch/v1 ainsi que les requêtes contenant rest_route=/batch/v1 (les deux motifs sont nécessaires), ou installer le petit plugin publié par Searchlight Cyber qui impose une authentification sur l'API de requêtes groupées. Ce sont des rustines : la mise à jour reste la seule vraie correction. Mon site est géré par un prestataire : quelles questions lui poser ?
Trois questions suffisent : le site est-il en version corrigée (7.0.2, 6.9.5 ou 6.8.6) ? Les mises à jour automatiques de sécurité sont-elles actives ? Une vérification d'absence de compromission a-t-elle été faite depuis le 17 juillet ? Si votre contrat de maintenance ne couvre pas ce type d'urgence, c'est le moment de le renégocier — wp2shell ne sera pas la dernière alerte de ce genre.
Sources
- CERT-FR — Bulletin d'alerte CERTFR-2026-ALE-007, « Multiples vulnérabilités dans WordPress », 20 juillet 2026
- WordPress.org — « WordPress 7.0.2 Release », 17 juillet 2026
- Searchlight Cyber — wp2shell.com, outil de vérification et mesures de contournement
- Clubic — « WordPress : des failles critiques RCE avec exploits publics », juillet 2026
- LRob — « Failles critiques dans le core WordPress », 18 juillet 2026
- The Hacker News — « New wp2shell WordPress Core Flaw », juillet 2026
- W3Techs — Statistiques d'usage de WordPress
- CVE.org — Fiche CVE-2026-63030
