🔥 XSS2Shell — Scanner CVE-2026-64638 et kit PoC

Scanner de masse axé sur le comportement et générateur de PoC de qualité probante pour la chaîne XSS vers RCE en pré-authentification de WordPress, affectant plus de 500 millions de sites web.
Détection uniquement. Aucune weaponisation. Conçu pour les programmes de bug bounty et les blue teams.

Vérificateur officiel : https://pwn.ai/xss2shell-checker.html

Qu'est-ce que c'est ? • Démarrage rapide • Shodan Dorks • Utilisation • Matrice de décision • Détection • FAQ

🔎 Shodan Dorks

Recherchez des instances WordPress potentiellement vulnérables sur Internet avant de scanner :

Découverte WordPress de base

http.component:"wordpress" -http.title:"Just a moment"

Trouve les sites WordPress tout en excluant les pages en mode « I'm Under Attack » / protection anti-bot de Cloudflare qui bloqueront ou défieront les requêtes automatisées.

Cibler les pages de connexion

http.component:"wordpress" http.title:"Log In"

Ne renvoie que les pages de connexion WordPress — la surface d'attaque exacte de CVE-2026-64638.

Recherche par version spécifique

http.component:"wordpress" "wp-content" "?ver=7.0" -"?ver=7.0.3"

Signale les instances WordPress 7.0.x sans le correctif 7.0.3 grâce à l'empreinte des versions des ressources.

Élargir la surface

http.component:"wordpress" http.html:"wp-login.php"

Capture les sites où wp-login.php est accessible mais n'est peut-être pas la page courante — couverture plus large.

Exclusions Cloudflare (combinées)

http.component:"wordpress" -http.title:"Just a moment" -http.title:"Attention Required" -org:"Cloudflare"

Filtre agressif qui élimine la plupart des cibles derrière Cloudflare. À utiliser lors de scans à grande échelle avec --active — Cloudflare limitera le débit ou bloquera la requête de la sonde.

Astuce : exportez les résultats Shodan avec shodan download et canalisez les noms d'hôtes directement vers xss2shell_mass.py -i.

🚨 Qu'est-ce que CVE-2026-64638 ?

Le 7 août 2026, pwn.ai a divulgué CVE-2026-64638 (XSS2Shell) — une vulnérabilité critique de cross-site scripting avant authentification dans le cœur de WordPress qui s'enchaîne jusqu'à l'exécution de code à distance sur le serveur. [citation:pwn.ai blog]

Le bug exploite un désaccord entre l'analyseur syntaxique de PHP strip_tags() et celui de WordPress wp_kses_post() :

• strip_tags() utilise < immédiatement suivi d'une lettre pour identifier les balises HTML. < area id=...> (avec un espace) est traité comme du texte — il survit.
• wp_kses_post() (KSES) reconnaît < area comme un élément <area> valide — et <area> est sur la liste blanche de KSES. [citation:pwn.ai blog]

Un échec de connexion avec un nom d'utilisateur spécialement conçu < area id=ajaxurl href=/?rest_route=/&_method=GET&_jsonp=alert>... contourne les deux assainisseurs, est rendu comme DOM vivant sur la page de connexion, détourne le script user-profile.js de WordPress via le DOM clobbering et déclenche alert() dans l'origine WordPress — zéro clic, zéro authentification, zéro cookie requis. [citation:pwn.ai blog]

Escaladée jusqu'à un administrateur connecté ? La même primitive vole les mots de passe d'application via l'exécution de méthode de même origine (SOME), téléverse un plugin malveillant et exécute du PHP en tant que www-data. [citation:pwn.ai blog] [citation:hadrian.io blog]

Versions affectées : WordPress 6.4 à 7.0.2 — corrigé dans 7.0.3 avec des rétroportages vers 4.7+.
Impact : ~500 millions de sites web au moment de la divulgation. [citation:pwn.ai blog]

📰 Ressources clés

⚡ Ce que fait ce kit

Il s'agit d'un kit de détection uniquement. Il ne weaponise pas la vulnérabilité — il donne aux chercheurs en sécurité, aux chasseurs de bug bounty et aux blue teams tout ce qu'il faut pour :

1. Scanner en masse des centaines d'hôtes WordPress en quelques minutes avec une précision axée sur le comportement
2. Générer des pages de PoC de qualité probante pour prouver que le XSS se déclenche (alert() uniquement)
3. Classer les résultats avec des niveaux de confiance précis — aucun faux positif provenant de la correspondance de versions

🔑 Pourquoi l'approche comportementale ?

« Une chaîne de version indique le niveau de correctif que le code devrait avoir.
Seul le comportement de l'assainisseur de la page de connexion indique si le bug se déclenche. »

Les hébergeurs gérés rétroportent silencieusement des correctifs de sécurité sans modifier les chaînes de version. Les plugins de durcissement de connexion remplacent entièrement le message d'erreur, supprimant le canal de réflexion même sur les versions non sécurisées. Les scanners basés uniquement sur la version produisent des faux positifs et des faux négatifs. Ce scanner envoie une seule sonde bénigne et classe le comportement réel de l'assainisseur.

🚀 Démarrage rapide

Installation

git clone https://github.com/jakestone/xss2shell.git
cd xss2shell
pip install -r requirements.txt

Scan en 5 minutes

# Passive — no probes sent to target, version + endpoint fingerprinting only
python3 xss2shell_mass.py -i domains.txt -o results

# Active — sends ONE benign failed-login per host (authorized assets only!)
python3 xss2shell_mass.py -i domains.txt -o results --active --workers 80

Générer des PoC probants

# Single target
python3 make_poc.py --target https://blog.example.com

# Batch from scanner output
python3 make_poc.py --from-results results.csv -o pocs/

Ouvrez le fichier .poc.html généré dans votre navigateur tout en enregistrant une vidéo → si alert() se déclenche, vous avez capturé une preuve de XSS avant authentification.

📖 Utilisation

Scanner de masse (xss2shell_mass.py)

usage: xss2shell_mass.py [-h] -i INPUT [-o OUTPUT]
                         [--active] [--workers WORKERS]
                         [--timeout TIMEOUT] [--quiet]

Preuves du scan passif (aucune sonde active, toujours collectées)

1. Page d'accueil → empreinte WordPress (meta generator, paramètres ?ver= des ressources, références wp-content)
2. Page de connexion → accessibilité, détection du formulaire de connexion standard, gadget user-profile.js chargé, versions des ressources du cœur
3. Test de fumée REST JSONP → GET inoffensif sur /?rest_route=/&_method=GET&_jsonp=<random> — la voie JSONP est-elle ouverte ?
4. Repli Feed/Readme → extraction de la version si l'empreinte de la page d'accueil est absente

Sonde active (un POST, option --active)

Envoie une seule tentative de connexion échouée avec le nom d'utilisateur < area id=<RANDOM> href=/x2s> et classe la réponse HTML :

• bypass — Un véritable élément <area> avec notre marqueur a survécu → désaccord strip_tags/KSES CONFIRMÉ
• escaped — Marqueur présent mais encodé en entités → correctif ou durcissement présent
• stripped — Erreur WP par défaut affichée, balises supprimées → acevomod ou corrigé
• closed — Aucune réflexion du nom d'utilisateur → plugin de durcissement de connexion installé

Générateur de PoC (make_poc.py)

usage: make_poc.py [-h] [--target TARGET] [--from-results FROM_RESULTS]
                   [-o OUTDIR]

Génère la page PoC publiée par pwn.ai pour chaque cible — le formulaire HTML exact qui déclenche alert() sur un WordPress non corrigé. Trois variantes de payload sont incluses en commentaires :

🧠 Matrice de décision

Le moteur de décision du scanner combine la classification de version (issue de l'API stable-check de WordPress.org) avec les preuves comportementales pour produire 10 verdicts distincts :

Format de sortie

Colonnes CSV : host, url, status, checker_status, wp_version, branch_status, evidence, http, ms, error

La colonne checker_status correspond au vocabulaire du vérificateur public de pwn.ai (vulnerable / patched / not_wordpress / unreachable / inconclusive / error) pour une corrélation directe.

🔍 Signatures de détection (Blue Team / SOC)

Si vous êtes du côté de la défense, voici les signaux forensiques laissés par cette vulnérabilité :

Côté serveur (journaux du serveur web / WAF)

# Primary signal: encoded '<' in the log parameter
POST /wp-login.php  →  log=%3C...  (URL-encoded < in username field)

# Higher confidence: paired with REST pivoting
GET /?rest_route=/&_method=GET&_jsonp=...     # JSONP callback
GET /wp-json/wp/v2/statuses/publish?_jsonp=...  # WAF-bypass variant

# Escalation stage indicators
GET /wp-admin/authorize-application.php?success_url=<off-origin>
POST /wp-admin/update.php?action=upload-plugin
GET /wp-content/plugins/<random>/shell.php

Règle de blocage Edge / WAF

Bloquez POST /wp-login.php lorsque le paramètre log contient %3C (< encodé en URL). Les noms d'utilisateur WordPress valides ne contiennent jamais de chevrons. Ne pas cibler des balises spécifiques — KSES autorise la tabulation, le saut de ligne et le retour chariot après < ainsi que toute balise en liste blanche, donc une règle spécifique à une balise est trivialement contournée. [citation:hadrian.io blog]

Point clé pour les défenseurs

Le callback _jsonp= au stade de l'escalade utilise des points pour parcourir les propriétés (par ex., window.opener.approve.click). Signalez les requêtes REST avec des callbacks JSONP à points comme indicateurs forts d'exploitation. [citation:hadrian.io blog]

⚖️ Utilisation légale et éthique

THIS TOOL IS DETECTION-ONLY. IT DOES NOT:
  ✗ Weaponize the JSONP callback beyond the public alert()
  ✗ Include admin-lure pages or Application Password capture
  ✗ Include REST abuse, plugin upload, or PHP shell code
  ✗ Execute more than one failed login per target per scan

YOU MUST:
  ✓ Only scan assets you own or have written authorization to test
  ✓ Only generate PoCs for your own browser on your own server
  ✓ Never send PoC links to site admins/users
  ✓ Never escalate past alert() without program written approval
  ✓ Follow the bug bounty program scope and rules

This toolkit exists for authorized security research, bug bounty
programs, and defensive detection engineering. Misuse is your
responsibility.

📁 Structure du dépôt

xss2shell/
├── README.md                  ← You are here
├── xss2shell_mass.py          ← Behavior-first mass scanner (v1.1.0)
├── make_poc.py                ← Evidence-grade PoC page generator
├── requirements.txt           ← Python dependencies (just `requests`)
├── .gitignore                 ← Ignores scan outputs and cache
└── example/
    ├── domains.txt            ← Example input file
    └── example_output.csv     ← Example scan output

❓ FAQ

Q : Pourquoi ne pas simplement vérifier la chaîne de version WordPress ?
R : Les hébergeurs gérés (WP Engine, Kinsta, Pantheon, etc.) rétroportent fréquemment des correctifs de sécurité sans modifier la version. Les plugins de durcissement de connexion remplacent entièrement le message d'erreur. Ces deux cas produisent des faux positifs dans les scanners basés uniquement sur la version et des faux négatifs pour les versions masquées. Ce scanner teste le comportement réel de l'assainisseur.

Q : La sonde --active est-elle dangereuse ?
R : Non. Elle envoie exactement un échec de connexion avec un nom d'utilisateur marqueur bénin. Elle ne tente pas d'exécuter du JavaScript, n'énumère pas les noms d'utilisateur valides et ne déclenche aucune exploitation réelle. Elle est moins intrusive qu'une tentative de connexion standard.

Q : Cet outil peut-il être utilisé pour des scans non autorisés ?
R : Non. La sonde active envoie un POST HTTP vers /wp-login.php, ce qui est une requête au serveur cible. À utiliser uniquement sur des actifs que vous possédez ou pour lesquels vous disposez d'une autorisation écrite explicite de test.

Q : Quelle est la différence entre vulnerable et confirmed_vulnerable ?
R : vulnerable signifie que l'API WordPress.org indique que la version est non sécurisée, mais nous n'avons pas confirmé comportementalement le désaccord strip_tags/KSES. confirmed_vulnerable signifie que nous avons envoyé une sonde et que l'élément <area> a survécu aux deux assainisseurs — la chaîne publiée peut se déclencher.

Q : Puis-je l'utiliser pour les rapports de mon programme de bug bounty ?
R : Oui ! La colonne checker_status correspond directement au vocabulaire du vérificateur public de pwn.ai pour une corrélation facile. Associez les résultats de scan aux preuves vidéo PoC de make_poc.py pour des rapports complets.

Q : Cet outil détecte-t-il la chaîne RCE ?
R : Non. Ce kit détecte le point d'entrée XSS avant authentification. La chaîne RCE complète nécessite un administrateur connecté, des mots de passe d'application activés et des permissions de téléversement de plugin — des conditions que ce scanner n'évalue pas. Le scanner se concentre sur ce qui est observable depuis l'extérieur : le contournement de l'assainisseur.

🏆 Crédits et références

• Découverte et divulgation : pwn.ai — découverte de manière autonome par un système d'IA multi-agents
• Fondation de la technique SOME : Paulos Yibelo — recherche de 2022 nominée pour les Top Web Hacking Techniques
• Analyse technique : Hadrian — recommandations complètes de détection et d'atténuation
• CVE : CVE-2026-64638 / GHSA-52p2-r8wf-jcrf
• Correctif : WordPress 7.0.3

_{Conçu par 0xlipon • Détection uniquement • Pour usage autorisé uniquement}