Faille wp2shell (CVE-2026-63030) : mettez votre site WordPress à jour maintenant

Le 17 juillet 2026, l’équipe de sécurité de WordPress a publié en urgence les versions
7.0.2 et 6.9.5 pour corriger une vulnérabilité critique du cœur du
CMS, surnommée « wp2shell » et référencée CVE-2026-63030. Elle permet
une exécution de code à distance (RCE) : un attaquant peut prendre le contrôle complet
d’un site non mis à jour, sans identifiant, sans clic d’un administrateur, sans complicité interne.
Le CERT-FR — le centre gouvernemental de veille rattaché à l’ANSSI — a publié une alerte officielle,
et une preuve de concept circule publiquement. Si votre site tourne encore sur une version antérieure,
cet article est à appliquer aujourd’hui, pas ce week-end. Voici pourquoi, et comment, en détail.

La chronologie : pourquoi chaque jour compte

Ce déroulé n’a rien d’exceptionnel : c’est le cycle de vie standard d’une faille majeure. Dès qu’un
correctif sort, les attaquants le décompilent pour comprendre ce qu’il corrige — on appelle cela le
patch diffing. La publication du correctif est donc, paradoxalement, le coup d’envoi des
attaques contre ceux qui ne l’appliquent pas.

Comment fonctionne wp2shell (expliqué simplement)

« wp2shell » n’est pas une faille unique mais une chaîne d’exploitation : deux
faiblesses distinctes du cœur de WordPress qui, prises isolément, seraient d’une gravité modérée, mais
qui s’emboîtent. Le nom résume le résultat : de WordPress à un shell — un accès en
ligne de commande sur votre serveur.

Le schéma, vulgarisé :

• →Étape 1 — la porte entrebâillée. La première faiblesse permet à un visiteur non authentifié de faire exécuter à WordPress une opération interne normalement réservée : c’est le point d’appui.
• →Étape 2 — le pied dans la porte. La seconde faiblesse est utilisée depuis ce point d’appui pour écrire du contenu contrôlé par l’attaquant là où il ne devrait jamais pouvoir écrire : dans un fichier exécuté par le serveur.
• →Étape 3 — le shell. Ce fichier devient une porte dérobée (webshell) : une page cachée depuis laquelle l’attaquant pilote le serveur — lecture de la base de données, création de comptes, installation de logiciels, rebond vers d’autres sites du même hébergement.

C’est ce chaînage qui rend la faille critique : chaque maillon contourne une protection différente,
et le résultat final équivaut à donner les clés du serveur. Une fois le webshell déposé,
mettre WordPress à jour ne sert plus à rien pour l’expulser : la porte d’origine est
refermée, mais l’intrus est déjà à l’intérieur avec son propre passe-partout.

Suis-je concerné ? Le point par situation

Vous êtes vulnérable si votre site utilise une version de WordPress antérieure à 7.0.2
(ou à 6.9.5 pour la branche 6.9). Pour vérifier : Tableau de bord → Mises à jour —
la version installée s’affiche en haut de page. Ensuite, selon votre cas :

• Mises à jour automatiques activées (réglage par défaut) : les versions de sécurité se déploient normalement seules sous quelques heures. Mais vérifiez quand même : un site en erreur PHP, un disque plein, un fichier verrouillé ou une version trop ancienne peuvent bloquer la mise à jour silencieusement. Nous croisons régulièrement des sites persuadés d’être à jour qui ne le sont plus depuis des mois.
• Mises à jour gérées par l’hébergeur (offres « WordPress géré ») : la plupart des hébergeurs sérieux ont déployé le correctif dans les 48 h. Vérifiez la version affichée dans votre admin plutôt que de le supposer.
• Site géré par un prestataire : demandez une confirmation écrite, avec le numéro de version installée. C’est une demande normale, pas une marque de défiance.
• Site resté sur une vieille branche (6.x ancienne, 5.x) : le saut de plusieurs versions majeures peut casser le thème ou des extensions. C’est le scénario où il faut un environnement de test et un accompagnement — mais ne rien faire est le pire des choix : ces branches cumulent wp2shell et toutes les failles corrigées depuis.
• Site vitrine « sans données sensibles » : vous êtes concerné aussi. Les attaquants ne cherchent pas vos données, ils cherchent votre serveur — pour héberger du phishing, envoyer du spam ou piéger vos visiteurs (voir plus bas).

Le plan d’action, étape par étape

1. Sauvegardez avant tout

Une sauvegarde complète — fichiers + base de données — stockée ailleurs que sur le
serveur du site (votre poste, un cloud, l’espace de sauvegarde de l’hébergeur). Elle sert à deux
choses : revenir en arrière si la mise à jour se passe mal, et conserver un état analysable si le site
s’avère déjà compromis. Ne l’écrasez pas dans les jours qui suivent.

2. Mettez à jour le cœur WordPress

Tableau de bord → Mises à jour → installez la 7.0.2 (ou la 6.9.5 si vous devez rester en 6.9).
L’opération prend quelques minutes. Profitez-en pour mettre à jour thème et extensions :
les attaquants enchaînent volontiers plusieurs failles, et un cœur corrigé ne protège pas d’un plugin
troué.

3. Cherchez les signes d’une intrusion déjà survenue

C’est l’étape que presque tout le monde saute, et c’est la plus importante : la faille est exploitée
depuis des semaines. Mettre à jour ferme la porte — cela ne fait pas sortir celui qui est déjà entré.
Passez en revue, dans l’ordre :

• →Les utilisateurs : Utilisateurs → Tous, triés par rôle. Un administrateur ou un éditeur que vous n’avez pas créé ? Des comptes aux noms génériques (admin2, support, wp-user, test) apparus récemment ?
• →Les fichiers suspects : des fichiers .php dans wp-content/uploads/ (ce dossier ne doit contenir que des médias), des fichiers récents à la racine du site, un dossier mu-plugins que vous n’avez jamais créé.
• →Les fichiers du cœur modifiés : wp-config.php (lignes ajoutées, souvent en tête ou en fin de fichier), .htaccess (règles de redirection inconnues), index.php. Un scanner comme Wordfence compare les fichiers du cœur aux originaux officiels et signale toute divergence.
• →Les tâches planifiées : avec l’extension WP Crontrol, cherchez des tâches cron inconnues — c’est un mécanisme classique pour faire « revenir » une porte dérobée supprimée.
• →Le comportement public du site : redirections vers des sites douteux (parfois uniquement sur mobile, ou uniquement depuis Google — testez en navigation privée), pages inconnues indexées (tapez site:votredomaine.fr dans Google), lenteurs soudaines, e-mails de spam émis par votre domaine.
• →Google Search Console : onglet « Sécurité et actions manuelles ». Un avertissement ici est un signal certain — et il fait chuter votre trafic tant qu’il n’est pas levé.

4. Si vous trouvez quelque chose : ne bricolez pas

Un site compromis via une RCE cache presque toujours plusieurs portes dérobées :
un webshell visible, un deuxième discret, un compte admin de secours, une tâche cron qui recrée le
tout. Supprimer le fichier trouvé donne un sentiment de sécurité trompeur — l’attaquant revient par
une autre entrée quelques jours plus tard, et chaque récidive aggrave les dégâts (blacklistage Google,
domaine marqué comme spam). Un nettoyage sérieux est méthodique : inventaire complet des fichiers
modifiés, analyse de la base de données, purge des comptes et des tâches planifiées, rotation de
tous les accès (WordPress, FTP/SSH, base de données, hébergeur), puis surveillance
rapprochée.

5. Surveillez les jours suivants

Après la mise à jour, gardez un œil sur : les connexions à l’administration, les créations de
comptes, les modifications de fichiers (les plugins de sécurité savent alerter par e-mail), et vos
statistiques de trafic — une chute brutale peut signaler un blacklistage, une hausse anormale un usage
frauduleux du serveur.

Que font les attaquants d’un site piraté ?

Comprendre la motivation aide à prendre la menace au sérieux. Un site WordPress compromis est une
ressource qui se monétise, quelle que soit sa taille :

• Spam SEO : des milliers de pages (contrefaçons, pharmacie, casino) injectées et indexées sous votre nom de domaine, souvent invisibles pour vous car servies uniquement à Google (cloaking). Votre référencement, construit sur des années, s’effondre en quelques semaines.
• Redirections malveillantes : vos visiteurs sont renvoyés vers des arnaques ou de fausses mises à jour de navigateur. Votre réputation encaisse.
• Hébergement de phishing : de fausses pages bancaires hébergées dans un recoin de votre serveur. C’est votre domaine qui finit sur les listes noires.
• Envoi de spam : votre serveur devient une machine à e-mails frauduleux, jusqu’à ce que votre hébergeur suspende le compte.
• Revente de l’accès : les accès aux sites compromis s’achètent et se vendent en gros sur des places de marché spécialisées. Votre site peut être exploité par plusieurs groupes successifs.

Aucun de ces usages ne nécessite que votre site soit « intéressant ». Il suffit qu’il soit en ligne
et vulnérable.

Questions fréquentes

Mon site est tout petit, qui irait l’attaquer ?

Personne — au sens où personne ne le choisit. Les attaques sont automatisées : des robots testent
la faille sur des millions de sites, sans distinction. Un site à 30 visiteurs par jour est aussi
exposé qu’un site à 30 000.

J’ai un plugin de sécurité, suis-je protégé ?

Partiellement. Un pare-feu applicatif (WAF) peut bloquer les tentatives d’exploitation connues, et
les éditeurs ont déployé des règles pour wp2shell. Mais ces règles arrivent après la divulgation, ne
couvrent pas toutes les variantes, et les versions gratuites les reçoivent souvent avec du retard.
Le pare-feu est un filet de sécurité, pas un substitut à la mise à jour.

Je ne peux pas mettre à jour tout de suite (site fragile, prestataire absent…)

Réduisez l’exposition en attendant : sauvegarde immédiate, activation du pare-feu de votre plugin
de sécurité, et planifiez la mise à jour sous 48 h maximum, en environnement de test si le site est
critique. « Plus tard » sans date, face à une faille activement exploitée, c’est accepter le risque
d’un nettoyage bien plus coûteux que la mise à jour.

Comment savoir si mon site a déjà été exploité ?

Aucun signe visible ne prouve l’absence d’intrusion — les attaquants soignent leur discrétion.
Croisez les vérifications de l’étape 3 ci-dessus avec un scan complet (Wordfence, Sucuri). En cas de
doute persistant, un audit par un professionnel tranche : l’analyse des fichiers, de la base et des
journaux du serveur ne laisse pas beaucoup de place au doute.

La leçon de fond

wp2shell restera comme la faille marquante de 2026 parce qu’elle touche le cœur de WordPress — un
événement rare. Mais le mécanisme qui décide qui se fait pirater est toujours le même : le
délai entre la publication d’un correctif et son application. Trois habitudes
raccourcissent ce délai à presque rien :

• →Mises à jour appliquées sous 24-48 h pour les correctifs de sécurité, toujours après sauvegarde ;
• →Sauvegardes externalisées et testées — une sauvegarde jamais restaurée est une hypothèse, pas une garantie ;
• →Surveillance active — être alerté quand un fichier change ou quand le site tombe, plutôt que l’apprendre par un client.

C’est très exactement le rôle d’une maintenance WordPress
sérieuse : ces trois réflexes, appliqués pour vous, chaque semaine — pour que la prochaine alerte
CERT-FR soit un non-événement pour votre site.

Sources : alerte CERT-FR CERTFR-2026-ALE-007 (ANSSI) ; annonces de sécurité WordPress 7.0.2 /
6.9.5 ; Cybermalveillance.gouv.fr, AlerteCyber juillet 2026.