CVE-2026-63030 wp2shell : la faille WordPress qui crée un administrateur sans mot de passe
Ce qu'une PME doit savoir sur la vulnérabilité critique du cœur WordPress exploitée massivement depuis juillet 2026
Analyse 2LKATIME
Nos pentesters certifiés OSCP/OSEP suivent les vulnérabilités critiques du cœur WordPress au quotidien pour le compte de nos clients PME. Cet article synthétise les éléments techniques et opérationnels à connaître sur wp2shell.
Pour un dirigeant, c'est la porte d'entrée la plus discrète qui existe
Pas de mot de passe volé, pas de phishing, pas d'employé qui clique sur le mauvais lien. Un attaquant anonyme peut obtenir un accès administrateur complet à votre site en quelques requêtes automatisées, sans jamais toucher au formulaire de connexion. Le site continue de fonctionner normalement : rien ne clignote, rien n'alerte, jusqu'à ce que les conséquences deviennent visibles.
wp2shell est le nom donné par la communauté de la sécurité à une chaîne d'exploitation critique du cœur de WordPress, révélée le 17 juillet 2026. En combinant deux failles, CVE-2026-63030 et CVE-2026-60137, elle permet à un attaquant sans identifiant de créer un compte administrateur à distance, puis d'exécuter du code sur le serveur. Un exploit public est apparu en moins de 24 heures, et l'exploitation active à l'échelle d'internet a été confirmée dès le 18 juillet.
Cet article explique concrètement comment fonctionne l'attaque, quels signes doivent alerter une PME qui utilise WordPress, et quelles obligations RGPD peuvent découler d'une compromission de ce type. L'objectif n'est pas de créer de la panique, mais de donner une grille de lecture claire pour agir vite si besoin.
1. Comprendre wp2shell en quatre chiffres
WordPress motorise plus de 40% des sites web dans le monde, ce qui fait de chaque faille de son cœur un événement de sécurité à grande échelle. wp2shell se distingue par le fait qu'elle touche l'installation par défaut, sans nécessiter de plugin ou de thème particulier.
9.8
Score CVSS de la chaîne complète
0
Identifiant nécessaire pour attaquer
<24h
Délai avant l'apparition d'un exploit public
48h
Délai avant exploitation massive confirmée
Les versions concernées sont WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Les correctifs officiels sont sortis le 17 juillet 2026 dans les versions 6.9.5, 7.0.2 et 6.8.6. Étant donné la gravité, l'équipe WordPress.org a forcé le déploiement automatique du correctif sur les sites ayant les mises à jour automatiques activées, une mesure exceptionnelle qui donne la mesure du risque.
2. Comment fonctionne l'attaque
La chaîne d'exploitation combine deux mécanismes distincts. CVE-2026-63030 est une confusion de route dans l'endpoint REST /wp-json/batch/v1, qui permet de faire passer des paramètres là où ils ne devraient pas arriver. CVE-2026-60137 est une injection SQL dans le paramètre author__not_in de WP_Query, la classe qui construit la plupart des requêtes de base de données de WordPress. Combinées, ces deux failles permettent de forger un article via une injection UNION, puis d'exploiter le mécanisme de cache oEmbed pour transformer cet accès en création d'un compte administrateur, avant de déposer un plugin webshell pour obtenir une exécution de code persistante.
Ce qui n'est PAS nécessaire à l'attaquant
- - Un identifiant ou un mot de passe valide
- - Un plugin vulnérable installé sur le site
- - Une interaction humaine (clic, téléchargement)
- - Un accès préalable au serveur
Ce que l'attaquant obtient au final
- - Un compte administrateur complet
- - Un accès au système de fichiers via un plugin webshell
- - La possibilité d'exécuter du code arbitraire sur le serveur
- - Un point d'entrée qui peut servir à d'autres attaques (base de données, mail, serveur mutualisé)
Point important pour les équipes techniques : la majorité des requêtes décisives de cette attaque transitent dans le corps de requêtes POST vers l'endpoint batch, qui n'apparaissent que rarement dans les journaux d'accès classiques. Les traces les plus fiables se trouvent généralement dans la base de données elle-même (comptes créés, options suspectes) plutôt que dans les logs serveur.
3. Les signes qui doivent alerter
Une compromission via wp2shell laisse généralement des traces identifiables, à condition de savoir où regarder. Voici les points de contrôle prioritaires pour toute PME utilisant WordPress.
Comptes administrateur inconnus
Lister l'ensemble des utilisateurs (via l'interface d'administration ou la commande wp user list en ligne de commande) et vérifier qu'aucun compte administrateur n'a été créé sans votre connaissance, y compris ceux avec des identifiants ou des adresses e-mail génériques et peu naturels.
Plugin inconnu de quelques kilo-octets
Un dossier de plugin au nom plausible mais jamais installé par vous, contenant un seul petit fichier PHP, est une signature classique de webshell déposé après compromission. Ce type de fichier se fait souvent passer pour une extension légitime avec un en-tête d'auteur crédible.
Requêtes anormales vers l'API REST
Dans les journaux du serveur web, rechercher un volume inhabituel de requêtes POST vers /wp-json/batch/v1, en particulier sur les jours qui ont suivi le 17 juillet 2026, période de début de l'exploitation massive.
Version de WordPress non corrigée
Même en l'absence de signe visible de compromission, un site encore en version 6.9.0 à 6.9.4 ou 7.0.0 à 7.0.1 reste vulnérable et doit être mis à jour en priorité vers 6.9.5, 7.0.2 ou une version ultérieure.
4. Obligations RGPD et délai de réaction
Une prise de contrôle administrateur d'un site WordPress n'est pas seulement un problème technique : c'est potentiellement une violation de données personnelles au sens de l'article 4 du RGPD, dès lors que le site traite des données de clients, prospects ou salariés (formulaires de contact, comptes utilisateurs, newsletter). Si l'investigation ne permet pas d'exclure un accès ou une exfiltration de ces données par l'attaquant, l'entreprise doit évaluer une notification à la CNIL sous 72 heures conformément à l'article 33 du RGPD, et potentiellement informer les personnes concernées si le risque est élevé.
Pour les entreprises entrant dans le périmètre de la directive NIS2, une compromission de ce niveau de gravité peut également déclencher des obligations de notification spécifiques selon le secteur d'activité. Documenter méthodiquement la chronologie de l'incident (détection, comptes touchés, actions correctives, absence ou présence d'exfiltration de données) est essentiel pour démontrer la conformité, que la notification soit finalement nécessaire ou non.
5. Comment 2LKATIME accompagne les PME sur ce type d'incident
Nos auditeurs cybersécurité certifiés OSCP, OSEP et OSWE interviennent auprès de PME et ETI à Paris comme partout en France, avec des tarifs identiques quelle que soit la localisation (voir nos formules et tarifs, disponibles également pour Lyon et Bordeaux). Sur ce type de vulnérabilité, notre démarche suit trois volets complémentaires : un audit de sécurité pour vérifier l'absence de compromission et corriger les versions vulnérables, un accompagnement RGPD pour déterminer si le seuil de notification à la CNIL est atteint, et, pour les entreprises qui souhaitent une surveillance continue plutôt qu'une intervention ponctuelle, un accompagnement CISO externalisé.
Que vous ayez un doute sur l'état de votre site WordPress ou que vous souhaitiez simplement vérifier votre exposition avant qu'un incident ne survienne, un diagnostic initial permet de faire un point clair et actionnable en moins d'une heure.
FAQ - wp2shell et sécurité WordPress
Qu'est-ce que la faille wp2shell (CVE-2026-63030) ?
wp2shell est le nom donné à une chaîne d'exploitation combinant deux vulnérabilités du cœur de WordPress, CVE-2026-63030 et CVE-2026-60137. Elle permet à un attaquant anonyme, sans identifiant ni mot de passe, de créer un compte administrateur à distance sur un site WordPress non corrigé, puis d'exécuter du code arbitraire sur le serveur.
Quelles versions de WordPress sont concernées ?
Les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1 sont vulnérables à la chaîne complète. Les correctifs ont été publiés le 17 juillet 2026 dans les versions 6.9.5, 7.0.2 et 6.8.6. Toute installation restée sur une version antérieure à ces correctifs est exposée, quel que soit le thème ou les plugins installés.
Comment savoir si mon site WordPress a été compromis ?
Les signes les plus fréquents sont la présence de comptes administrateur que vous n'avez pas créés, un dossier de plugin inconnu contenant un fichier PHP de quelques kilo-octets seulement, et des requêtes inhabituelles vers l'endpoint /wp-json/batch/v1 dans les journaux du serveur. Une vérification via la ligne de commande WP-CLI (wp user list) est le moyen le plus rapide de lister tous les comptes existants.
Que faire si je découvre un compte administrateur inconnu ?
Il faut agir dans l'ordre : supprimer le compte suspect, mettre à jour WordPress vers une version corrigée, régénérer les clés de sécurité du fichier wp-config.php pour invalider toutes les sessions actives, changer les mots de passe des comptes légitimes, puis vérifier l'absence de plugin ou fichier PHP malveillant résiduel avant de considérer l'incident clos.
La RGPD m'oblige-t-elle à notifier cette compromission ?
Si le site traite des données personnelles (formulaire de contact, comptes clients, newsletter) et que l'investigation ne peut pas exclure un accès ou une exfiltration de ces données par l'attaquant, l'entreprise doit évaluer une notification à la CNIL sous 72 heures conformément à l'article 33 du RGPD. Un accompagnement par un expert en cybersécurité permet de documenter cette analyse et de déterminer si le seuil de notification est atteint.
Vérifiez l'exposition de votre site WordPress
Un diagnostic rapide permet de savoir si votre installation est à jour, si des comptes suspects existent, et quelles actions correctives prioriser. Nos experts vous accompagnent, de la vérification technique jusqu'à la mise en conformité RGPD si nécessaire.