Faille critique WordPress (wp2shell) : mets ton site à jour maintenant

Ce qui s’est passé

Le 17 juillet 2026, WordPress.org a publié en urgence la version 7.0.2. Ce n’est pas une mise à jour de confort : elle corrige deux vulnérabilités de sécurité, dont une classée critique.

La plus grave a été baptisée wp2shell par les chercheurs qui l’ont trouvée. Son identifiant officiel est CVE-2026-63030. Elle a été signalée par Adam Kues, d’Assetnote/Searchlight Cyber.

Ce qui la rend sérieuse tient en une phrase : elle permet d’exécuter du code à distance sans avoir besoin de se connecter. Pas de mot de passe à deviner, pas de compte à compromettre, pas de plugin exotique à installer. Une installation WordPress standard, avec sa configuration par défaut, est exploitable.

En clair, ça veut dire quoi

Le terme technique est « RCE pré-authentification » (Remote Code Execution). Traduit en langage de dirigeant : un attaquant qui n’a aucun accès légitime à ton site peut y faire exécuter ses propres instructions.

À partir de là, il peut typiquement :

• créer un compte administrateur pour revenir quand il veut ;
• déposer des fichiers sur ton serveur (portes dérobées, pages de spam) ;
• lire ta base de données, donc tes utilisateurs, tes commandes, tes formulaires ;
• rediriger tes visiteurs, injecter du contenu, ou utiliser ton hébergement pour attaquer ailleurs.

Ce n’est pas un défaut d’affichage. C’est une prise de contrôle.

Comment ça marche (sans donner de mode d’emploi)

La faille combine deux problèmes distincts qui, pris séparément, seraient nettement moins graves.

Le premier concerne l’API REST de WordPress, et plus précisément un point d’entrée nommé /wp-json/batch/v1. Cette route existe dans le cœur de WordPress depuis la version 5.6 et elle est active par défaut. Elle sert à regrouper plusieurs requêtes en une seule. Le souci : une confusion sur la manière dont la route est interprétée, ce qui permet de faire passer une requête pour autre chose que ce qu’elle est.

Le second est une injection SQL, c’est-à-dire la possibilité de glisser des instructions dans une requête envoyée à la base de données.

Enchaînés, les deux permettent d’aller de « visiteur anonyme » à « contrôle du site ». C’est cet enchaînement qui vaut la classification critique.

Les chercheurs ont volontairement retenu les détails techniques complets au moment de la divulgation, précisément pour laisser aux sites le temps de se mettre à jour.

Ton site est-il concerné ?

Voici les versions touchées et les versions corrigées :

Il y a en effet une seconde vulnérabilité dans cette publication : CVE-2026-60137, une injection SQL signalée par TF1T, dtro et haongo. Elle est corrigée dans 7.0.2, 6.9.5 et 6.8.6.

C’est pour cette raison que la branche 6.8 reçoit une mise à jour (6.8.6) alors qu’elle n’est pas vulnérable à wp2shell : elle corrige uniquement la seconde faille.

Les versions antérieures à 6.8 ne sont pas concernées par ces deux vulnérabilités. Cela ne veut évidemment pas dire qu’elles sont sûres : elles traînent leurs propres failles non corrigées.

Faut-il paniquer ?

Non. Mais il faut agir aujourd’hui, pas la semaine prochaine.

Soyons précis sur ce qui est établi et ce qui ne l’est pas :

• Établi : la faille est réelle, critique, et corrigée. WordPress.org a jugé la situation suffisamment sérieuse pour forcer les mises à jour automatiques sur les sites en version vulnérable, ce qui est rare.
• Non établi : au moment de la publication des correctifs, aucune exploitation active n’était rapportée et les chercheurs n’avaient pas publié le détail de l’attaque.

Autrement dit : la fenêtre est encore ouverte, mais elle se referme. Quand une faille de ce calibre est publiée, la rétro-ingénierie du correctif par des acteurs malveillants se compte en jours, parfois en heures. Le fait que les détails soient retenus ralentit le processus, il ne l’empêche pas.

Méfie-toi des articles qui affirment déjà une « exploitation massive en cours ». À la date de rédaction, ce n’est pas documenté.

Quoi faire, dans l’ordre

1. Vérifie ta version. Connecte-toi à ton administration WordPress. La version est affichée en bas à droite du tableau de bord, ou dans « Tableau de bord » puis « Mises à jour ».

2. Sauvegarde avant de toucher à quoi que ce soit. Fichiers et base de données. Une mise à jour se passe bien dans l’immense majorité des cas, mais une sauvegarde datée de ce matin coûte cinq minutes et évite une très mauvaise journée.

3. Mets à jour. Dans « Tableau de bord » puis « Mises à jour », lance la mise à jour du cœur de WordPress vers 7.0.2 (ou 6.9.5, ou 6.8.6 selon ta branche).

4. Vérifie que la mise à jour a bien été appliquée. Ne te fie pas au message de succès : recharge la page des mises à jour et confirme le numéro de version.

5. Contrôle ton site. Page d’accueil, formulaire de contact, tunnel de commande si tu vends en ligne, connexion à l’administration. Cinq minutes de vérification manuelle.

6. Regarde s’il y a des traces suspectes. Comptes administrateurs que tu ne reconnais pas, fichiers récemment modifiés, activité inhabituelle dans tes journaux d’accès.

Si les mises à jour automatiques sont désactivées

Beaucoup de sites professionnels désactivent les mises à jour automatiques, souvent pour de bonnes raisons (éviter qu’une mise à jour casse une personnalisation sans surveillance).

Le problème : dans un cas comme celui-ci, cette précaution se retourne contre toi. Le forçage décidé par WordPress.org ne s’appliquera pas si tu as bloqué le mécanisme dans ton wp-config.php ou via un plugin.

Si tu es dans ce cas, tu dois mettre à jour manuellement, et vite.

Ce que ça dit de la maintenance d’un site

Une faille comme wp2shell n’est pas un accident isolé, c’est le fonctionnement normal d’un logiciel utilisé par une part énorme du web. Le cœur de WordPress est plutôt bien tenu et le correctif est arrivé vite.

La vraie question n’est pas « est-ce que WordPress est sûr », mais « combien de temps mon site reste-t-il vulnérable après la publication d’un correctif ». Sur les sites que nous reprenons en maintenance, ce délai se compte souvent en mois. C’est là que se joue le risque réel, bien plus que dans la gravité théorique d’une CVE.

Si personne ne surveille les mises à jour de ton site, ce n’est pas cette faille précise qui devrait t’inquiéter, mais la prochaine.

Besoin d’un coup de main

Si tu n’es pas sûr de ta version, si la mise à jour échoue, ou si tu veux qu’on vérifie qu’aucune trace suspecte ne traîne sur ton site, écris-nous. Un contrôle de sécurité prend moins d’une heure et évite des semaines de réparation.