wp2shell : une vulnérabilité RCE non authentifiée dans WordPress et comment la bloquer

juillet 19, 2026 Updated août 6, 2026 Patrick Schlesinger

wp2shell est une chaîne d’exécution de code à distance sans authentification présente dans le cœur de WordPress. Elle combine une SQL Injection (CVE-2026-60137) avec une faille de confusion de routes REST par lots (CVE-2026-63030) et ne nécessite ni Login ni plugin tiers. Les sites utilisant ReportedIP Hive sont déjà protégés : les règles sont actives dans la configuration de base fournie et publiées via l’API des règles ; ainsi, les installations gratuites et synchronisées bloquent dès aujourd’hui ce type de requêtes.

Commencez par appliquer le correctif au cœur de WordPress pour passer à la version corrigée. Cela permet d’éliminer la cause première du problème. Un pare-feu protège vos sites jusqu’à ce que tous ceux de votre parc soient mis à jour et bloque les variantes, mais il ne remplace pas le correctif du cœur. Si vous utilisez Hive, mettez-le également à jour vers la version 2.1.25, car les deux nouvelles règles sont incluses dans la version de base Free. Le guide du plugin contient les étapes d’installation et de mise à jour, et la dernière version est disponible sur la page GitHub Releases.

Les deux bogues, et pourquoi la chaîne est importante

Aucun de ces deux bogues n’est en soi critique. Mais lorsqu’ils sont combinés, ils permettent à une requête anonyme d’aboutir à l’exécution de code.

CVE-2026-60137 (SQL Injection, CVSS 9,1). Le paramètre REST author_exclude est mappé à la author__not_in variable de requête dans WP_Query et interpolée sous forme de chaîne dans une post_author NOT IN (…) clause. Une valeur telle que 0) UNION SELECT …-- - ferme la IN() liste et ajoute du code SQL arbitraire. En soi, cette fonctionnalité n’est accessible qu’à partir d’une requête de collection authentifiée.
CVE-2026-63030 (confusion de routes dans le traitement par lots REST). Dans /wp-json/batch/v1, une sous-requête dont le chemin d’accès échoue wp_parse_url() est ajoutée à la $validation mais pas à $matches. Les deux tableaux se désynchronisent, et une sous-requête validée est traitée par le gestionnaire de la sous-requête suivante. Cela permet à une GET /wp/v2/posts/999999 exécuter author_exclude s’exécute sous la collection `posts` get_items(), où réside la variable de requête injectable, sans aucune authentification.

Cette escalade par lots concerne WordPress 6.9 et les versions ultérieures, qui intègrent la gestion de la confusion d’itinéraire.

D’une attaque SQLi « à l’aveugle » à un shell

Dès que l’injection atteint une requête non fractionnée (l’exploit utilise orderby=none et per_page=500 la ligne subsiste donc en tant que fausse publication), il forge une ligne complète de 23 colonnes wp_posts avec UNION SELECT et transmet la valeur divulguée dans la requête réfléchie post_title. À partir de là, la chaîne génère trois oembed_cache articles, récupère leurs identifiants via la même injection, transpose ces identifiants dans un ensemble de modifications du personnalisateur et un graphe d’éléments de menu de navigation, puis crée un nouvel administrateur via la route utilisateur REST. Une fois l’accès administrateur obtenu, le téléchargement d’un plugin ou d’un thème permet l’exécution de code. Aucun identifiant n’est requis à aucune étape.

Comment ReportedIP Hive le bloque

Le pare-feu Hive s’intègre init avec la priorité 1, et le module optionnel « drop-in » s’exécute encore plus tôt via un auto_prepend_file « guard », avant même le démarrage de WordPress. Pour une requête non authentifiée, il inspecte l’URI, l’agent utilisateur et le corps de la requête jusqu’à 64 Ko. Depuis la version 2.1.25, il inspecte le corps à la fois au format brut et décodé en URL ; ainsi, une Payload encodée en pourcentage à l’intérieur d’un lot JSON (SLEEP%283%29 au lieu de SLEEP() est détectable par les mêmes signatures. La documentation du pare-feu aborde le moteur de manière plus approfondie.

Le chemin de création de l’administrateur dépend de UNION SELECT, la règle gratuite waf_sqli_union bloquait déjà avant cette version. La version 2.1.25 ajoute deux règles structurelles qui ne dépendent pas de la présence des mots-clés SQL dans le corps de la requête.

waf_rest_batch_desync correspond à la catégorie des chemins de sous-requêtes mal formés rejetés par un analyseur par lots, tels que deux barres obliques ou plus en début de chemin, ou un schéma avec un hôte vide. Il cible directement le « desync primer » lui-même ; par conséquent, modifier le jeton ne permet pas de le contourner.
waf_rest_batch_nested correspond à l’invariant que l’attaque ne peut pas supprimer, à savoir une sous-requête dont le corps est lui-même un lot ("body":{…"requests":[).

Ces deux règles sont de Paranoia Level 1 et sont toutes deux protégées contre les retours en arrière catastrophiques. Elles sont intégrées à la base de référence hors ligne fournie avec chaque installation ; la protection est donc active dès la mise à jour du plugin, sans qu’aucune Rule Sync ne soit nécessaire. Pour les sites « Professional », ces mêmes règles sont publiées sur l’API du jeu de règles signé et sont disponibles dès la synchronisation suivante. Lors du test de validité public, les six étapes ont toutes été rejetées sur les niveaux « Free » et « Professional », et un corpus de False Positives composé d’appels par lots normaux, d’URL relatives au protocole et d’URL absolues n’a présenté aucun problème.

Que faire maintenant ?

Mettez à jour le cœur de WordPress sur l’ensemble de vos sites. Mettez à jour ReportedIP Hive vers la version 2.1.25 depuis la section « Plugins », ou cliquez sur « Vérifier les mises à jour » pour le télécharger immédiatement. Les sites Free et non synchronisés reçoivent les deux règles lors de la mise à jour du plugin. Les sites Professional synchronisés les reçoivent lors de la prochaine synchronisation des règles, ou instantanément en cliquant sur « Synchroniser maintenant ». Si vous gérez de nombreux sites, appliquez d’abord le correctif du cœur et laissez le pare-feu assurer la protection pendant sa propagation.

Foire aux questions

Le plugin ReportedIP Hive remplace-t-il la mise à jour du cœur de WordPress ?

Non. C’est le correctif du noyau qui résout le problème. Hive bloque le modèle de requête en amont du code vulnérable, ce qui protège la fenêtre de correction et détecte les variantes, mais cela ne supprime pas le bogue sous-jacent.

Les sites Free sont-ils protégés contre wp2shell ?

Oui. Ces deux nouvelles règles sont de niveau « Paranoia Level 1 » et sont incluses dans la configuration de base ; elles s’appliquent donc à toutes les formules dès que le plugin passe à la version 2.1.25.

Les nouvelles règles vont-elles bloquer les requêtes REST par lots légitimes ?

Non. Ils ciblent les chemins de sous-requêtes mal formés et un lot imbriqué dans le corps d’une sous-requête. Les appels de lots normaux ne produisent pas ce type de structure, ce que le corpus de False Positives a confirmé.

Les jours qui ont entouré la divulgation apparaissent dans nos données de télémétrie : les tentatives d’accès aux points de terminaison REST par lots ont augmenté à la mi-juillet. Le WordPress Attack Report pour la période mai-juillet 2026 place wp2shell dans son contexte, aux côtés de 1,69 million d’autres attaques, et la plateforme « Threat Reports » assure le suivi de ces données chaque trimestre.