seolounge
- Un serveur ouvert a révélé une opération de webshells visant surtout des CMS mal tenus.
- Les listes exposées dépassaient 1,4 million de domaines, sans vouloir dire que tout était piraté.
- Le dossier contenait des exploits, des shells, des logs, des listes de cibles et des réglages de commande.
- La campagne s’appuyait sur 27 CVE connues, avec Breeze Cache comme gros point d’entrée côté WordPress.
- Le bon réflexe consiste à vérifier les plugins, les fichiers PHP récents, les admins et les logs.
WP-SHELLSTORM secoue la sécurité WordPress depuis le 10 juillet 2026, et cette fois le sujet ne se limite pas à une faille isolée dans un plugin. L’histoire est plus instructive. Un groupe cybercriminel a laissé un serveur accessible publiquement pendant environ 22 jours. Dedans, des chercheurs ont retrouvé des scripts d’exploitation, des webshells, des historiques de commandes, des listes de cibles et des traces d’activité qui montrent comment une attaque de masse se prépare quand des plugins restent trop longtemps sans mise à jour.
Le nom WP-SHELLSTORM désigne une opération de revente d’accès par webshell. En clair, l’objectif n’est pas forcément de casser ton site tout de suite. L’attaquant cherche d’abord à déposer un petit fichier PHP qui lui permet de revenir plus tard, de parcourir les fichiers, de lancer des commandes, de vendre l’accès ou de laisser quelqu’un d’autre exploiter le terrain. C’est discret, pénible à nettoyer et à traiter vite, surtout quand le fichier se cache dans wp-content.
Le point qui mérite ton attention, c’est la méthode. Pas besoin d’une faille inconnue ou fraîchement publiée. La campagne a utilisé des CVE déjà connues, souvent corrigées, mais encore présentes sur des sites qui tournent avec une vieille version de plugin. Pour un admin WordPress, le sujet est surtout très pratique, parce qu’il donne une liste de vérifications concrètes à faire sans attendre le prochain mail d’alerte.
Un serveur oublié qui raconte une attaque massive
Le serveur exposé contenait environ 800 Mo de données réparties dans plus de 400 fichiers. Ce n’est pas seulement une capture de malware. C’est un morceau de coulisses. On y voit des listes de domaines, des scripts pour tester des failles, des webshells obfusqués, des traces de téléchargements et même des éléments de configuration utilisés par l’opérateur.
Les chiffres doivent être lus calmement. Plus de 1,4 million de domaines apparaissaient dans les listes de cibles, mais une cible listée n’est pas un site compromis. Les estimations publiques varient selon la méthode de comptage. Une analyse évoque plus de 5 700 webshells actifs confirmés. Une autre monte à 25 195 indices de compromission validés. Dans les deux cas, le message reste le même. Les sites non patchés continuent de payer très cher les mises à jour reportées.
Le détail le plus parlant concerne Breeze Cache. La faille CVE-2026-3844 aurait produit une grande partie des shells observés dans cette campagne, surtout quand un réglage non standard autour du stockage local des Gravatars était activé. Si tu utilises ce plugin, relis notre point sur Breeze Cache et CVE-2026-3844, puis vérifie la version réellement installée sur le site, pas seulement ce que tu penses avoir mis à jour.
Ce que ça change pour ton WordPress
WP-SHELLSTORM rappelle un truc assez simple. Le danger ne vient pas seulement du plugin très connu qui fait la une. Il vient du mélange entre une vieille extension, un serveur exposé, un fichier PHP déposé au mauvais endroit et un suivi trop léger après incident. Un site peut avoir l’air propre côté visiteurs et héberger pourtant un accès discret côté serveur.
Un webshell n’a pas besoin d’être gros. Il peut tenir dans un fichier court, porter un nom rassurant ou se cacher dans un dossier où personne ne va regarder tous les matins. uploads, cache, mu-plugins, plugins désactivés, anciens thèmes, backups oubliés et répertoires temporaires méritent un passage. Le but n’est pas de supprimer au hasard. Le but est de comparer ce qui existe avec ce qui devrait exister.
Si tu es freelance, agence ou responsable d’un petit parc de sites, l’angle le plus rentable est l’inventaire. Tu notes les plugins présents, les versions, les sites où le plugin est actif, les sites où il est juste installé, puis tu patches. Ça sonne basique, oui. Mais cette campagne montre que les attaques de masse adorent les oublis basiques.
| Zone à contrôler | Signal à surveiller | Action utile |
|---|---|---|
| Plugins | Version ancienne ou plugin abandonné | Mettre à jour ou désactiver proprement |
| Fichiers PHP | Ajout récent dans uploads ou cache | Comparer avec une sauvegarde saine |
| Comptes admin | Compte inconnu ou ancien prestataire actif | Réduire les accès et changer les mots de passe |
| Logs serveur | POST répétés vers un fichier bizarre | Isoler le fichier et garder la trace |
| Pages spam ou titres inconnus | Nettoyer puis inspecter dans Search Console |
Les plugins à passer en priorité
La campagne a touché 27 CVE au total, mais quelques noms ressortent davantage côté WordPress et CMS. Breeze Cache arrive en tête dans les données exposées. ThemeREX Addons apparaît aussi avec un volume notable. D’autres entrées comme Simple File List, Custom CSS JS PHP, WavePlayer, BerqWP, Ninja Forms uploads, WPBookit et WP File Manager méritent un contrôle si tu les as déjà installés sur un site.
Tu n’as pas besoin de connaître chaque CVE par cœur. Tu as surtout besoin de savoir si le plugin est présent, si la version est corrigée, si le dossier du plugin contient des fichiers récemment modifiés et si le site a reçu des requêtes étranges autour de la période visée. Un plugin désactivé peut rester un souci si ses fichiers vulnérables répondent encore côté serveur. Un vieux dossier renommé peut aussi faire des dégâts si le code reste accessible.
Pour les sites WooCommerce, les sites d’agence et les sites clients qui n’ont pas été ouverts depuis des semaines, je ferais le tour tout de suite. Pas dans trois audits. Maintenant. Les attaques qui posent des webshells aiment les périodes molles, les comptes oubliés et les dossiers que personne n’assume vraiment.
Breeze Cache garde une place à part
Breeze Cache avait déjà son propre sujet de sécurité, mais WP-SHELLSTORM lui donne une autre portée. Ici, la faille n’est pas juste une fiche CVE rangée dans une base. Elle apparaît dans une chaîne d’attaque industrialisée, avec des cibles, des scripts et des shells. Le réglage lié aux Gravatars limite le périmètre, mais si ton site entre dans ce cas, tu dois traiter ça avec sérieux.
Vérifie la version, vide le cache, regarde les fichiers récents dans wp-content, puis teste quelques pages publiques. Si tu trouves un fichier suspect, ne le supprime pas à chaud sans copie. Mets le site en sécurité, garde une trace, récupère les logs et compare avec une sauvegarde propre. Un nettoyage trop rapide peut effacer l’indice qui t’aurait dit par où l’attaquant est entré.
Chercher un webshell sans casser le site
Les noms de fichiers observés dans les indicateurs publics donnent quelques pistes. Sur un serveur Linux, regarde les fichiers récents qui ressemblent à .bd.php, .wp-log.php, .brq-*.php, .sd.php, .leo_.php, .wvp-*.php, .cc-*.php, .nf-log.php ou BZ_*.phtml. La présence d’un nom proche ne prouve pas tout, mais ça mérite un vrai contrôle.
Le bon réflexe consiste à croiser trois choses. La date de modification du fichier, son emplacement et les requêtes reçues dans les logs. Un fichier PHP apparu hier dans uploads est rarement normal. Un fichier qui reçoit des POST depuis plusieurs IP inconnues mérite encore plus d’attention. Un fichier obfusqué qui mélange beaucoup de chaînes encodées, des appels à eval, system, shell_exec ou base64_decode doit te faire lever les sourcils.
Si tu as un accès SSH, un scan par date peut déjà aider. Si tu travailles chez un hébergeur mutualisé, utilise le gestionnaire de fichiers, les logs fournis par l’hébergeur et le scanner de sécurité disponible. L’objectif n’est pas de jouer au forensic de film. Tu veux confirmer si le site est propre, isoler ce qui ne l’est pas, puis remettre une base saine.
Après le nettoyage, surveille aussi Google
Un webshell peut servir à bien plus qu’un simple accès serveur. Il peut déposer des pages spam, modifier des fichiers de thème, injecter des redirections, créer de nouveaux utilisateurs ou servir de relais à une autre campagne. C’est là que Search Console devient utile. Si Google commence à voir des pages inconnues, des titres en langue étrangère, des redirections douteuses ou des alertes de sécurité, tu veux le savoir vite.
Regarde les pages indexées récentes, les requêtes qui ne ressemblent pas à ton activité, les erreurs de couverture et les alertes de sécurité. Si ton site a eu un souci, nettoie d’abord, vérifie le sitemap, purge les caches, puis demande une inspection de l’URL. Pour suivre les prochains sujets proches, garde aussi nos alertes sécurité WordPress récentes dans un coin.
Ne te limite pas au tableau de bord WordPress. Un attaquant qui a déjà un webshell peut modifier un fichier hors admin. Il peut créer une tâche cron, déposer un faux plugin, toucher htaccess ou réinjecter du code après ton nettoyage. Si le site revient infecté deux jours plus tard, ce n’est pas de la magie. C’est qu’un accès a survécu.
Le plan rapide si tu gères plusieurs sites
Sur un parc de sites, commence par un tableau simple. Domaine, hébergeur, version PHP, version WordPress, plugins ciblés, version installée, statut du patch, dernière sauvegarde saine, date du dernier scan, présence d’admins externes. Pas besoin d’un outil hors de prix pour le premier passage. Une feuille bien tenue fait déjà gagner du temps.
Ensuite, traite en priorité les sites qui cumulent plusieurs signaux. Plugin visé, version ancienne, accès admin nombreux, site très visible dans Google, formulaire public, ancien thème premium, hébergement sans isolation claire. C’est là que tu as le plus à perdre et le plus de chance de trouver un fichier ou un accès à corriger.
Ce qui rend WP-SHELLSTORM utile à suivre, ce n’est pas le nom impressionnant. C’est la leçon très terre à terre. Les attaquants automatisent ce que nous laissons traîner. Un plugin oublié devient une porte. Un fichier PHP discret devient un accès. Un compte admin dormant devient un accélérateur. Tu n’as pas besoin d’être parfait, tu dois juste réduire assez vite les angles faciles.
