wp2shell, la faille critique dans le cœur de WordPress qui touche potentiellement tous les sites

Le 17 juillet 2026, WordPress a publié en urgence la version 7.0.2. Pas une mise à jour de confort avec trois retouches de blocs Gutenberg : une rustine de sécurité qui bouche une faille exploitable sans le moindre identifiant, à distance, sur potentiellement tous les sites tournant sous 6.9 ou 7.0. Et le pire, c'est que les attaques ont commencé avant même que la plupart des administrateurs aient entendu parler du problème.

La bonne nouvelle : WordPress a forcé la mise à jour automatique. La mauvaise : « forcée » ne veut pas dire « garantie sur votre site », et beaucoup d'installations passent entre les mailles. Voici pourquoi cette faille (nommée wp2shell) est plus grave que la moyenne, et comment vérifier en deux minutes que votre site est bien passé en 7.0.2.

L'essentiel à retenir ℹ️ WordPress 7.0.2, publié le 17 juillet 2026, corrige une faille critique du cœur surnommée wp2shell (CVE-2026-63030) : une injection SQL non authentifiée via l'API REST qui mène à la prise de contrôle complète du site, et qui est déjà activement exploitée. Les correctifs existent aussi pour les branches précédentes, en 6.9.5 et 6.8.6. Vérifiez votre version dans Tableau de bord > Mises à jour et mettez à jour sans attendre.

wp2shell, une faille dans le cœur, pas dans un plugin : pourquoi ça change tout

D'habitude, quand je vous parle d'une alerte de sécurité WordPress, c'est un plugin qui est en cause. Un formulaire de contact mal codé, une extension de cache abandonnée, un thème premium piraté. Le réflexe est simple : vous identifiez l'extension fautive, vous la mettez à jour ou vous la désactivez, et c'est réglé. Selon le rapport Patchstack, plus de 90 % des failles WordPress vivent dans les plugins et les thèmes.

Là, c'est différent. La faille est dans le cœur de WordPress, le code que tout le monde fait tourner, quels que soient vos plugins ou votre thème. Il n'y a rien à identifier, rien à désactiver. Si votre site est en WordPress 6.9, 7.0 ou 7.0.1 et qu'il n'est pas patché, il est concerné. Point. C'est exactement ce qui rend ce type de faille rare et redoutable : la surface d'attaque, c'est l'ensemble de l'écosystème d'un coup.

https://www.youtube.com/watch?v=4Fj1V2tkJYg

Ce que corrige la 7.0.2, concrètement

La version 7.0.2 bouche deux trous, et c'est leur combinaison qui fait mal.

Le premier, référencé CVE-2026-63030, est classé critique. Il touche le point d'entrée /wp-json/batch/v1, une fonction de l'API REST introduite en WordPress 6.9 qui permet de grouper plusieurs requêtes en une seule. Un problème de « confusion de routes » permet à un attaquant d'envoyer une requête validée selon un modèle mais exécutée selon un autre. Traduction : il glisse une injection SQL non authentifiée là où WordPress croit traiter une requête inoffensive. Au bout de la chaîne, on parle d'exécution de code à distance et de prise de contrôle complète du site. Dans la communauté, la faille a déjà son surnom : wp2shell. Elle a été découverte par Adam Kues, chercheur chez Searchlight Cyber.

Le second, CVE-2026-60137, est de sévérité élevée. Il vient d'une injection SQL dans le paramètre author__not_in de WP_Query, le moteur de requêtes de WordPress. En clair, une chaîne mal filtrée pouvait se retrouver directement dans une requête à la base de données.

Sachez que ces attaques ne sont pas théoriques. Patchstack indique avoir observé des tentatives d'exploitation actives dans ses journaux dès la divulgation. Le 21 juillet, l'agence américaine CISA a inscrit les deux CVE à son catalogue KEV, la liste officielle des vulnérabilités exploitées dans la nature. Quand une faille non authentifiée est déjà chassée sur le terrain, chaque heure sans patch compte.

Petite mise au point sur les numéros de version

Il y a eu de la confusion dans les premières remontées, alors soyons clairs sur qui doit installer quoi.

Si vous êtes sur la branche 7.0, la version corrigée est la 7.0.2. Mais WordPress a aussi rétroporté les correctifs sur les branches plus anciennes encore maintenues :

WordPress 6.9.5 corrige les deux failles. WordPress 6.8.6 corrige l'injection SQL de WP_Query. La confusion de routes ne la concerne pas, puisque le point d'entrée batch fautif est arrivé avec la 6.9.

Les versions antérieures à 6.8 ne sont pas touchées par ces deux failles précises. Ce qui ne veut évidemment pas dire qu'un site sous WordPress 6.4 est un endroit sûr où vivre, mais c'est un autre sujet.

Comment vérifier que votre site est bien passé en 7.0.2

WordPress a activé la mise à jour forcée via le système d'auto-update pour les versions vulnérables. Sur le papier, votre site aurait dû se patcher tout seul dans les heures qui ont suivi le 17 juillet. En pratique, je ne fais jamais confiance à un « ça devrait être bon ». On vérifie.

Premier réflexe : le tableau de bord. Connectez-vous à votre admin, puis allez dans Tableau de bord > Mises à jour. La version installée est affichée en haut. Vous devez lire 7.0.2 (ou 6.9.5 / 6.8.6 selon votre branche). Vous pouvez aussi jeter un œil au pied de page de l'admin, à droite, qui affiche le numéro de version.

Si vous n'êtes pas à jour, cliquez sur le bouton de mise à jour manuelle depuis cette même page Mises à jour. Avant de le faire, une sauvegarde complète (fichiers + base de données) reste la règle de base. Une mise à jour du cœur se passe bien 999 fois sur 1000, mais c'est précisément la millième qui vous gâche la soirée.

Si les mises à jour automatiques du cœur sont désactivées sur votre site, vous ne recevrez pas le correctif tout seul. C'est fréquent chez les freelances et les agences qui verrouillent les versions pour maîtriser leurs déploiements. Deux cas de figure. Soit vous les avez coupées via une constante dans wp-config.php du type define( 'WP_AUTO_UPDATE_CORE', false );, et il faut alors déclencher la mise à jour à la main depuis l'admin ou via WP-CLI. Soit c'est un plugin de gestion de mises à jour qui pilote ça, et vous passez par son interface. Dans tous les cas, ne restez pas en version vulnérable en attendant votre prochaine fenêtre de maintenance : cette faille ne mérite pas d'attendre.

Pour ceux qui sont à l'aise en ligne de commande, un wp core version vous donne la version installée en une seconde, et wp core update déclenche la mise à jour.

Et si mon site a déjà été visité ?

C'est la question qui fâche. Une mise à jour empêche une future exploitation, elle n'efface pas une compromission qui aurait déjà eu lieu. Si votre site tournait en version vulnérable pendant plusieurs jours, surtout s'il est populaire ou exposé, une vérification s'impose.

Le premier signe à traquer, c'est la présence de comptes administrateurs que vous ne reconnaissez pas. Allez dans Utilisateurs > Tous les utilisateurs, filtrez sur le rôle Administrateur, et vérifiez chaque ligne. Un compte créé récemment que vous n'avez pas ajouté vous-même est un drapeau rouge immédiat. Surveillez aussi l'apparition de fichiers PHP inconnus à la racine ou dans wp-content, et tout comportement anormal (redirections, pages inconnues, ralentissements). Au moindre doute, un scan avec un outil de sécurité réputé et, si nécessaire, l'aide d'un professionnel de la remédiation valent mieux qu'un nettoyage approximatif.

Ce qu'il faut faire en sortant de cet article

Trois actions, dans l'ordre :

Vérifiez votre version dans Tableau de bord > Mises à jour. Vous devez être en 7.0.2, 6.9.5 ou 6.8.6. Si vous n'y êtes pas, sauvegardez puis mettez à jour immédiatement, sans attendre votre prochaine maintenance planifiée. Contrôlez vos comptes administrateurs si votre site est resté exposé plusieurs jours.

Ma recommandation, si je ne devais en garder qu'une : réactivez les mises à jour automatiques du cœur si vous les aviez coupées. Je comprends l'envie de tout maîtriser, mais une faille non authentifiée activement exploitée dans le cœur de WordPress, c'est exactement le scénario où l'auto-update vous sauve la mise pendant que vous dormez. Les correctifs mineurs de sécurité ne cassent quasiment jamais un site. Cette fois, ils l'ont protégé.

Foire aux questions Comment savoir en trente secondes si mon site est vulnérable ?+ Regardez votre version dans Tableau de bord > Mises à jour ou dans le pied de page de l'admin, en bas à droite. Si vous n'êtes pas en 7.0.2, 6.9.5 ou 6.8.6, votre site est vulnérable et doit être mis à jour tout de suite. Le testeur wp2shell.com est-il fiable ?+ Il a été publié par Searchlight Cyber, l'équipe du chercheur Adam Kues qui a découvert la faille, pour vérifier si un site est exposé. C'est un bon indicateur, mais il ne remplace ni la mise à jour ni le contrôle de vos comptes administrateurs : un site déjà compromis ne se répare pas avec un simple test. Mes mises à jour automatiques me protègent-elles sans rien faire ?+ En principe oui, puisque WordPress a forcé le correctif via l'auto-update. Mais beaucoup de sites d'agence désactivent les mises à jour automatiques du cœur via wp-config.php ou un plugin de gestion. Dans ce cas, rien ne s'installe tout seul : vérifiez et lancez la mise à jour à la main. Les versions plus anciennes que 6.8 sont-elles concernées ?+ Pas par ces deux failles précises, introduites plus récemment. Mais faire tourner un site sous une version aussi ancienne vous expose à quantité d'autres vulnérabilités corrigées depuis longtemps. La vraie réponse reste : passez à une version maintenue. Faut-il bloquer l'API REST pour se protéger de wp2shell ?+ Non, ce serait contre-productif : Gutenberg et de nombreux plugins reposent sur l'API REST, et un blocage complet casserait votre admin. La seule protection fiable reste la mise à jour vers 7.0.2, 6.9.5 ou 6.8.6. Un pare-feu applicatif peut filtrer les requêtes malveillantes en attendant, pas plus.