
🔥 XSS2Shell — CVE-2026-64638-Scanner & PoC-Toolkit
Verhaltensbasierter Massen-Scanner und beweistauglicher PoC-Generator für die WordPress-Pre-Auth-XSS-zu-RCE-Kette, die über 500 Millionen Websites betrifft.
Nur Erkennung. Keine Waffenisierung. Entwickelt für Bug-Bounty-Programme und Blue Teams.
Was ist das? • Schnellstart • Shodan-Dorks • Verwendung • Entscheidungsmatrix • Erkennung • FAQ
Durchsuchen Sie vor dem Scannen das Internet nach potenziell verwundbaren WordPress-Instanzen:
http.component:"wordpress" -http.title:"Just a moment"
Findet WordPress-Seiten und schließt dabei Cloudflare-Seiten im Modus "I'm Under Attack" sowie Bot-Schutz-Seiten aus, die automatisierte Anfragen blockieren oder mit einer Challenge beantworten.
http.component:"wordpress" http.title:"Log In"
Gibt nur WordPress-Anmeldeseiten zurück — genau die Angriffsfläche für CVE-2026-64638.
http.component:"wordpress" "wp-content" "?ver=7.0" -"?ver=7.0.3"
Markiert WordPress-7.0.x-Instanzen ohne den 7.0.3-Patch per Asset-Versions-Fingerprinting.
http.component:"wordpress" http.html:"wp-login.php"
Erfasst Seiten, auf denen wp-login.php erreichbar ist, aber nicht unbedingt die aktuelle Seite ist — für eine breitere Abdeckung.
http.component:"wordpress" -http.title:"Just a moment" -http.title:"Attention Required" -org:"Cloudflare"
Aggressiver Filter, der die meisten Cloudflare-geschützten Ziele entfernt. Für Scans in großem Maßstab mit --active verwenden — Cloudflare drosselt oder blockiert die Probe-Anfrage.
Tipp: Exportieren Sie Shodan-Ergebnisse mit
shodan downloadund leiten Sie die Hostnamen direkt inxss2shell_mass.py -iweiter.
Am 7. August 2026 hat pwn.ai CVE-2026-64638 (XSS2Shell) offengelegt — eine kritische Pre-Auth-Cross-Site-Scripting-Schwachstelle im WordPress-Core, die sich bis hin zur Remote-Codeausführung auf dem Server ausweiten lässt. [citation:pwn.ai blog]
Der Fehler nutzt eine Parser-Diskrepanz zwischen PHP strip_tags() und WordPress wp_kses_post() aus:
strip_tags() verwendet < unmittelbar gefolgt von einem Buchstaben, um HTML-Tags zu identifizieren. < area id=...> (mit einem Leerzeichen) wird als Text behandelt — es überlebt.wp_kses_post() (KSES) erkennt < area als gültiges <area>-Element — und <area> ist in KSES auf der Whitelist. [citation:pwn.ai blog]Ein fehlgeschlagener Login mit einem speziell präparierten Benutzernamen < area id=ajaxurl href=/?rest_route=/&_method=GET&_jsonp=alert>... umgeht beide Sanitizer, wird als Live-DOM auf der Anmeldeseite gerendert, kapert das eigene user-profile.js-Skript von WordPress per DOM-Clobbering und löst alert() im WordPress-Ursprung aus — null Klicks, keine Authentifizierung, keine Cookies erforderlich. [citation:pwn.ai blog]
Zu einem angemeldeten Administrator eskaliert? Dieselbe Primitive stiehlt Application Passwords per Same-Origin-Method-Execution (SOME), lädt ein bösartiges Plugin hoch und führt PHP als www-data aus. [citation:pwn.ai blog] [citation:hadrian.io blog]
Betroffen: WordPress 6.4 bis 7.0.2 — in 7.0.3 gepatcht, mit Backports bis 4.7+.
Auswirkungen: ~500 Millionen Websites zum Zeitpunkt der Offenlegung. [citation:pwn.ai blog]
| Ressource | Link |
|---|---|
| Originale Offenlegung (pwn.ai) | pwn.ai/blog/xss2shell |
| Technische Analyse (Hadrian) | hadrian.io/blog/wordpress-xss2shell |
| WordPress-Sicherheitshinweis (GHSA) | GHSA-52p2-r8wf-jcrf |
| SOME-Angriffsforschung (2022) | pwn.ai/blog/bypass-csp-using-wordpress |
| WordPress-7.0.3-Release | wordpress.org/news/2026/08/wordpress-7-0-3-release |
Dies ist ein reines Erkennungs-Toolkit. Es beinhaltet keine Waffenisierung der Schwachstelle — es gibt Sicherheitsforschern, Bug-Bounty-Jägern und Blue Teams alles an die Hand, um:
"Ein Versionsstring sagt, welcher Patchstand der Code sein sollte.
Nur das Verhalten des Anmeldeseiten-Sanitizers sagt, ob der Fehler greift."
Verwaltete Hosts portieren Sicherheitspatches still zurück, ohne die Versionsstrings zu erhöhen. Login-Härtungs-Plugins ersetzen die Fehlermeldung vollständig und unterbinden damit den Reflexionskanal selbst auf unsicheren Versionen. Reine Versions-Scanner erzeugen False Positives und False Negatives. Dieser Scanner sendet eine einzige harmlose Probe und klassifiziert das tatsächliche Sanitizer-Verhalten.
git clone https://github.com/jakestone/xss2shell.git
cd xss2shell
pip install -r requirements.txt
# 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
# 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/
Öffnen Sie die generierte .poc.html in Ihrem Browser und zeichnen Sie dabei ein Video auf → wenn alert() ausgelöst wird, haben Sie Pre-Auth-XSS-Beweise erfasst.
xss2shell_mass.py)usage: xss2shell_mass.py [-h] -i INPUT [-o OUTPUT]
[--active] [--workers WORKERS]
[--timeout TIMEOUT] [--quiet]
| Flag | Beschreibung |
|---|---|
-i, --input | Datei mit einem Host pro Zeile (nackte Domain oder vollständige URL) |
-o, --output | Basis-Pfad für Ausgabedateien (erzeugt .csv + .json) |
--active | Verhaltensprobe aktivieren — ein fehlgeschlagener Login pro Host |
--workers | Thread-Pool-Größe (Standard: 50, max. ~200 bei guten Verbindungen) |
--timeout | HTTP-Timeout in Sekunden (Standard: 10) |
--quiet | Nur confirmed_vulnerable, vulnerable und likely_vulnerable ausgeben |