Failles critiques dans le core WordPress : ce qu’il faut savoir et comment réagir

Le 17 juillet 2026, l’équipe de sécurité de WordPress a publié trois versions correctives — 6.8.6, 6.9.5 et 7.0.2 — accompagnées de deux avis de sécurité publiés sur le dépôt wordpress-develop. L’une des deux vulnérabilités est classée critique et permet, dans certaines configurations, l’exécution de code à distance.

Cet article détaille la nature technique de ces failles, les versions concernées, et la marche à suivre pour sécuriser vos installations.

---

Pourquoi une faille dans le core mérite votre attention

L’écrasante majorité des vulnérabilités WordPress rendues publiques chaque année concernent des extensions et des thèmes tiers. Le code du core, lui, bénéficie d’un processus de revue rigoureux, d’une base de contributeurs importante et d’une équipe de sécurité dédiée. Les failles y sont rares.

C’est précisément ce qui rend l’événement notable. Une vulnérabilité dans le core touche potentiellement l’ensemble des sites exécutant les versions concernées, sans qu’aucune extension particulière ne soit nécessaire à l’exploitation. La surface d’attaque n’est plus fonction des choix de l’administrateur : elle est universelle.

---

Les deux vulnérabilités

GHSA-fpp7-x2x2-2mjf — Injection SQL facilitée dans WP_Query

Sévérité : modérée

Versions affectées :

Branche	Versions vulnérables
6.8	6.8.0 → 6.8.5
6.9	6.9.0 → 6.9.4
7.0	7.0.0 → 7.0.1

La faille réside dans le traitement du paramètre author__not_in de la classe WP_Query, le composant central utilisé par WordPress pour construire les requêtes de récupération de contenu.

WP_Query accepte un grand nombre de paramètres permettant de filtrer les publications retournées. Le paramètre author__not_in sert à exclure des auteurs d’un jeu de résultats, en attendant normalement un tableau d’identifiants numériques. Un défaut de validation sur ce paramètre permet à des données non assainies de se retrouver dans la requête SQL finale.

Le qualificatif de vulnérabilité « facilitée » (facilitated) employé dans l’avis est important : le core n’expose pas directement le paramètre à une entrée utilisateur non authentifiée. L’exploitation suppose qu’un point d’entrée — extension, thème, code personnalisé ou route API — transmette une valeur contrôlée par l’attaquant à ce paramètre. Le core rend l’exploitation possible ; le contexte applicatif la rend atteignable.

C’est ce qui explique le classement en sévérité modérée lorsqu’on considère la faille isolément. Ce classement change radicalement en combinaison.

Divulguée par : TF1T, dtro et haongo.

GHSA-ff9f-jf42-662q — Confusion de routes dans l’API REST menant à du RCE

Sévérité : critique

Versions affectées :

Branche	Versions vulnérables
6.9	6.9.0 → 6.9.4
7.0	7.0.0 → 7.0.1

Depuis WordPress 6.9, l’API REST propose un mécanisme de requêtes groupées (batch requests), qui permet de soumettre plusieurs opérations en un seul appel HTTP via l’endpoint /wp-json/batch/v1. Ce mécanisme existe pour des raisons de performance, notamment côté éditeur de blocs.

La vulnérabilité tient à une confusion dans la résolution des routes au sein de ce mécanisme. Les requêtes individuelles encapsulées dans un lot ne sont pas résolues et validées avec la même rigueur qu’une requête directe équivalente. Un attaquant peut exploiter cette divergence pour atteindre, via le lot, des routes ou des paramètres qui auraient été filtrés en accès direct.

Prise isolément, cette confusion de routes est un problème de contrôle d’accès. Combinée à l’injection SQL décrite ci-dessus, elle fournit le point d’entrée qui manquait : l’attaquant obtient un canal pour injecter des données contrôlées dans WP_Query, transformant une faille conditionnelle en chaîne d’exploitation complète menant à l’exécution de code à distance.

C’est le schéma classique d’une vulnérabilité composée : deux défauts individuellement gérables, dont l’assemblage produit un impact d’un tout autre ordre.

Divulguée par : Adam Kues (Assetnote / Searchlight Cyber).

---

Synthèse des versions

Versions corrigées

• 6.8.6
• 6.9.5
• 7.0.2
• 7.1 beta2

Tableau récapitulatif

Version installée	Injection SQL	RCE via API REST	Action
≤ 6.7.x	Non concernée	Non concernée	Mise à jour de branche recommandée
6.8.0 – 6.8.5	Vulnérable	Non concernée	Passer en 6.8.6
6.8.6	Corrigée	Non concernée	À jour
6.9.0 – 6.9.4	Vulnérable	Vulnérable	Passer en 6.9.5 — urgent
6.9.5	Corrigée	Corrigée	À jour
7.0.0 – 7.0.1	Vulnérable	Vulnérable	Passer en 7.0.2 — urgent
7.0.2	Corrigée	Corrigée	À jour

Le cas particulier des versions 6.7 et antérieures

Ces versions ne sont pas concernées par les deux avis. C’est une bonne nouvelle ponctuelle qui masque un problème structurel.

Un site en 6.7 ou antérieur accuse plusieurs cycles de retard. Il est exposé aux vulnérabilités corrigées entre sa version et la version courante — des failles publiques, documentées, pour lesquelles des exploits circulent depuis des mois. Ne pas figurer sur la liste des versions affectées ce mois-ci ne constitue pas une posture de sécurité.

---

Que faire concrètement

1. Identifier vos versions

Depuis WP-CLI, sur chaque installation :

wp core version

Sur un serveur mutualisé ou multi-sites, un inventaire par balayage du système de fichiers reste la méthode la plus fiable :

find /var/www -name version.php -path '*/wp-includes/*' 2>/dev/null | \
while read f; do
  v=$(grep -oP "\\\$wp_version = '\K[^']+" "$f")
  echo -e "$v\t${f%/wp-includes/version.php}"
done | sort -V

2. Mettre à jour

Via WP-CLI, en restant dans la branche mineure :

wp core update --minor

Ou en ciblant explicitement la version :

wp core update --version=7.0.2

Depuis l’interface d’administration : Tableau de bord → Mises à jour.

3. Vérifier après coup

La mise à jour du core ne garantit rien si elle a échoué silencieusement — cas fréquent lorsque les permissions du système de fichiers sont restrictives ou qu’un plugin de gestion de mises à jour interfère. Contrôlez systématiquement la version effective après l’opération.

4. Rechercher d’éventuelles traces de compromission

Sur un site resté vulnérable en 6.9.x ou 7.0.x pendant une période prolongée, une mise à jour ne suffit pas : elle ferme la porte, mais n’expulse pas qui serait déjà entré. Points de contrôle prioritaires :

• comptes administrateurs inconnus dans Utilisateurs
• fichiers PHP récemment modifiés dans wp-content/uploads/ (répertoire qui ne devrait jamais en contenir)
• tâches planifiées inattendues (wp cron event list)
• entrées suspectes dans les logs d’accès sur /wp-json/batch/v1

Si votre site a été piraté, LRob propose un service de réparation et de sécurisation pour WordPress.

5. Empêcher que cela se reproduise

Les mises à jour automatiques du core pour les versions mineures sont activées par défaut depuis WordPress 3.7. Si vos sites n’étaient pas à jour, c’est que ce mécanisme a été désactivé — volontairement ou par un plugin. Vérifiez la constante dans wp-config.php :

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Les versions correctives de sécurité relèvent précisément de cette catégorie.

Pour une mise à jour plus rapide, les hébergements LRob permettent les mises à jour automatiques directement depuis le serveur.

---

Ce que révèle vraiment cet épisode

Le délai entre la publication d’un correctif et l’apparition d’exploits automatisés se mesure aujourd’hui en heures, pas en semaines. Les scanners de masse intègrent les nouveaux vecteurs presque immédiatement, et un site en retard n’est pas ciblé parce qu’il intéresse quelqu’un : il l’est parce qu’il est trouvable.

La question pertinente n’est donc pas « suis-je à jour aujourd’hui ? », mais « combien de temps s’écoule structurellement, dans mon organisation, entre la publication d’un correctif et son application ? ». C’est une question de processus, pas de vigilance individuelle.

---

L’approche LRob

Chez LRob, la couverture de ces deux failles concernait 1,3 % du parc hébergé au moment de la publication des avis — conséquence directe d’une politique de mise à jour automatisée appliquée par défaut.

Notre offre d’hébergement WordPress inclut :

• des protections additionnelles spécifiques à WordPress, en amont du code applicatif, avec un bannissement actif des attaquants par les serveurs, ce qui réduit drastiquement la surface d’attaque indépendamment de la version installée ;
• la possibilité d’activer les mises à jour automatiques du core, des extensions et des thèmes ;
• des offres de maintenance WordPress complètes, comprenant surveillance, sauvegardes testées et intervention en cas d’incident.

L’objectif est simple : que la publication d’un avis de sécurité ne soit plus, pour vous, un événement nécessitant une action dans l’urgence. Vous confiez la veille et l’application des correctifs, et vous dormez sur vos deux oreilles.

Découvrir nos offres de maintenance WordPress →

---

Références

• GHSA-fpp7-x2x2-2mjf — Facilitated SQL injection vulnerability in the author__not_in parameter of WP_Query
• GHSA-ff9f-jf42-662q — REST API batch-route confusion and SQL injection issue leading to Remote Code Execution
• Annonce officielle WordPress 7.0.2