Faille wp2shell : vérifier si votre site WordPress est compromis

L'essentiel en 30 secondes

• Le 17 juillet 2026, WordPress a publié trois versions d'urgence et activé les mises à jour forcées à l'échelle mondiale
• La faille, surnommée wp2shell, permet à un visiteur anonyme d'exécuter du code sur votre serveur, sans compte et sans aucun plugin tiers
• Les correctifs sont les versions 6.8.6, 6.9.5 et 7.0.2
• L'exploitation active a été confirmée moins de 48 heures après la divulgation
• Le correctif ferme la porte. Il n'expulse pas ce qui est déjà entré.

Le 17 juillet 2026, WordPress a publié trois versions d'urgence et activé les mises à jour forcées à l'échelle mondiale.

La plupart des propriétaires de sites au Québec ne l'ont jamais su.

Aucun courriel, aucune alerte, aucune manoeuvre à faire. Le correctif est arrivé seul pendant la nuit, le tableau de bord est resté vert, et la vie a continué.

C'est exactement le problème.

Qu'est-ce que la faille wp2shell?

wp2shell n'est pas une faille de plugin. C'est une faille du coeur de WordPress.

Elle a été découverte par Adam Kues, de Searchlight Cyber, et divulguée le 17 juillet 2026.

Ce n'est pas non plus une seule faille, mais une chaîne de deux vulnérabilités :

• CVE-2026-60137 : une injection SQL dans le moteur de requêtes de WordPress
• CVE-2026-63030 : une confusion de route dans l'API REST de traitement par lot

Prises séparément, elles sont limitées. Enchaînées, elles permettent à un visiteur anonyme, sans compte, sans mot de passe, sans aucune interaction de votre part, d'exécuter du code sur votre serveur.

Sur une installation WordPress standard. Sans aucun plugin tiers.

Quelles versions étaient touchées :

L'exploitation active a été confirmée moins de 48 heures après la divulgation. Les deux failles ont été ajoutées au catalogue des vulnérabilités activement exploitées de la CISA américaine le 21 juillet.

Selon Wiz Research, 60 % des organisations utilisant WordPress avaient au moins une instance vulnérable au moment de la publication, et 25 % exposaient un serveur vulnérable directement à Internet. Ces chiffres ont chuté à 50 % et 10 % dans les 24 heures suivantes, à mesure que les correctifs se sont appliqués.

Ce que les attaquants ont fait, une fois entrés : déposer des portes dérobées en fichier, installer des extensions malveillantes déguisées en plugins légitimes, énumérer les comptes administrateurs, et tenter de lire le fichier de configuration du site pour en extraire les identifiants de base de données et les clés de sécurité.

Mon site s'est mis à jour tout seul. Suis-je protégé?

Vous êtes protégé contre une nouvelle intrusion. Vous n'avez aucune garantie sur ce qui s'est passé avant.

Un correctif ferme une porte.

Il n'expulse pas quelqu'un qui était déjà entré.

Entre le moment où la faille est devenue publique et le moment où le correctif s'est appliqué sur votre site, il y a eu une fenêtre. Quelques heures pour certains, plusieurs jours pour d'autres, selon la configuration de l'hébergement et selon que les mises à jour automatiques étaient réellement fonctionnelles.

Pendant cette fenêtre, des balayages automatisés ont ratissé Internet à grande échelle.

Si un attaquant a déposé une porte dérobée pendant cette période, elle est toujours là aujourd'hui. Sur un site parfaitement à jour. Avec un tableau de bord parfaitement vert.

Une porte dérobée n'a pas besoin d'exploiter une faille pour fonctionner. Elle a sa propre entrée.

Pourquoi un scan de sécurité ne répond pas à la question?

Un scan de sécurité WordPress opère à l'intérieur du périmètre WordPress.

C'est utile, et c'est nécessaire. Mais quatre zones lui échappent par construction, et ce sont précisément celles qui comptent après cette faille.

1. Votre point de restauration était-il propre?

Si vous avez restauré une sauvegarde, toute votre remédiation repose sur une hypothèse : que cette sauvegarde précède l'intrusion.

Si l'intrusion a eu lieu avant le point de restauration, vous avez ramené la compromission avec vous.

Une porte dérobée en fichier ou en base de données ne dépend d'aucun identifiant. Changer les mots de passe ne la ferme pas.

La bonne nouvelle : cette attaque laisse des traces caractéristiques dans les journaux d'accès du serveur. L'intrusion est datable précisément. On peut confirmer, preuves à l'appui, que le point de restauration était propre, ou démontrer qu'il ne l'était pas.

2. Qu'est-ce qui a été extrait de votre base de données?

C'est le point le plus souvent négligé.

L'injection SQL de la chaîne donne accès à la base de données. Donc aux empreintes de mots de passe administrateurs, exploitables hors ligne.

Et une fois l'exécution de code obtenue, Wiz a observé des tentatives directes de lecture du fichier de configuration de WordPress, pour en extraire les identifiants de base de données et les clés d'authentification.

Une mise à jour ne révoque pas des identifiants déjà volés.

Sans rotation complète des mots de passe administrateurs, des clés de sécurité, des identifiants de base de données et des sessions actives, un attaquant peut revenir par la porte d'en avant. Sur un site à jour. Sans exploiter quoi que ce soit.

3. Que reste-t-il en dehors de WordPress?

wp2shell donne une exécution de code sous l'utilisateur du compte d'hébergement.

Pas seulement dans WordPress. Dans le compte.

Si votre hébergeur utilise une isolation par compte, celle-ci protège les autres clients du serveur. Elle ne protège pas l'intérieur du vôtre.

Restent donc accessibles, et hors de portée d'une restauration du dossier web :

• Les tâches planifiées du compte
• Les fichiers déposés en dehors du dossier web
• Les autres domaines rattachés au même compte

4. Et le staging que personne ne regarde?

L'environnement de test, la vieille copie du site, le sous-domaine laissé en place depuis la refonte.

S'ils sont rattachés au même compte que la production, ils étaient dans le périmètre d'exécution de l'attaquant.

S'ils vivent ailleurs, la question devient : roulaient-ils une version vulnérable, exposée publiquement, pendant la même période? Ont-ils été mis à jour et restaurés eux aussi, ou seulement oubliés?

Une seule installation vulnérable sur un compte suffit à compromettre le reste.

Comment vérifier si mon site WordPress a été compromis?

Vous pouvez faire une première passe vous-même. Cinq points, aucun outil requis.

Pour la version rapide, notre analyse gratuite RapideWP Scan confirme la version installée et vérifie l'exposition publique de votre site en quelques secondes.

1. Confirmez la version réellement installée

Tableau de bord, section Mises à jour.

Vous devez voir 7.0.2, 6.9.5 ou 6.8.6, au minimum.

Ne présumez pas que la mise à jour forcée s'est rendue. Vérifiez sur chaque site, y compris ceux que vous n'ouvrez jamais.

2. Passez vos comptes administrateurs en revue

Section Utilisateurs, filtrée par rôle administrateur.

Cherchez les comptes créés entre le 17 juillet et la date de mise à jour de votre site.

Cherchez aussi les noms plausibles que personne dans votre organisation ne reconnaît.

3. Passez la liste des extensions en revue

Une extension que vous n'avez jamais installée. Une extension désactivée dont personne ne connaît l'origine. Une extension au nom crédible, mais sans page de réglages.

Les attaquants ont notamment déposé des portes dérobées déguisées en outils de sécurité légitimes. Le nom rassurant ne prouve rien.

4. Cherchez les traces dans vos journaux d'accès

Dans le panneau de votre hébergement, cherchez les requêtes vers les endpoints de traitement par lot de l'API REST.

Deux signaux publiquement documentés :

• Des réponses HTTP 207 ou 200 Multi-Status sur ces endpoints
• Des agents utilisateurs contenant wp2shell ou rezwp2shell

Une requête bloquée n'est pas un problème. Une réponse 207 sur une version vulnérable, avant votre mise à jour, en est un.

5. Répétez sur tous les sites du même compte

Y compris le staging. Y compris le vieux sous-domaine.

Si l'un de ces points révèle quelque chose, arrêtez de fouiller.

Chaque manipulation supplémentaire écrase des traces dont on a besoin pour dater l'intrusion. C'est le moment de passer à une intervention sur site WordPress piraté.

Quand faut-il aller plus loin?

Les cinq points ci-dessus vous disent si quelque chose d'évident est visible.

Ils ne vous disent pas si votre point de restauration était propre, ni si la persistance vit en dehors de WordPress, ni ce qui a été extrait de votre base de données.

Ces réponses demandent une analyse des journaux serveur et une inspection au niveau du compte d'hébergement, pas seulement du site.

C'est ce qu'on fait dans une vérification post-incident :

• Datation de l'intrusion dans les journaux d'accès
• Validation du point de restauration, preuves à l'appui
• Inspection de la persistance au niveau du compte, production et staging
• Rotation complète des secrets, avec liste de vérification
• Renforcement pour fermer définitivement ce vecteur : restriction de l'accès anonyme aux endpoints concernés, surveillance des artefacts connus

Le résultat est un rapport qui dit une chose simple : votre site est propre, et voici comment on le sait. Ou : voici ce qui reste, et voici ce qu'on fait avec.

Si vous gérez un site WordPress d'affaires et que vous n'avez pas vérifié depuis le 17 juillet, écrivez-nous. On regarde ça.

Questions fréquentes

Mon hébergeur m'a dit que tout était correct. Est-ce suffisant?

Votre hébergeur confirme que le correctif est appliqué. C'est vrai, et c'est important. Mais il ne se prononce pas sur ce qui s'est passé dans votre compte pendant la fenêtre d'exposition. Ce sont deux questions différentes.

Mon site est petit, pourquoi quelqu'un s'y intéresserait?

Les campagnes observées sont des balayages automatisés de masse. Personne n'a choisi votre site. Un script a testé des millions d'adresses et a gardé celles qui répondaient.

J'ai déjà lancé un scan de sécurité et il est revenu propre. Suis-je correct?

Un scan propre est un bon signal, pas une preuve. Il vous dit qu'aucun fichier malveillant connu n'est visible dans WordPress. Il ne vous dit rien sur les tâches planifiées du compte, les fichiers déposés hors du dossier web, ni sur les identifiants qui ont pu être extraits.

Combien de temps un attaquant peut-il rester sans qu'on le voie?

Indéfiniment, si la persistance a été bien placée. Les portes dérobées modernes retournent volontairement des erreurs 404 aux visiteurs ordinaires pour passer inaperçues.

Faut-il changer les mots de passe même si le site est à jour?

Oui. La mise à jour corrige la faille, elle ne révoque pas des identifiants déjà volés. La rotation doit couvrir les comptes administrateurs, les clés de sécurité, les identifiants de base de données et les sessions actives.

Comment savoir si mon site est exposé en ce moment?

Notre analyse gratuite vérifie la version de WordPress publiquement exposée et les signaux de configuration les plus courants. C'est un point de départ, pas un diagnostic complet.