Faille critique WordPress wp2shell activement exploitée — mettez à jour maintenant

Une vulnérabilité WordPress wp2shell nouvellement révélée est activement exploitée sur Internet en ce moment même, et si votre entreprise utilise un site WordPress, ce n’est pas une mise à jour à remettre à plus tard. Le 18 juillet 2026, l’équipe de sécurité de WordPress a corrigé deux failles dans le cœur même de WordPress — pas dans une extension, pas dans un thème, mais dans le logiciel sur lequel repose chaque site WordPress. Combinées, ces deux failles permettent à un attaquant de prendre le contrôle d’un site vulnérable sans identifiants de connexion. En 72 heures, les chercheurs observaient déjà, en temps réel, des scans massifs, le dépôt de webshells et la création de comptes administrateur frauduleux.

Qu’est-ce que la vulnérabilité WordPress wp2shell ?

Selon Help Net Security (18 juillet 2026), la vulnérabilité WordPress wp2shell est en réalité constituée de deux failles distinctes dans le cœur de WordPress, bien plus dangereuses une fois combinées :

• CVE-2026-60137 — une faille d’injection SQL. L’injection SQL permet à un attaquant d’envoyer des données spécialement conçues pour tromper la base de données du site et lui faire exécuter des commandes qu’elle ne devrait jamais accepter, exposant potentiellement identifiants, hachages de mots de passe et clés secrètes.
• CVE-2026-63030 — un bug de « confusion de route batch » dans l’API REST. L’API REST de WordPress permet de regrouper plusieurs actions dans une seule requête (un « batch »). Cette faille permet à un attaquant d’exploiter la manière dont WordPress détermine quelle action exécuter, en contournant totalement l’authentification pour atteindre des fonctions normalement réservées à un administrateur connecté.

Prise séparément, chaque faille est déjà sérieuse. Combinées, les chercheurs ont découvert qu’elles permettent à un attaquant sans compte, sans mot de passe et sans accès préalable d’obtenir une exécution de code à distance — c’est-à-dire d’exécuter son propre code sur le serveur, d’y déposer un webshell et de prendre effectivement le contrôle du site. Les chercheurs ont baptisé cette chaîne d’attaque combinée « wp2shell ».

Pourquoi une RCE non authentifiée dans le cœur est le pire scénario possible

La plupart des incidents WordPress traités par SecureWeb impliquent une extension vulnérable, un mot de passe faible ou un e-mail de phishing — des causes claires et maîtrisables. Ici, c’est différent. Il s’agit d’une faille d’exécution de code à distance exploitable avant toute authentification, dans le cœur même de WordPress, la couche logicielle sous-jacente à chaque extension et chaque thème. Peu importe la robustesse du mot de passe administrateur, le nombre d’extensions installées, ou l’activation de l’authentification à deux facteurs — rien de tout cela n’est vérifié avant même le début de l’attaque. WordPress fait fonctionner une large part des sites d’entreprises, de commerce en ligne et d’institutions marocaines, ce qui explique pourquoi cette catégorie de vulnérabilité mérite une attention urgente plutôt qu’un traitement de routine.

Qui est concerné

Tout site WordPress auto-hébergé exécutant une version du cœur affectée par CVE-2026-60137 et CVE-2026-63030 est à risque tant qu’il n’est pas mis à jour. WordPress a publié des correctifs sur ses branches maintenues le 18 juillet 2026 : 6.8.6, 6.9.5 et 7.1-beta2. Si la version du cœur de votre site est antérieure au correctif de sa branche, elle est vulnérable.

L’ampleur est notable. The Hacker News (21 juillet 2026) rapporte que la société de sécurité Wiz a scanné des installations WordPress actives et constaté que 60 % étaient initialement vulnérables, dont environ 25 % directement exposées sur Internet — c’est-à-dire accessibles par n’importe quel attaquant, où qu’il soit, sans accès réseau préalable. C’est une surface d’attaque très large pour une faille de cette gravité.

Exploitation active : ce que constatent les chercheurs en sécurité en ce moment

Il ne s’agit pas d’un risque théorique. Dès le 19–21 juillet 2026 — soit un ou deux jours après la divulgation —, les attaquants scannaient déjà massivement Internet à la recherche d’installations vulnérables. Le réseau de honeypots (serveurs leurres conçus pour attirer et enregistrer le trafic d’attaque) de watchTowr a enregistré des dizaines de milliers de tentatives d’exploitation en provenance d’adresses IP situées dans plusieurs pays. Parmi les comportements confirmés : le dépôt de webshells (scripts cachés donnant à l’attaquant un accès en ligne de commande persistant sur le serveur) et la création de comptes administrateur frauduleux pour conserver l’accès même après la correction de la faille d’origine.

L’angle marocain : la DGSSI suit cette vulnérabilité

L’autorité nationale marocaine de cybersécurité, la DGSSI (Direction Générale de la Sécurité des Systèmes d’Information), référence actuellement dans son bulletin national de sécurité une entrée intitulée « Vulnérabilités critiques dans le CMS WordPress » — une confirmation directe que ce dossier est suivi au niveau national, et pas uniquement par des éditeurs internationaux. Pour toute organisation marocaine utilisant WordPress — PME, boutiques e-commerce, établissements de santé, institutions financières ou sites gouvernementaux — la présence de ce bulletin DGSSI est un signal fort qu’il ne s’agit pas d’une situation à observer passivement. Il convient de la traiter comme un appel à l’action formel : vérifier, corriger et valider vos installations WordPress sans délai. C’est aussi l’occasion de revoir la conformité globale de votre organisation avec les lois marocaines sur la cybersécurité, en particulier si vous traitez des données clients ou financières.

Comment corriger la vulnérabilité WordPress wp2shell

Corriger cette faille précise n’est qu’une partie d’une démarche plus large pour sécuriser WordPress — consultez le guide de SecureWeb pour sécuriser un site WordPress et découvrir des mesures de durcissement supplémentaires au-delà de cet incident.

1. Vérifiez votre version de WordPress. Dans wp-admin, allez dans Tableau de bord → Mises à jour, ou Tableau de bord → Vue d’ensemble, pour voir votre version actuelle du cœur.
2. Mettez à jour vers une version corrigée. Selon votre branche : 6.8.6, 6.9.5, ou une version ultérieure (7.1-beta2 ou la future version stable 7.1 une fois disponible).
3. Sauvegardez avant de mettre à jour — une bonne pratique standard, mais particulièrement importante ici compte tenu de l’exploitation active ; vous voulez un point de restauration propre en cas de problème.
4. Activez les mises à jour automatiques du cœur si votre hébergement le permet, afin que les futures versions de sécurité s’appliquent sans action manuelle.
5. Si vous utilisez un hébergement WordPress géré, vérifiez directement auprès de votre hébergeur si le correctif a déjà été appliqué au niveau de la plateforme — de nombreux hébergeurs gérés déploient automatiquement les mises à jour critiques, mais il vaut mieux vérifier que supposer.
6. Si votre installation WordPress est personnalisée ou fortement modifiée (routes REST personnalisées, réseau multisite, ou équipe de développement maintenant le code), impliquez vos développeurs dès maintenant — ils devront peut-être vérifier que le code personnalisé ne réintroduit pas des failles similaires.

Signes que votre site pourrait déjà être compromis

L’exploitation massive ayant débuté quelques jours seulement après la divulgation, il est utile de vérifier tout signe de compromission même après avoir mis à jour :

• Des comptes administrateur que vous ne reconnaissez pas (Utilisateurs → Tous les utilisateurs dans wp-admin).
• Des fichiers PHP inconnus, notamment dans /wp-content/uploads/ — ce dossier ne devrait normalement contenir aucun code exécutable.
• Un trafic sortant inhabituel ou une charge serveur anormalement élevée.
• Des modifications de fichiers du cœur qui ne correspondent pas à une mise à jour légitime.

Si vous constatez l’un de ces signes, une simple mise à jour ne suffit pas — l’attaquant a peut-être déjà pris pied sur le site. Traitez la situation comme une compromission suspectée : isolez le site, conservez les journaux, et suivez le guide de SecureWeb pour restaurer un site piraté, ou faites appel à un spécialiste de la réponse à incident avant de reprendre une activité normale.

De l’authentification à deux facteurs au correctif : deux couches, pas une seule

Le récent guide de SecureWeb sur la mise en place de l’authentification à deux facteurs sur WordPress couvre une couche de défense importante mais différente : protéger le formulaire de connexion pour qu’un mot de passe volé ou deviné ne suffise pas à s’introduire. La vulnérabilité wp2shell rappelle pourquoi ce n’est qu’une couche parmi d’autres — cette chaîne d’attaque contourne entièrement le formulaire de connexion, donc la 2FA ne fait rien pour l’arrêter. Une sécurité de connexion robuste et un cœur WordPress à jour et corrigé sont complémentaires, pas interchangeables. Un site WordPress bien sécurisé a besoin des deux.

Ce que les entreprises marocaines doivent faire maintenant

• Mettez à jour le cœur de WordPress immédiatement vers 6.8.6, 6.9.5 ou 7.1-beta2, selon votre branche.
• Consultez le bulletin national de la DGSSI pour les dernières recommandations sur cette faille et les avis connexes.
• Vérifiez vos comptes administrateur juste après la mise à jour, à la recherche de tout compte non reconnu.
• Recherchez des webshells et fichiers inconnus, en particulier dans les dossiers d’upload.
• Si vous ne pouvez pas mettre à jour immédiatement (tests de compatibilité requis, par exemple), envisagez un pare-feu applicatif web comme mesure temporaire — ce n’est pas un substitut au correctif, seulement une solution d’attente.
• Envisagez un audit de sécurité ou un test d’intrusion professionnel si votre site traite des données clients, des paiements ou des informations sensibles. Consultez la liste de vérification pour l’audit de sécurité d’un site web de SecureWeb — cet incident est une bonne occasion de vérifier qu’aucun autre problème non corrigé ne subsiste en parallèle.
• Continuez à surveiller — les attaquants ayant scanné lors de la première vague pourraient revenir vérifier si un site a été corrigé.

En résumé

La vulnérabilité WordPress wp2shell est exactement le type de faille qui transforme une simple notification de « mise à jour disponible » en tâche urgente : non authentifiée, exploitable à distance, présente dans le cœur, et déjà massivement exploitée quelques jours après sa divulgation. Si vous gérez un site WordPress — ou si vous ne savez pas qui le fait — vérifier votre version du cœur aujourd’hui est une tâche de cinq minutes qui peut éviter un incident bien plus long et coûteux. Pour un second avis, les audits de sécurité de site web et les services de réponse à incident de SecureWeb peuvent vous aider à confirmer que votre site est corrigé et sain.

Questions fréquentes

Qu’est-ce que WordPress wp2shell ?

« WordPress wp2shell » est le nom donné par les chercheurs en sécurité à l’exploitation combinée de deux vulnérabilités du cœur de WordPress, CVE-2026-60137 (injection SQL) et CVE-2026-63030 (confusion de route batch dans l’API REST), qui permettent ensemble à un attaquant non authentifié d’obtenir une exécution de code à distance sur un site WordPress vulnérable.

Quelles versions de WordPress sont concernées par WordPress wp2shell ?

Les versions antérieures aux correctifs publiés le 18 juillet 2026 — WordPress a résolu le problème dans les versions 6.8.6, 6.9.5 et 7.1-beta2. Si la version installée du cœur de votre site est antérieure au correctif de sa branche, mettez à jour immédiatement.

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

Vérifiez la présence de comptes administrateur non reconnus, de fichiers PHP inconnus (notamment dans le dossier uploads), d’une charge serveur ou d’un trafic sortant inhabituels, et de fichiers du cœur ne correspondant à aucune mise à jour légitime. Si vous constatez l’un de ces signes, traitez-le comme une compromission suspectée et faites appel à un spécialiste plutôt que de supposer qu’un simple nettoyage suffira.