Une nouvelle faille WordPress wp2shell permet à un attaquant non authentifié d’exécuter du code à distance sur des millions de sites, via une simple requête HTTP anonyme. Cette RCE WordPress non authentifiée touche le cœur du CMS le plus utilisé au monde : pour une PME ou une ETI dont la vitrine, le blog ou la boutique tournent sous WordPress, c’est une menace à traiter en urgence. Voici comment comprendre le risque et le neutraliser.
La faille WordPress wp2shell en bref
La vulnérabilité wp2shell provient d’une confusion de routage dans l’API REST « batch » du cœur de WordPress. En enchaînant plusieurs opérations dans une seule requête, un attaquant contourne les contrôles d’authentification et déclenche une injection SQL menant à l’exécution de code à distance. Aucune session, aucun compte, aucune interaction utilisateur ne sont nécessaires : une requête HTTP unique suffit sur une installation par défaut.
- Versions vulnérables : WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1.
- Versions corrigées : WordPress 6.9.5 et 7.0.2.
- Vecteur : requête anonyme vers l’API REST, sans privilège.
- Impact : prise de contrôle complète du site et du serveur hôte.
À la publication, aucune exploitation active n’était confirmée. Mais l’histoire récente de WordPress est claire : entre la divulgation d’une faille de cette gravité et les premières vagues d’exploitation de masse, il s’écoule souvent quelques heures. Le temps de réaction est donc l’unique variable que vous maîtrisez.
Pourquoi cette RCE WordPress concerne directement les PME-ETI
WordPress propulse une large part des sites d’entreprise en France. Une RCE WordPress non authentifiée ne vise pas une configuration exotique : elle frappe les installations par défaut, celles que la plupart des TPE, PME et ETI exploitent sans équipe sécurité dédiée. Les conséquences d’une compromission wp2shell sont immédiates :
- Défiguration ou blocage de votre vitrine commerciale.
- Vol de données clients, prospects et identifiants stockés en base.
- Rebond vers votre hébergement mutualisé ou votre serveur interne.
- Insertion de portes dérobées persistantes, difficiles à déloger après coup.
Neutraliser wp2shell : le plan d’action
La priorité absolue face à la faille WordPress wp2shell est la mise à jour du cœur. Les étapes ci-dessous permettent de sécuriser un parc WordPress en quelques minutes.
1. Mettre à jour le cœur WordPress sans délai
Passez immédiatement en WordPress 6.9.5 ou 7.0.2 selon votre branche. Depuis le tableau de bord, rendez-vous dans Tableau de bord > Mises à jour, ou en ligne de commande avec wp core update. Vérifiez ensuite le numéro de version affiché pour confirmer l’application du correctif.
2. Filtrer l’API REST batch au niveau du reverse proxy
Si vous ne pouvez pas patcher dans l’heure, ajoutez une règle sur votre WAF ou votre reverse proxy pour bloquer ou restreindre les appels à la route batch de l’API REST. C’est une mesure de contention, jamais un substitut au correctif.
3. Rechercher les signes de compromission
Inspectez les journaux d’accès à la recherche de requêtes POST anormales vers l’API REST, contrôlez les fichiers récemment modifiés dans wp-content, et traquez les comptes administrateurs inconnus. Notre guide pour détecter et bloquer les backdoors WordPress détaille la marche à suivre.
4. Faire tourner les secrets exposés
Après toute suspicion de RCE WordPress, considérez comme compromis les clés API, mots de passe de base de données et jetons présents sur le serveur. Régénérez-les, comme le rappelle notre analyse sur les secrets exposés et la fuite de clés.
Durcir WordPress contre la prochaine faille
La faille WordPress wp2shell ne sera pas la dernière RCE du cœur. Quelques réflexes réduisent durablement votre surface d’attaque :
- Activez les mises à jour automatiques du cœur pour les versions de sécurité.
- Placez WordPress derrière un WAF et un reverse proxy à jour.
- Limitez l’exposition de l’API REST aux seuls usages nécessaires.
- Sauvegardez hors ligne et testez vos restaurations régulièrement.
- Supervisez les fichiers et les accès avec une solution de détection.
En résumé : face à une RCE WordPress non authentifiée exploitable par une requête unique, la seule bonne posture est de patcher aujourd’hui, filtrer en attendant, et vérifier que rien n’est déjà passé. La rapidité de votre cycle de correctif est votre meilleure défense.