Bulletins de Sécurité

Détection de la compromission :

Afin de vérifier si une compromission a eu lieu, vous pouvez :

• Si un accès aux logs du serveur web (Apache, Nginx) est possible, auditer les logs à la recherche de requêtes HTTP POST vers /wp-json/batch/v1 ou /?rest_route=/batch/v1 depuis des IP suspectes.

• Les valeurs anormales de author__not_in / author_exclude contenant des mots-clés SQL sont l'un des indicateurs les plus propres d'une tentative d'exploitation de cette chaîne.

• Rechercher les motifs SQL dans les paramètres batch (SELECT, SLEEP, SUBSTRING, CHAR_LENGTH, UNION).

• Rechercher les fichiers PHP récemment créés ou modifiés dans wp-content/plugins/, en particulier des répertoires suivant le motif wp2shell-*.

• Exécuter wp core verify-checksums pour identifier des altérations du core, via la WP CLI.

• Passer en revue les comptes administrateurs (wp_users / table WP User) et vérifier tout utilisateur non répertorié dans l'inventaire approuvé, en particulier les comptes récemment créés.

Aucune adresse IP ni domaine C2 officiellement lié à une campagne d'exploitation n'a été publié à la date de rédaction. Il n'existe pas d'indicateurs (noms de fichiers ou IP) spécifiques à wp2shell dans les divulgations primaires, il ne faut donc pas s'appuyer sur une liste d'IoC figée. Il est indispensable de préserver les logs avant tout nettoyage.

Remédiation :

Mettre à jour WordPress Core vers les versions :

• Branche 6.9.x → 6.9.5

• Branche 7.0.x → 7.0.2

• Branche 7.1 beta → 7.1 beta2

Pour la Branche 6.8.x, uniquement affectée par la CVE-2026-60137, mettre à jour vers la version 6.8.6 

L'équipe de sécurité WordPress a également forcé le déclenchement de mises à jour automatiques sur les sites affectés où l'auto-update était activé. La mise à jour forcée réduit le risque mais ne garantit pas la remédiation. Une mise à jour en arrière-plan peut échouer ou être désactivée, donc les administrateurs doivent confirmer la version réellement installée sur chaque site plutôt que de supposer que la mise à jour est passée.

Le détail est disponible dans les liens en références.

Mitigation :

Si le patch ne peut être appliqué immédiatement :

• Bloquer l'accès anonyme à l'endpoint REST API batch (/wp-json/batch/v1 et ?rest_route=/batch/v1) via un WAF ou un plugin de sécurité.

• Cloudflare a déployé des règles WAF managées couvrant les deux CVE pour les sites proxifiés sur tous les plans, y compris le plan gratuit, ce qui bloque les patterns d'exploitation connus. Wordfence et Beazley Security ont également publié des règles pare-feu dédiées.

• Installer un plugin qui bloque totalement l'accès anonyme à l'API REST si le endpoint batch n'est pas nécessaire à l'exploitation métier.

• Restreindre l'accès à l'interface /wp-admin/ par ACL et/ou VPN.

• Un core patché ferme le chemin vulnérable mais n'annule pas une compromission antérieure au patch. Tout site ayant exécuté une version affectée pendant qu'il était atteignable doit être considéré comme potentiellement compromis jusqu'à revue.