WP2Shell Detektor und Validierungs-PoC

CVE-Abdeckung: CVE-2026-63030 und CVE-2026-60137 Verwendungszweck: Autorisierte Sicherheitstests, defensive Validierung und nur temporäre lokale Labore

WP2Shell ist eine WordPress-Core-Verwundbarkeitskette, die einen Pre-Authentifizierung-REST-API-Batch-Route-Confusion-Bug (CVE-2026-63030) mit einer WP_Query-author__not_in-SQL-Injection-Primitive (CVE-2026-60137) kombiniert. Dieses Repository bietet einen Python-Proof-of-Concept-Scanner und sicheren Validator, damit Verteidiger betroffene WordPress-Installationen identifizieren, das verwundbare Verhalten in einem isolierten Labor bestätigen und die Abhilfe überprüfen können – ohne Daten extrahieren oder Code ausführen zu müssen.

Übersicht

Dieses Projekt identifiziert WordPress-Installationen und validiert die beiden Verwundbarkeitsprimitive der WP2Shell WordPress-Core-Verwundbarkeitskette:

CVE-2026-63030 — REST-API-Batch-Route-Confusion.
CVE-2026-60137 — unvollständige Bereinigung von WP_Query::author__not_in, die zu SQL-Injection führen kann, wenn angreiferkontrollierte Eingabe den Parameter erreicht.

Wenn beide Bedingungen vorliegen, kann eine nicht authentifizierte Anfrage über den REST-API-Batch-Endpunkt die verwundbare SQL-Konstruktion erreichen. Öffentliche Advisories beschreiben die kombinierte Auswirkung als potenziell zur Remote-Code-Ausführung führend.

Dieses Repository sollte nur auf Systemen verwendet werden, die Ihnen gehören oder für die Sie ausdrücklich zur Prüfung autorisiert sind. Bevorzugen Sie ein isoliertes Docker- oder Virtual-Machine-Labor, das an 127.0.0.1 gebunden ist.

Sicherheitshinweis

Die aktuelle Quelldatei enthält zustandsändernde Funktionalität, einschließlich Datenbank-Datenextraktionsversuche, Dateischreibversuche, Authentifizierungsabläufe, Administratorerstellung, Plugin-Upload und Befehlsausführung.

WordPress-Fingerprinting.
Versionseinschätzung.
Lokale Quellbaum-Versionsprüfungen.
Sichere Route-Confusion-Validierung.
Zerstörungsfreie zeitbasierte SQL-Injection-Bestätigung in einem isolierten Labor.
Berichterstellung, Beweissammlung und Abhilfe.

Verwundbarkeitszusammenfassung

CVE-2026-63030 — REST-API-Batch-Route-Confusion

Betroffene WordPress-Versionen können die Ausrichtung zwischen internen Arrays verlieren, die zur Verfolgung von verwendet werden:

Geparsten Batch-Anfragen.
Abgeglichenen REST-Route-Handlern.
Validierungsergebnissen.

Wenn ein fehlerhaftes Batch-Mitglied in ein internes Array aufgenommen wird, aber nicht in ein anderes, können spätere Anfragen dem falschen Handler zugeordnet werden. Eine Anfrage kann daher als eine Route validiert, aber mit dem Callback einer anderen Route ausgeführt werden.

Sicherheitsauswirkungen:

REST-Anfrage/Handler-Desynchronisation.
Validierung gegen das falsche Routenschema.
Unerwartete verschachtelte Batch-Ausführung.
Erreichbarkeit sonst eingeschränkter Codepfade vor der Authentifizierung.
In Kombination mit CVE-2026-60137 potenzielle SQL-Injection und weitere Kompromittierung.

CVE-2026-60137 — `author__not_in` SQL-Injection

Die betroffene WP_Query-Implementierung normalisiert author__not_in nicht konsistent, bevor es zur Konstruktion einer SQL NOT IN (...)-Bedingung verwendet wird.

Der Parameter erwartet normalerweise eine Liste von Integer-Autor-IDs. Wenn ein skalarer String die verwundbare Abfragekonstruktion ohne die beabsichtigte REST-Schema-Validierung erreicht, kann unsichere SQL-Struktur in die Datenbankabfrage gelangen.

Sicherheitsauswirkungen:

Blinde SQL-Injection.
Boolesche oder zeitbasierte Datenbank-Orakel.
Potenzielle Offenlegung von WordPress-Datenbankinhalten.
Erhöhte Auswirkung bei Verkettung mit CVE-2026-63030.

Betroffene Versionen

WordPress veröffentlichte am 17. Juli 2026 Korrekturen und aktivierte erzwungene automatische Updates für betroffene Installationen aufgrund des Schweregrads.

Verwundbarkeits-Workflow```text

Unauthenticated client | v WordPress REST batch endpoint | v Malformed batch member creates request/handler misalignment | v Later request is validated against one route but dispatched using another route's handler | v Scalar author_exclude reaches WP_Query as author__not_in | v Unsafe value reaches SQL NOT IN (...) construction | v Blind SQL timing or Boolean oracle | v Potential database compromise | v Potential application-level compromise and RCE

Der Detektor sollte nach der Bestätigung der Route-Confusion- und SQL-Injection-Primitive stoppen. Es muss keine Daten extrahieren oder Befehle ausführen, um festzustellen, dass eine betroffene Installation verwundbar ist.

---

## Erkennungsablauf

### Phase 1 — Ziel normalisieren

Das Tool:

1. Fügt ein standardmäßiges `http`- oder `https`-Schema hinzu, falls fehlend.
2. Normalisiert den WordPress-Installationspfad.
3. Lehnt nicht unterstützte URL-Schemata und eingebettete Anmeldedaten ab.
4. Wendet Weiterleitungs-, Proxy-, TLS- und Zeitüberschreitungsrichtlinien an.

### Phase 2 — WordPress identifizieren

Der Scanner prüft auf:

- `wp-content/`-Referenzen.
- `wp-includes/`-Referenzen.
- WordPress-Generator-Metadaten.
- REST-API-Erkennungslinks.
- WordPress-REST-Indexstruktur.
- Den `wp/v2`-Namespace.
- Optionale Feed- und `readme.html`-Fingerabdrücke.

### Phase 3 — Version ermitteln

Versionsnachweise können aus folgenden Quellen stammen:

- HTML-Generator-Metadaten.
- Feed-Generator-Metadaten.
- WordPress-Core-Asset-Abfragezeichenfolgen.
- HTTP-Generator-Header.
- `readme.html`.
- Eine lokale `wp-includes/version.php`-Datei.

Nachweise werden bewertet und abgeglichen. Widersprüchliche Remote-Versionsanzeigen senken die Vertrauenswürdigkeit.

### Phase 4 — Batch-Route-Exposition prüfen

Der Scanner versucht, `/batch/v1` zu entdecken durch:```text
/?rest_route=/
/wp-json/

Die Route kann entweder über folgende(n) Weg(e) adressiert werden:```text /?rest_route=/batch/v1 /wp-json/batch/v1

### Phase 5 — Sichere Route-Confusion-Sonde

Die sichere Sonde enthält:

1. Einen absichtlich fehlerhaften internen Pfad.
2. Eine Anfrage an eine ungültige Post-ID mit einer harmlosen verschachtelten öffentlichen `GET`-Anfrage.
3. Eine darauffolgende `/batch/v1`-Anfrage.

Ein anfälliger Server gibt eine äußere `207 Multi-Status`-Antwort zurück, in der die ungültige Post-Anfrage als eine verschachtelte Batch-Anfrage verarbeitet wird.

Der Detektor meldet:```text
route-confusion-observed

wenn es folgendes sieht:

Den erwarteten parse_path_failed-Marker.
Eine zweite äußere Antwort mit Status 207.
Ein verschachteltes responses-Array, das zeigt, dass die harmlose interne Anfrage ausgeführt wurde.

Phase 6 — Zeitbasierte SQLi-Bestätigung

Ein nicht-destruktiver SQLi-Validator sollte gepaarte Anfragen senden, die sich nur durch eine konstante Boolesche Bedingung unterscheiden:```text False control -> no deliberate database delay True test -> deliberate database delay

Der Validator muss:

- Den erwarteten äußeren HTTP `207` akzeptieren.
- Sowohl den äußeren als auch die verschachtelten Batch-Envelope parsen.
- Die Markierungen für fehlerhafte Anfragen überprüfen.
- Sicherstellen, dass die verschachtelte SQLi-tragende Anfrage eine gültige Antwort zurückgegeben hat.
- Mehrere wahre und falsche Proben sammeln.
- Die Probenreihenfolge zufällig oder abwechselnd anordnen.
- Mediane vergleichen statt einer einzelnen Anfrage.
- Unzureichende Messungen als `inconclusive` melden.

Eine wiederholbare Lücke zwischen wahren und falschen Proben bestätigt, dass die vom Angreifer kontrollierte Eingabe die SQL-Auswertung erreicht hat. Es müssen keine Datenbankinhalte ausgewählt oder extrahiert werden.

---

## Anforderungen

- Python 3.9 oder später.
- Es werden keine Drittanbieter-Python-Pakete für das bereitgestellte Skript benötigt.
- Netzwerkzugriff auf die autorisierte WordPress-Installation.
- Für lokale Tests:
  - Ein entsorgbares WordPress 7.0.1 oder 6.9.4 Labor.
  - Ein Datenbank-Container oder eine dedizierte Testdatenbank.
  - Der an `127.0.0.1` gebundene Webdienst.
  - Keine Produktionsanmeldedaten oder -daten.

Python prüfen:```bash
python3 --version

Optionale Syntaxvalidierung:```bash python3 -m py_compile WP2Shell_CVE-2026-63030_POC.py

---

## Installation

Benennen Sie das mitgelieferte Skript in einen vorhersagbaren Dateinamen um:```bash
mv 'poc(1).py' WP2Shell_CVE-2026-63030_POC.py
chmod +x WP2Shell_CVE-2026-63030_POC.py

Globale Hilfe anzeigen:```bash python3 WP2Shell_CVE-2026-63030_POC.py --help

Version anzeigen:```bash
python3 WP2Shell_CVE-2026-63030_POC.py --version

Befehle

Das Skript definiert drei Befehle:```text remote Fingerprint and scan HTTP(S) WordPress targets. local Read the installed WordPress version from a source tree. exploit State-changing proof-of-concept path.

### Aktueller Build-Status

| Befehl | Status |
|---|---|
| `local` | Implementiert |
| `remote` | CLI ist definiert, aber `run_remote()` ist derzeit ein Stub und gibt einen Fehler zurück |
| `exploit` | Enthält zustandsändernde Funktionalität; auf ein wegwerfbares lokales Labor beschränken und von defensivem Scannen trennen |

Die Quelle gibt derzeit Folgendes für `remote` aus:```text
Remote scanning not fully implemented in this snippet. Use 'local' or 'exploit'.

Stellen Sie eine vollständige run_remote()-Implementierung wieder her, bevor Sie Bulk-Remote-Scans als funktionsfähig bewerben.

Lokale Versionsbewertung

Der local-Befehl lautet:```text /wp-includes/version.php

und extrahiert `$wp_version`.

## Grundlegende Verwendung```bash
python3 WP2Shell_CVE-2026-63030_POC.py local \
  --wordpress-root /var/www/html

JSON-Bericht```bash

python3 WP2Shell_CVE-2026-63030_POC.py local
--wordpress-root /var/www/html
--format json
--output local-result.json

## Docker-basierte WordPress-Installation

Wenn der WordPress-Container `wordpress` heißt, kopieren oder mounten Sie den Quellbaum auf den Host oder führen Sie die Versionsprüfung innerhalb des Containers durch:```bash
docker compose exec wordpress php -r \
  'require "/var/www/html/wp-includes/version.php"; echo $wp_version, PHP_EOL;'

Verwundbares Lab-Setup mit compose.yaml

Verwenden Sie die bereitgestellte compose.yaml, um ein temporäres lokales Lab auszuführen, das an 127.0.0.1:8080 gebunden ist:```bash docker compose up -d

Sobald die erstmalige WordPress-Einrichtung im Browser unter `http://127.0.0.1:8080` abgeschlossen ist, können Sie Folgendes ausführen:```bash
python3 WP2Shell_CVE-2026-63030_POC.py remote \
  --authorized \
  --target http://127.0.0.1:8080 \
  --active-probe \
  --format json

Um das Labor zu stoppen und zu entfernen:```bash docker compose down -v

## Optionen für lokale Befehle

| Option | Beschreibung |
|---|---|
| `--wordpress-root PATH` | Erforderliches Verzeichnis, das `wp-includes/version.php` enthält |
| `-f, --format` | `table`, `json`, `jsonl` oder `csv` |
| `-o, --output FILE` | Bericht in eine Datei schreiben |
| `--fail-on` | Exit-Code-Richtlinie: `never`, `vulnerable` oder `unknown` |

## Beispiel für Ausgabe einer anfälligen Version```json
[
  {
    "selected_version": "7.0.1",
    "version_assessment": "affected-wp2shell",
    "verdict": "CONFIRMED_AFFECTED_VERSION",
    "severity": "critical"
  }
]

Ein lokales Versionsergebnis bestätigt, dass die installierte Version im veröffentlichten betroffenen Bereich liegt. Es allein zeigt weder die Ausnutzbarkeit zur Laufzeit noch die Wirkung eines zurückportierten Patches.

Remote-Scanner-Schnittstelle

Der remote-Parser unterstützt die folgenden Argumente, aber die bereitgestellte Implementierung von run_remote() ist derzeit unvollständig.

Einzelnes Ziel

Erwartete Schnittstelle nach Wiederherstellung von run_remote():```bash python3 WP2Shell_CVE-2026-63030_POC.py remote
--authorized
--target https://wordpress.example
--active-probe

## Mehrere explizite Ziele```bash
python3 WP2Shell_CVE-2026-63030_POC.py remote \
  --authorized \
  --target https://site-one.example \
  --target https://site-two.example \
  --active-probe

Zieldatei

Erstelle targets.txt:```text https://site-one.example/ https://site-two.example/blog/

Erwartete Schnittstelle:```bash
python3 WP2Shell_CVE-2026-63030_POC.py remote \
  --authorized \
  --targets-file targets.txt \
  --active-probe \
  --format jsonl \
  --output results.jsonl

Standardeingabe```bash

cat targets.txt | python3 WP2Shell_CVE-2026-63030_POC.py remote
--authorized
--stdin

## Proxy-Nutzung```bash
python3 WP2Shell_CVE-2026-63030_POC.py remote \
  --authorized \
  --target https://wordpress.example \
  --active-probe \
  --proxy http://127.0.0.1:8081

Benutzerdefinierter Anfrage-Header```bash

python3 WP2Shell_CVE-2026-63030_POC.py remote
--authorized
--target https://wordpress.example
--header 'Authorization: Bearer TEST_TOKEN'

## Remote-Optionen

| Option | Zweck |
|---|---|
| `-u, --target URL` | Ziel-URL; wiederholbar |
| `-l, --targets-file DATEI` | Ein Ziel pro Zeile; wiederholbar |
| `--stdin` | Ziele von stdin lesen |
| `--authorized` | Erforderliche Autorisierungsbestätigung |
| `--default-scheme` | Schema, das bei Auslassung angewendet wird |
| `-c, --concurrency` | Gleichzeitige Zielarbeiter |
| `--rate` | Aggregierte Anforderungsrate |
| `--timeout` | Zeitüberschreitung pro Anforderung |
| `--retries` | Wiederholungsanzahl |
| `--max-targets` | Maximale Anzahl akzeptierter Ziele |
| `--max-body-bytes` | Maximale beibehaltene Antworttextgröße |
| `-k, --insecure` | TLS-Verifizierung deaktivieren |
| `--no-redirects` | Weiterleitungen deaktivieren |
| `--allow-cross-host-redirects` | Weiterleitungen zu einem anderen Host erlauben |
| `--proxy` | HTTP/HTTPS-Proxy |
| `-H, --header` | Benutzerdefinierter Header; wiederholbar |
| `--user-agent` | User-Agent überschreiben |
| `--fingerprint-level` | `quick`, `standard` oder `extended` |
| `--active-probe` | Senden der sicheren Route-Confusion-Sonde |
| `--rest-endpoint` | `query`, `pretty` oder `both` |
| `--include-request-log` | URL-, Status- und Zeitmetadaten hinzufügen |
| `-f, --format` | `table`, `json`, `jsonl` oder `csv` |
| `-o, --output` | Ausgabe in eine Datei schreiben |
| `--fail-on` | Exit-Code-Richtlinie |

---

# Sichere Laufzeitvalidierung

Für eine zerstörungsfreie lokale Validierung beider Primitiven verwenden Sie einen dedizierten Validator, der:

- Nicht-Loopback-Hosts ablehnt.
- Zuerst Route-Confusion bestätigt.
- Zeitproben nur nach erfolgreicher Route-Confusion unter konstanten Bedingungen ausführt.
- Keine Daten extrahiert oder Befehle ausführt.

Beispiel-Workflow:```bash
python3 wp2shell_local_validator.py check \
  --authorized \
  --target http://127.0.0.1:8080 \
  --sqli \
  --delay 2 \
  --samples 4 \
  --warmups 2 \
  --debug \
  --dump-dir evidence \
  --output result.json

Erwartetes Zeitmuster des verwundbaren Labors:```text False controls: approximately 0.03–0.10 seconds True tests: consistently delayed

Erwartetes Urteil:```text
FULL_VULNERABILITY_PRIMITIVES_CONFIRMED

Ein Timing-Test kann die Verzögerungsausführung mehrmals ausführen, sodass eine konfigurierte Verzögerung von zwei Sekunden eine beobachtete Verzögerung von nahezu vier Sekunden verursachen kann. Das wichtige Signal ist die wiederholbare Trennung zwischen wahren und falschen Bedingungen.

Ausgabeformate

Tabelle

Am besten für die interaktive Terminalnutzung:```bash --format table

### JSON

Am besten für Beweise und Integration:```bash
--format json --output result.json

JSON Lines

Am besten für große Zielmengen:```bash --format jsonl --output results.jsonl

### CSV

Am besten für Tabellenkalkulationen und Berichterstellung:```bash
--format csv --output results.csv

Bewertungen

Exit-Codes

Der Scanner verwendet richtlinienbasierte Exit-Codes.

Ein Sicherheitslückenfund kann daher absichtlich einen von Null verschiedenen Status zurückgeben.

Beispiel:```bash python3 WP2Shell_CVE-2026-63030_POC.py local
--wordpress-root /var/www/html
--fail-on vulnerable

echo $?

## Differentialtest zwischen angreifbarer und behobener Version

Eine starke Validierung vergleicht zwei saubere Umgebungen.

### Angreifbare Umgebung```text
WordPress 7.0.1

Erwartet:```text route-confusion-observed repeatable true/false SQL timing difference

### Feste Umgebung```text
WordPress 7.0.2

Erwartet:```text route-confusion-not-observed SQLi timing test not reached or no valid timing oracle

Erstellen Sie beim Ändern der Versionen immer das WordPress-Volume neu. Wenn Sie ein Volume wiederverwenden, können alte oder automatisch aktualisierte Kerndateien erhalten bleiben.```bash
docker compose down -v
docker compose pull
docker compose up -d

Behebung

Aktualisieren Sie sofort auf eine der behobenen Versionen oder eine neuere unterstützte Version:

WordPress 6.8.6.
WordPress 6.9.5.
WordPress 7.0.2.
WordPress 7.1 beta2 oder höher, für Tests mit Vorabversionen.

Temporäre Kontrollen sollten beide Batch-Endpunkt-Formulare abdecken:```text /wp-json/batch/v1 /?rest_route=/batch/v1

Zusätzliche Abwehrmaßnahmen:

1. Überprüfen Sie die Protokolle auf anonyme Batch-Anfragen, fehlerhafte interne URLs, verschachtelte Batch-Strukturen und ungewöhnliche `author_exclude`-Werte.
2. Überprüfen Sie Administrator-Konten, Plugin-Änderungen, unerwartete PHP-Dateien und Datenbankzugriffe nach jeder Phase der Offenlegung.
3. Überprüfen Sie die Checksummen des WordPress-Kerns und stellen Sie aus einem bekannten guten Backup wieder her, wenn ein Kompromiss vermutet wird.
4. Wechseln Sie Geheimnisse und Anmeldeinformationen, die in der WordPress-Datenbank gespeichert sind, wenn eine SQL-Injection-Ausnutzung stattgefunden haben könnte.

Das Blockieren des Endpunkts ist eine vorübergehende Maßnahme und kein Ersatz für die Aktualisierung des WordPress-Kerns.

---

## Erkennungsideen

Mögliche Indikatoren umfassen:

- Anonyme `POST`-Anfragen an eine der beiden Batch-Endpunkt-Formulare.
- HTTP `207`-Antworten, die verschachtelte `responses`-Arrays enthalten.
- Fehlerhafte interne URLs in Batch-Anfragekörpern.
- Verschachtelte `requests`-Objekte innerhalb eines anderen Batch-Mitglieds.
- Skalare oder SQL-förmige `author_exclude`-Werte.
- Wiederholte gepaarte Anfragen mit abwechselnd schnellen und verzögerten Antworten.
- Unerwartete Erstellung von WordPress-Administratoren.
- Unerwartete Plugin-Installation oder -Aktivierung.
- Neue PHP-Dateien in beschreibbaren WordPress-Verzeichnissen.
- Datenbankabfragen mit ungewöhnlichen `author__not_in`-Ausdrücken.

---


## Bekannte Einschränkungen des bereitgestellten Skripts

- Die Cookie-Verarbeitung entspricht nicht einer persistenten Browsersitzung.
- Datenbanktabellen-Präfixe werden in einigen Codepfaden angenommen.
- Das Datenbank-`FILE`-Privileg und die Dateisystempfade variieren je nach Bereitstellung.
- `INTO OUTFILE` ist normalerweise eingeschränkt und kann vorhandene Dateien nicht überschreiben.
- WordPress kann die Plugin-Installation durch `DISALLOW_FILE_MODS` deaktivieren.
- Zeitschwellen können durch Proxies, WAFs, PHP-Timeouts, Datenbank-Timeouts und Last beeinflusst werden.
- Versionsstrings können versteckt, gefälscht, zwischengespeichert oder inkonsistent sein.
- Eine beobachtete betroffene Version beweist nicht das Fehlen eines Sicherheits-Backports.
- Ein fehlendes Zeitsignal beweist nicht, dass der Server gepatcht ist.

---

## Referenzen

- WordPress 7.0.2 Sicherheitsveröffentlichung:  
  https://wordpress.org/news/2026/07/wordpress-7-0-2-release/

- WordPress 7.0.2 Dokumentation und geänderte Dateien:  
  https://wordpress.org/documentation/wordpress-version/version-7-0-2/

- NVD — CVE-2026-63030:  
  https://nvd.nist.gov/vuln/detail/CVE-2026-63030

- NVD — CVE-2026-60137:  
  https://nvd.nist.gov/vuln/detail/CVE-2026-60137

- WordPress-Release-Archiv:  
  https://wordpress.org/download/releases/

---

## Rechtliche und ethische Nutzung

Verwenden Sie dieses Projekt nur, wenn:

- Sie das System besitzen oder
- Sie eine ausdrückliche schriftliche Genehmigung haben, und
- Die angeforderte Testaktivität innerhalb des vereinbarten Umfangs liegt.

Setzen Sie absichtlich verwundbare WordPress-Installationen nicht dem öffentlichen Internet aus. Verwenden Sie Einmal-Anmeldeinformationen, synthetische Daten, isolierte Netzwerke und saubere Snapshots. Zerstören oder setzen Sie das Labor nach dem Test zurück.

Der sicherste Nachweis einer Verwundbarkeit ist die minimale Evidenz, die erforderlich ist, um das Problem zu demonstrieren:```text
Affected version
        +
Route-confusion behavior
        +
Repeatable constant-condition SQL timing oracle

Diebstahl von Anmeldedaten, Persistenz, Webshell-Installation und Befehlsausführung sind nicht erforderlich, um zu bestätigen, dass die Sicherheitslücke existiert.

6.8.x	CVE-2026-60137 nur: 6.8.0–6.8.5	6.8.6
6.9.x	Beide Probleme: 6.9.0–6.9.4	6.9.5
7.0.x	Beide Probleme: 7.0.0–7.0.1	7.0.2
7.1 Vorabversion	Beta 1 betroffen	Beta 2
Älter als 6.8	Nicht von diesen beiden CVEs betroffen	N/A

`CONFIRMED_VULNERABLE_BEHAVIOR`	Runtime Route-Confusion-Verhalten wurde beobachtet
`CONFIRMED_AFFECTED_VERSION`	Lokale Quellversion befindet sich in einem betroffenen Bereich
`LIKELY_VULNERABLE`	Remote-Versionshinweise deuten auf eine betroffene Version hin
`VULNERABLE_SQLI_ONLY`	Version ist von CVE-2026-60137 betroffen, liegt aber außerhalb des vollständigen Route-Confusion-Bereichs
`AFFECTED_VERSION_BUT_BEHAVIOR_NOT_OBSERVED`	Betroffene Version erkannt, aber sicheres Laufzeitverhalten wurde nicht beobachtet
`PATCHED_VERSION`	Version erfüllt die veröffentlichte Korrekturgrenze
`NOT_AFFECTED`	Version liegt außerhalb des betroffenen Zweigs
`POTENTIALLY_EXPOSED_VERSION_UNKNOWN`	WordPress und die Batch-Route wurden gefunden, aber die Version ist versteckt
`WORDPRESS_VERSION_UNKNOWN`	WordPress erkannt, ohne zuverlässigen Versionsnachweis
`ERROR`	Das Ziel konnte nicht bewertet werden
`NOT_WORDPRESS_OR_NOT_DETECTED`	Kein zuverlässiger WordPress-Nachweis

`0`	Kein richtlinienauslösendes Ergebnis oder `--fail-on never`
`2`	Verwundbares oder betroffenes Ergebnis unter der Standardrichtlinie
`3`	Unbekanntes oder nicht eindeutiges Ergebnis, wenn `--fail-on unknown` ausgewählt ist
`1`	Argument-, Eingabe- oder Befehl-unvollständig-Fehler

Beliebteste

WP2Shell-CVE-2026-63030-POC