wp2shell_scanner

Scanner de détection non-intrusif pour les récentes vulnérabilités core de WordPress — incluant la chaîne RCE pré-authentification wp2shell.

wp2shell_scanner.py identifie la version du noyau WordPress d'un site et lit sa surface d'API REST publiquement annoncée, puis classe chaque CVE core suivie indépendamment par rapport à la version détectée. Les verdicts sont conscients de la branche — par exemple un site en 6.8.x est correctement signalé comme exposé à la CVE d'injection SQL mais pas à la chaîne RCE complète. Il détecte uniquement : aucune charge utile d'exploitation n'est jamais envoyée. Fichier unique, une seule dépendance (requests), codes de sortie adaptés à l'CI et rapports HTML / JSON / e-mail prêts pour le client.

⚠️ Utilisation autorisée uniquement. Scannez les systèmes que vous possédez ou pour lesquels vous êtes explicitement autorisé (par écrit) à tester. Le scanner envoie un User-Agent d'identification afin que les blue teams puissent attribuer le trafic — il ne se cache pas.

Vulnérabilités suivies (noyau WordPress)

La chaîne RCE wp2shell = CVE-2026-63030 + CVE-2026-60137 ensemble → exécution de code à distance sans authentification sur une installation par défaut. Le scanner signale la chaîne comme exposée uniquement lorsque les deux CVE sont classées comme vulnérables pour la version détectée.

Nuances de branche que le scanner gère correctement :

• 6.8.x porte l'injection SQL (CVE-2026-60137) uniquement — pas la chaîne RCE.
• Sur la branche 6.9, CVE-2026-3906 (Notes) est corrigée dans 6.9.2, mais la chaîne wp2shell n'est pas fermée avant 6.9.5. Ainsi 6.9.2/6.9.4 sont lus corrigés pour le bug des Notes, mais restent vulnérables à la chaîne RCE — le scanner ne recommande donc que 6.9.5 ou ultérieur sur cette branche, jamais 6.9.4.

Important sur le plan opérationnel : des articles techniques et un PoC fonctionnel pour wp2shell sont déjà publics. La détection de version est désormais le minimum absolu — la priorité est la correction. La mise à jour ferme le chemin vulnérable mais ne supprime pas une porte dérobée installée avant le correctif — d'où l'étape d'évaluation de compromission dans le rapport.

Périmètre

Ceci est un scanner de version du noyau. Les CVE de plugins et de thèmes — la grande majorité du catalogue WPScan / Patchstack — nécessitent un flux live et organisé et une énumération de version par plugin, et sont intentionnellement hors du périmètre ici. Dans son domaine (CVE récentes du noyau WordPress), il vise à être précis et exact sur les branches plutôt qu'à dupliquer une base de données de vulnérabilités commerciale.

Ce que fait le scanner

• Empreinte passive de WordPress via quatre vecteurs de version publics :
  • <meta name="generator"> sur la page d'accueil
  • /readme.html
  • Balise <generator> des flux RSS / Atom
  • /wp-links-opml.php (OPML)
• Vérification croisée des vecteurs. S'ils divergent sur la version, ou si une version pré-release (beta/RC/alpha) est détectée, le verdict est forcé sur INCONNU — le scanner ne signale jamais un Corrigé potentiellement faux à partir de preuves contradictoires.
• Découverte de la surface d'API REST — lit /wp-json/ pour voir si WordPress annonce l'espace de noms batch/v1 dans son index REST. Cela confirme que l'espace de noms est enregistré, pas que le point de terminaison est atteignable via un WAF. Aucune requête batch et aucune charge utile ne sont envoyées.
• Verdict par CVE — la version détectée est classée indépendamment pour chaque CVE suivie (consciente de la branche), et produit en sortie :
  • un rapport HTML prêt pour le client (impression → PDF),
  • un enregistrement JSON (adapté aux pipelines/EAV),
  • un e-mail de notification provisoire.

Ce qu'il ne fait pas explicitement

Il n'exploite rien. Aucune charge utile d'injection SQL, aucune requête de confusion de route batch, aucune tentative d'exécuter du code ou de lire des données. La détection est basée sur la version plus une lecture passive de la surface d'API publiquement annoncée.

Installation

pip install requests

Utilisation

# cible unique
python3 wp2shell_scanner.py -t https://site.example --authorized

# liste de cibles (une par ligne, # commentaires autorisés)
python3 wp2shell_scanner.py -T scope.txt --authorized -o ./reports

# prévisualiser les formats de sortie avec des données synthétiques — pas de réseau, pas d'authentification nécessaire
python3 wp2shell_scanner.py --demo -o ./reports

Options

L'option --authorized est une barrière d'autorisation explicite — les scans en direct refusent de s'exécuter sans elle.

Codes de sortie (adaptés à l'CI)

Configuration

Le destinataire de l'e-mail de notification est la constante CSSLTD_CONTACT près du haut du script (par défaut [email protected]). Modifiez-la pour votre propre adresse de réception.

Verdicts

Exemple de sortie

Le répertoire examples/ contient une sortie synthétique (--demo) pour un hôte vulnérable fictif (example.com, WordPress 6.9.1 — exposé aux trois CVE suivies) :

• wp2shell_report_example.com.html — le rapport HTML prêt pour le client
• wp2shell_example.com.json — l'enregistrement JSON
• wp2shell_email_example.com.txt — l'e-mail de notification provisoire

Ceux-ci sont générés à partir de données fabriquées pour illustrer le format du rapport. Ils ne sont pas le résultat du scan d'un site réel.

Remédiation (telle qu'émise dans le rapport)

1. Faites d'abord une sauvegarde vérifiée (base de données + arborescence complète des fichiers).
2. Mettez à jour le noyau WordPress vers une version qui corrige toutes les CVE suivies — 6.8.6 / 6.9.5 / 7.0.2 — ou ultérieure sur la branche correspondante. (Sur 6.9, seul 6.9.5+ est propre — 6.9.4 a encore la chaîne wp2shell.)
3. Confirmez que le site et l'administration fonctionnent toujours.
4. Supposez une compromission si l'hôte a été exposé alors qu'il était vulnérable — effectuez une évaluation de compromission sur les thèmes, plugins, uploads/, wp-config.php, wp-cron et comptes administrateurs ; vérifiez l'intégrité des fichiers par rapport au noyau connu bon.
5. Ajoutez une défense en profondeur en périphérie (règles WAF, restreindre /wp-json/batch/v1).
6. Renouvelez les secrets (salts d'authentification, mots de passe admin/DB, clés API) si une compromission est suspectée.
7. Re-scannenez pour confirmer que le verdict indique désormais Corrigé.

Références

• Avis de sécurité GitHub WordPress — chaîne RCE wp2shell (GHSA-ff9f-jf42-662q)
• Avis de sécurité GitHub WordPress — SQLi author__not_in (GHSA-fpp7-x2x2-2mjf)
• Avis de sécurité GitHub WordPress — API REST des notes (GHSA-6x83-fcf5-r65g)
• NVD — CVE-2026-63030 · NVD — CVE-2026-3906
• Rapid7 — ETR: CVE-2026-63030 wp2shell
• VulnCheck — WP2Shell (CVE-2026-63030 & CVE-2026-60137)
• Versions WordPress (cibles sûres : 6.8.6 / 6.9.5 / 7.0.2)

Avertissement

Cet outil est destiné uniquement aux tests de sécurité autorisés. Vous êtes responsable de vous assurer que vous avez la permission de scanner toute cible. Le scan non autorisé peut être illégal. Les auteurs déclinent toute responsabilité en cas d'utilisation abusive.