WordPress : une chaîne de deux vulnérabilités permet une prise de contrôle à distance sans authentification

Une simple requête POST vers l'endpoint batch de l'API REST de WordPress, accompagnée d'un corps JSON spécifique, peut suffire à prendre le contrôle total d'un site. C'est ce que révèlent les détails techniques de wp2shell, rendus publics le 18 juillet 2026 par des équipes de recherche en cybersécurité. La faille, identifiée sous les références CVE-2026-63030 et CVE-2026-60137, a été découverte par Adam Kues (chercheur chez Assetnote / Searchlight Cyber) et, pour la composante d'injection SQL, par les experts TF1T, dtro et haongo.

Deux bugs chaînés pour une RCE complète

Contrairement à une idée répandue, wp2shell n'est pas un outil malveillant ou un plugin supplémentaire, mais le nom donné à un enchaînement de deux vulnérabilités du noyau WordPress. La première, CVE-2026-63030, est une confusion de routes dans l'endpoint batch (/wp-json/batch/v1). Ce dernier permet de regrouper plusieurs sous-requêtes en une seule transaction HTTP. En interne, WordPress maintient deux tableaux parallèles pour la validation et le routage des sous-requêtes. Les chercheurs ont montré qu'une sous-requête avec un chemin volontairement malformé (échouant à wp_parse_url) est ajoutée au tableau de validation mais pas au tableau de routage, provoquant un décalage entre les deux. Ce décalage fait qu'une sous-requête ultérieure est validée sous une route mais exécutée sous une autre, contournant les contrôles d'authentification et de méthode.

La seconde vulnérabilité, CVE-2026-60137, est une injection SQL dans le paramètre author__not_in de WP_Query. Isolée, elle ne permet pas une prise de contrôle à distance. Mais couplée à la confusion de routes, elle devient exploitable sans aucun prérequis d'authentification. Un attaquant peut ainsi exécuter des requêtes SQL arbitraires sur la base de données.

Versions concernées et correctifs

L'analyse détaillée des versions affectées révèle que la branche 6.8 (de 6.8.0 à 6.8.5) n'est vulnérable qu'à l'injection SQL seule, sans possibilité d'enchaînement menant à une exécution de code. En revanche, les versions 6.9.0 à 6.9.4, 7.0.0 à 7.0.1, ainsi que la version bêta 7.1, sont toutes exposées à une RCE pré-authentifiée complète. Les correctifs ont été déployés dans les versions 6.8.6, 6.9.5 et 7.0.2. La version 7.1 bêta 2 a également corrigé le problème.

Réaction officielle : mise à jour forcée

Face à la gravité de la menace, l'équipe de WordPress a réagi en déclenchant des mises à jour automatiques forcées sur les installations concernées. Cette mesure vise à protéger les millions de sites qui utilisent encore une version vulnérable. Les administrateurs sont invités à vérifier que leur installation est à jour, notamment en consultant la version indiquée dans le panneau d'administration ou via des outils de détection.

Mécanisme exploité sans accès préalable

D'après les informations publiées, l'attaque nécessite une seule requête POST correctement formée vers /wp-json/batch/v1. Aucun compte administrateur ni plugin tiers vulnérable n'est requis. Une fois l'exploitation réussie, l'attaquant peut créer un nouveau compte administrateur, installer un plugin malveillant dans le répertoire wp-content/plugins/, et exécuter des commandes système via un shell distant. Les chercheurs insistent sur le fait que les payloads opérationnels n'ont pas été rendus publics afin d'éviter une exploitation massive avant que les correctifs ne soient largement déployés.

Recommandations

Les propriétaires de sites WordPress doivent s'assurer que leur version est supérieure ou égale à 6.8.6, 6.9.5 ou 7.0.2 selon leur branche. La mise à jour automatique étant déjà active par défaut pour les versions corrigées, il est conseillé de vérifier manuellement si l'option de mise à jour automatique a été désactivée. Pour les sites ne pouvant pas être mis à jour immédiatement, une restriction de l'accès à l'endpoint /wp-json/batch/v1 via un pare-feu applicatif peut constituer une mesure de mitigation temporaire.