Faille WordPress WP2Shell : mettez à jour immédiatement

Si vous gérez un site WordPress, il y a de fortes chances que vous ayez entendu parler de "WP2Shell" ces dernières semaines. Cette faille, révélée en juillet 2026, ne concerne pas un plugin obscur ou un thème mal codé : elle touche le cœur même de WordPress. Explications, et pourquoi une surveillance proactive de vos mises à jour est plus indispensable que jamais.

Qu'est-ce que WP2Shell ?

WP2Shell n'est pas une faille unique, mais deux vulnérabilités distinctes que des chercheurs en sécurité ont réussi à chaîner :

• CVE-2026-63030 : un défaut de routage dans le point de terminaison de traitement par lots de l'API REST de WordPress (/wp-json/batch/v1).
• CVE-2026-60137 : une injection SQL présente elle aussi dans le noyau de WordPress.

Combinées, ces deux failles permettent à un attaquant, sans aucun compte ni identifiant, de prendre le contrôle total d'un site WordPress à jour dans ses seules dépendances par défaut. Pas besoin de plugin vulnérable, pas besoin de configuration particulière, un simple site "de base" suffit.

Le surnom "WP2Shell" résume bien le problème : en quelques requêtes bien construites, un inconnu peut transformer une installation WordPress standard en porte d'entrée pour déposer un shell malveillant et exécuter n'importe quel code sur le serveur.

Une découverte assistée par l'IA

Détail notable de cette affaire : la faille n'a pas été trouvée en épluchant manuellement des milliers de lignes de code. Les chercheurs de Searchlight Cyber, à l'origine de la découverte, ont utilisé un modèle d'intelligence artificielle pour analyser le code source de WordPress et identifier la chaîne de vulnérabilités. C'est un signe des temps : la recherche de failles de sécurité s'appuie de plus en plus sur l'IA pour explorer des bases de code volumineuses et repérer des enchaînements de bugs qu'un audit humain classique pourrait mettre bien plus longtemps à détecter.

Le rapport coût/impact donne le vertige : le chercheur à l'origine de la découverte estime avoir dépensé environ 25 dollars de tokens IA pour trouver cette chaîne de failles, sur une dizaine d'heures de travail. Or, ce type de vulnérabilité - une exécution de code à distance pré-authentification sur WordPress - se négocie habituellement jusqu'à 500 000 dollars sur le marché des courtiers en exploits. Vingt-cinq dollars de calcul contre un demi-million de dollars de valeur potentielle : l'écart donne une idée de la vitesse à laquelle ce type de recherche va se démocratiser.

Quels sites sont concernés ?

Les versions touchées sont :

• WordPress 6.9.0 à 6.9.4
• WordPress 7.0.0 à 7.0.1

Sachant que WordPress fait tourner une part très importante des sites web dans le monde (~40% en 2026), l'ampleur potentielle de cette faille est considérable. On parle de dizaines, voire de centaines de millions d'installations concernées.

Une gravité maximale, une exploitation quasi immédiate

Cette vulnérabilité a été classée avec un score de gravité proche du maximum. Pire encore : l'exploitation active a commencé quasiment dès la divulgation publique. En quelques jours seulement, des dizaines d'outils d'exploitation automatisés ont circulé, et les autorités de cybersécurité américaines (CISA) ont classé ces deux CVE parmi les vulnérabilités activement exploitées dans la nature.

Des études menées à l'époque montraient qu'une majorité des organisations utilisant WordPress avaient au moins une instance vulnérable au moment de la divulgation, et qu'une part significative de ces sites vulnérables étaient directement exposés sur Internet, donc à portée immédiate des attaquants.

Le rôle des hébergeurs : un filet de sécurité pour une partie du web

Un aspect important de cette crise mérite d'être souligné : tous les sites WordPress n'ont pas été exposés de la même façon. Plusieurs grands hébergeurs et prestataires d'infrastructure, parmi lesquels Automattic, Bluehost, Cloudflare, GoDaddy, Hostinger et WP Engine, ont reçu un accès anticipé à l'information, environ 24 heures avant la divulgation publique, via un canal privé et sous des règles strictes de confidentialité. Cela leur a permis de préparer et de déployer des correctifs ou des règles de pare-feu applicatif dès l'annonce officielle, parfois avant même que les propriétaires de sites concernés n'aient connaissance du problème.

Combiné au système de mises à jour automatiques forcées activé par WordPress.org, ce filet a permis de réduire sensiblement la fenêtre d'exposition pour une grande partie des sites hébergés chez ces acteurs. Mais cette protection n'est pas universelle : les sites dont les mises à jour automatiques sont désactivées, ceux déployés via des pipelines personnalisés qui contournent le système de mise à jour natif, ou ceux hébergés chez des prestataires plus petits n'ayant pas reçu cet accès anticipé, sont restés pleinement exposés. D'où l'importance de vérifier soi-même la version installée plutôt que de supposer que "quelqu'un d'autre s'en est occupé".

Chronologie de la crise

• 16 juillet 2026 : environ 24 heures avant la divulgation publique, plusieurs grands hébergeurs et prestataires d'infrastructure reçoivent un accès anticipé à l'information.
• 17 juillet : divulgation publique de la faille et publication simultanée du correctif (WordPress 6.9.5 et 7.0.2). WordPress et les partenaires informés déploient une mise à jour automatique forcée pour les sites concernés, signe de la gravité de la situation.
• 19 juillet : plus d'une vingtaine de preuves de concept (PoC) publiques recensées, à peine deux jours après la divulgation.
• 21 juillet : les deux failles sont ajoutées au catalogue des vulnérabilités activement exploitées de la CISA.
• 22 juillet : publication des détails techniques complets de la chaîne d'exploitation, ce qui a encore accéléré la diffusion d'outils d'attaque.

Ce calendrier illustre une réalité que l'on observe de plus en plus souvent : le temps entre la divulgation d'une faille critique et son exploitation massive se compte désormais en heures, pas en semaines.

Que faire si vous êtes concerné ?

1. Vérifiez immédiatement la version de WordPress utilisée sur votre site.
2. Mettez à jour vers la version 6.9.5, 7.0.2, ou une version ultérieure.
3. Si une mise à jour immédiate n'est pas possible, une mesure temporaire consiste à bloquer l'accès anonyme au point de terminaison concerné au niveau de votre pare-feu applicatif.
4. Inspectez votre site à la recherche de signes de compromission antérieurs à la mise à jour : comptes administrateurs inconnus, fichiers suspects, plugins que vous n'avez pas installés. Il existe également des utilitaires vérifiant automatiquement les signes majeurs.

Pourquoi une gestion proactive change tout

L'épisode WP2Shell illustre parfaitement pourquoi attendre de "penser à faire la mise à jour" n'est plus une stratégie viable. Quand une faille critique touche le cœur de WordPress et qu'elle est exploitée en masse dans les jours qui suivent sa divulgation, chaque heure sans correctif compte.

Sources

• WordPress.org, Version 7.0.2 - Release Notes et WordPress 7.0.2 Release - WordPress News
• Searchlight Cyber, Exploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6 Sol Ultra and $25