POCBIT
Log inSign up

Telegram — New PoC releases & critical CVE alerts

You can join our Telegram channel to get instant updates on new PoC releases and critical CVE alerts.

Join @pocbit
← Blog

WordPress SiteSkite RCE (CVE-2026-96349): API Keys as Admin Tokens and MCP eval()

Admin · October 1, 2026 · 5 views

Why SiteSkite is a CVSS 10.0 WordPress incident, not “just another plugin”

SiteSkite is a large WebOps plugin: backups, portal integration, and on-site AI MCP “abilities” that can run eval() on supplied PHP and write arbitrary files. CVE-2026-96349 (Patchstack / CVE Program, CVSS 10.0 Critical, CWE-94) chains two design mistakes in ≤ 2.1.8:

  1. The long-lived siteskite_api_key doubles as an unauthenticated admin login bearer via ?token= on /siteskite-autologin (and front-end token handling).
  2. With that secret, attackers call REST or admin-ajax.php MCP endpoints and run siteskite_execute_php (or drop shells via siteskite_write_file).

Vendor fix: ≥ 2.2.0 (September 2026)—raw API keys no longer mint WordPress admin sessions; portal-issued signed autologin links replace the legacy path.

Mechanism and authorized lab tooling: CVE-2026-96349 on pocbit.org. Repository: murrez/CVE-2026-96349.

Attack chain in plain language

From a defender’s perspective the chain has three beats:

| Step | Attacker action | Why it works (≤ 2.1.8) | |------|-----------------|-------------------------| | 1 | Obtain siteskite_api_key | Keys leak via portal “Login as” URLs, backups, logs, referrers, insiders, or paired intel lists—not always “guessable,” but Patchstack classifies the issue as unauthenticated RCE because no WordPress password is required once the bearer is known | | 2 | Optional session proof | /?token=KEY or /siteskite-autologin?token=KEY → wp_set_auth_cookie() for the first administrator (some 2FA plugins bypassed) | | 3 | Code execution | POST /wp-json/siteskite/v1/abilities/execute with header X-SiteSkite-Key: KEY → siteskite_execute_php or file write |

Advanced MCP tools default on in many 2.1.8 installs (DEFAULT_ADVANCED = '1'), so linked sites expose dangerous abilities whenever the key is valid.

Defender checklist

| # | Action | Detail | |---|--------|--------| | 1 | Inventory SiteSkite version | readme.txt stable tag under /wp-content/plugins/siteskite/ | | 2 | Upgrade to ≥ 2.2.0 immediately | Compare AutoLoginController behavior—legacy key equality must be gone | | 3 | Rotate the SiteSkite API key after upgrade | Old key was a login bearer | | 4 | Disable unused MCP / advanced abilities | Reduce eval/write surface if AI editing is not required | | 5 | Block or rate-limit /siteskite-autologin externally | Temporary compensating control during rollout | | 6 | Audit logs for ?token=, X-SiteSkite-Key, abilities/execute | Correlate with new admin sessions | | 7 | Patchstack WAF users | Enable vendor mitigation rule until patched |

Cross-read: WordPress plugin vulnerabilities defender guide, WordPress security checklist (2026), RCE vs local privilege escalation.

Detection hints (your assets only)

Passive discovery (FOFA/Shodan-style) for your estate:

body="/wp-content/plugins/siteskite/"
header="siteskite" && body="wp-content/plugins"

Version fingerprint: readme.txt stable tag ≤ 2.1.8; legacy autologin endpoint behavior on missing token.

Exploit tooling in the wild expects a known API key—check mode does not brute-force keys. Your threat model must include secret hygiene for any third-party plugin that stores long-lived bearer tokens in wp_options.

Patch validation in a lab

Authorized teams should:

  1. Stand up WordPress with SiteSkite 2.1.8 (or use the public PoC --lab self-test).
  2. Run check mode against a clone URL; confirm affected fingerprint.
  3. Upgrade to 2.2.0+; confirm raw ?token=KEY no longer establishes admin.
  4. Retest abilities endpoints with the rotated key only under expected auth.

See safe PoC lab setup and step-by-step CVE PoC testing.

FAQ

We never shared our SiteSkite key—is risk zero?

No. Keys appear in portal links, support tickets, database dumps, and compromised admin workstations. Treat rotation after 2.2.0 as mandatory.

Is this “authenticated” RCE?

CVE text emphasizes no WordPress credentials—the plugin’s API key is the bearer. Operationally, classify it as secret-dependent unauthenticated takeover plus eval primitives.

Can WAF replace the vendor patch?

Rules on autologin and abilities paths help during maintenance windows. 2.2.0 removes the autologin key equivalence that makes session acquisition trivial once the secret leaks.

Bottom line

CVE-2026-96349 is a reminder that AI/WebOps plugins must not reuse integration secrets as login tokens, and that eval() abilities belong behind strict auth and off-by-default policy. Upgrade SiteSkite, rotate keys, audit MCP settings—and use public PoCs only on systems you own.