WordPress wp2shell : la faille RCE critique qui a forcé une mise à jour d'urgence

Le 17 juillet 2026, WordPress a fait quelque chose qu'il ne fait presque jamais : ignorer le choix des administrateurs et forcer une mise à jour sur des millions de sites, même ceux où les mises à jour automatiques étaient désactivées.

Le nom de la faille : wp2shell. Le verdict des chercheurs qui l'ont trouvée : exécution de code à distance, sans authentification, sur une installation par défaut, sans plugin.

Autrement dit, le pire scénario possible pour un CMS qui fait tourner plus de 40 % du web.

Pourquoi cette faille sort du lot

Chaque semaine apporte son lot de vulnérabilités WordPress. Dans l'immense majorité des cas, elles touchent un plugin ou un thème tiers, avec une base d'installations limitée et un vecteur qui suppose déjà un minimum d'accès.

wp2shell ne coche aucune de ces cases rassurantes :

• Elle vit dans le cœur de WordPress, pas dans un plugin.
• Elle est exploitable sans compte, sans droits, sans interaction.
• Elle touche une installation par défaut, telle quelle, sortie de la boîte.

C'est cette combinaison qui a poussé Searchlight Cyber, l'équipe qui a découvert la faille, à la classer critique, et qui a poussé WordPress à répondre avec un déploiement forcé plutôt qu'avec un simple bulletin de sécurité.

Comment fonctionne l'attaque

Tout part d'un endpoint REST API censé faire gagner du temps : /wp-json/batch/v1, qui permet de regrouper plusieurs appels API en une seule requête.

Le problème se situe dans la façon dont ce endpoint résout les routes internes, une confusion qui laisse passer des données non assainies jusqu'à la base de données. La chaîne complète se déroule en deux temps :

1. Une injection SQL via le traitement du batch, qui permet de manipuler des requêtes vers la base de données.
2. Une exécution de code arbitraire (RCE), rendue possible par ce qui a été injecté à l'étape précédente.

CVE-2026-60137 — la composante injection SQL, qui touche aussi la branche 6.8

CVE-2026-63030 — la chaîne complète menant au RCE, remontée par le chercheur Kues

Versions concernées

6.8.x — vulnérable jusqu'à 6.8.5 (SQLi seule) → corrigée en 6.8.6

6.9.x — vulnérable de 6.9.0 à 6.9.4 → corrigée en 6.9.5

7.0.x — vulnérable de 7.0.0 à 7.0.1 → corrigée en 7.0.2

7.1 (beta) — vulnérable en beta1 → corrigée en beta2

Le vrai signal d'alarme : le force-push

WordPress dispose d'un système de mise à jour automatique en tâche de fond, mais il respecte d'ordinaire la volonté d'un administrateur de le désactiver. C'est une des rares décisions de configuration que le cœur de WordPress ne remet jamais en question.

Le 17 juillet, cette règle a sauté. Le correctif a été poussé à tous les sites concernés, qu'ils aient ou non l'auto-update activé.

🚨 C'est ce détail, plus que la faille elle-même, qui mérite l'attention. WordPress ne casse ce contrat de confiance qu'en de très rares occasions. Le message implicite : le risque d'exploitation de masse était jugé trop élevé pour laisser la main aux administrateurs.

Ce qu'il faut faire, concrètement

1. Vérifier la version réellement installée. Ne présume pas que l'auto-update a fonctionné. Sur les hébergements mutualisés ou les configurations personnalisées, la mise à jour automatique peut échouer en silence. Va directement dans le tableau de bord d'administration et confirme la version affichée : 6.9.5, 7.0.2, ou supérieure.
2. Si une mise à jour immédiate est impossible, mets en place au moins une de ces mitigations le temps de patcher.
3. Surveiller les logs des jours suivants pour toute requête suspecte vers l'endpoint batch, même après correction, un signe qu'un tiers testait déjà la faille avant le patch.

• Bloquer /wp-json/batch/v1 et rest_route=/batch/v1 au niveau du WAF ou du reverse proxy
• Installer un plugin qui restreint l'accès non authentifié à la REST API
• Ajouter un must-use plugin qui exige une authentification sur la route batch

À retenir

Aucune exploitation active n'était signalée au moment de la divulgation, selon Searchlight Cyber. Mais l'historique des failles core WordPress est sans appel : la fenêtre entre la divulgation publique et les premières tentatives d'exploitation automatisée se compte en heures, pas en jours.

Si tu gères ne serait-ce qu'un seul site WordPress, ce correctif n'est pas de ceux qu'on remet à demain.