CVE-2026-10750 · Royal MCP WordPress Plugin Missing Authorization on MCP Tools After…

01 · The Real Story

Leaving the VIP section unguarded after the bouncer checks your ticket but forgets to check the guest list

CVE-2026-10750 is a missing-authorization flaw (CWE-862) in the Royal MCP WordPress plugin, which bridges AI agents (Claude, ChatGPT, Gemini, etc.) to WordPress sites via the Model Context Protocol. Versions prior to 1.4.26 fail to enforce WordPress capability checks on the majority of the plugin's 200+ MCP tools once a user has successfully authenticated with an MCP token. A Subscriber-level user who obtains a valid MCP API key or OAuth token can read private/draft posts, enumerate all users and their roles, and create, modify, or delete content belonging to any other user. The fix in 1.4.26 adds per-tool current_user_can() checks and converts status filters to positive allowlists.

The vendor rates this HIGH 8.1, and the CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) looks alarming in isolation. But reality sharply narrows the risk. Royal MCP has roughly 10,000 active installs — a rounding error against the 800M+ WordPress ecosystem. The MCP integration must be explicitly enabled by an admin (it is *not* on by default), and the attacker needs a valid MCP token, not just a WordPress login. Impact caps out at content-level operations: no RCE, no database shell, no file-system writes, no admin panel takeover. With an EPSS of 0.43%, no KEV listing, no known in-the-wild exploitation, and no public PoC, the vendor's 8.1 overstates the field-level urgency for most defenders.

"Niche WordPress AI plugin with broken authz — narrow blast radius, low real-world exposure"

02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify a WordPress site running Royal MCP < 1.4.26

The attacker fingerprints a target WordPress site by checking for the presence of the Royal MCP plugin via its publicly exposed /wp-json/royal-mcp/ REST routes or the .well-known/mcp.json endpoint. Plugin version can often be inferred from the readme.txt or changelog files if directory listing is enabled.

Conditions required:

Target site runs WordPress with Royal MCP < 1.4.26 installed and MCP integration enabled

Where this breaks in practice:

Only ~10,000 sites worldwide have this plugin installed
MCP integration must be explicitly enabled by a site administrator — it is not active by default

Detection/coverage: WPScan, Nuclei templates for WordPress plugin enumeration; no known CVE-specific Nuclei template as of October 2026

STEP 02

Obtain a low-privilege WordPress account

The attacker creates or compromises a Subscriber-level account on the target site. Many WordPress sites have open user registration enabled (default role: Subscriber). Alternatively, the attacker reuses credentials from a breach dump.

Conditions required:

Site has open registration OR attacker obtains valid Subscriber credentials

Where this breaks in practice:

Sites without open registration require credential theft, phishing, or another vuln to get a valid account
Security-conscious sites use MFA plugins (e.g., Wordfence, WP 2FA) that block credential-only attacks

Detection/coverage: WordPress login audit logs, Wordfence/Sucuri brute-force detection, anomalous user registration alerts

STEP 03

Acquire a valid MCP token

Using the authenticated WordPress session, the attacker initiates an OAuth 2.1 PKCE flow against the Royal MCP token endpoint or obtains an API key if one has been issued to their role. The vulnerability specifically manifests *after* successful token authentication — the token validates the identity but the subsequent tool calls skip capability enforcement.

Conditions required:

The MCP endpoint must accept token requests from Subscriber-level users
OAuth flow or API key issuance must not be restricted to Administrators

Where this breaks in practice:

Well-configured deployments restrict MCP API key generation to Administrators only
If the OAuth client registration is locked down, Subscribers cannot initiate the flow

Detection/coverage: Royal MCP activity log records every authenticated MCP request with timestamp, client IP, tool name, and parameters

STEP 04

Invoke privileged MCP tools without capability checks

With a valid MCP token, the attacker calls tools like wp_get_posts with post_status=private, wp_get_users to enumerate all accounts and roles, or wp_update_post / wp_delete_post to modify or destroy content owned by Administrators or Editors. None of these calls validate the caller's WordPress role against the required capability (e.g., read_private_posts, list_users, edit_others_posts).

Conditions required:

Valid MCP token from Step 3
Target site has content worth exfiltrating or modifying

Where this breaks in practice:

Impact is bounded to content operations — no RCE, no database queries, no filesystem writes
Plugin explicitly blocks writing to themes, includes, admin directories, and refuses raw SQL

Detection/coverage: Royal MCP activity log shows all tool invocations; anomalous volume or tool names from a Subscriber IP are detectable post-incident

STEP 05

Exfiltrate data or deface content

The attacker reads private posts (potentially containing PII, financial data in WooCommerce order notes, or unpublished embargoed content), exports the user roster for further targeting, or modifies/deletes published content to deface the site. The 72-hour undo feature in Royal MCP Pro may limit destructive impact but does not prevent data exfiltration.

Conditions required:

Successful tool invocations from Step 4

Where this breaks in practice:

Data value depends entirely on what the site stores — most WordPress sites are public-facing content with minimal sensitive private content
WooCommerce order data exposure is the worst realistic case, and even that requires WooCommerce + Royal MCP WooCommerce integration both enabled

Detection/coverage: Content integrity monitoring (e.g., Sucuri SiteCheck), WooCommerce order audit logs, WordPress revision history

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Update Royal MCP to 1.4.26 or later immediately — The definitive fix. Version 1.4.26 adds per-tool capability checks. Current stable is 1.5.6. As a MEDIUM verdict, the noisgate remediation SLA gives you 365 days, but since the fix is a one-click WordPress plugin update with no breaking changes, there is no reason to delay. Apply within your next maintenance window.

MEDIUM 5.5→LOW 2.5

SEVERITY REDUCED

Restrict MCP API key issuance to Administrator role only — Review Royal MCP settings and ensure API keys are only generated for and distributed to Administrator-level users. If OAuth is enabled, restrict the client registration endpoint so Subscribers cannot initiate token flows. This breaks Step 3 of the attack path by preventing low-privilege users from obtaining a valid MCP token. No mitigation SLA applies at MEDIUM, but this is a 5-minute configuration change.

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Disable MCP integration on sites where it is not actively used — If Royal MCP was installed for evaluation but MCP integration is not in production use, disable or uninstall the plugin entirely. This eliminates the entire attack surface. Audit your WordPress fleet for Royal MCP installs using WP-CLI: wp plugin list --field=name | grep royal-mcp.

MEDIUM 5.5→LOW 3.5

SEVERITY REDUCED

Disable open user registration on WordPress sites running Royal MCP — If the site does not require public Subscriber registration, disable it under Settings > General > Membership. This raises the bar for Step 2 by requiring the attacker to compromise an existing account rather than self-registering. This does not fully mitigate the vuln (compromised accounts still work) but adds meaningful friction.

What doesn't work

WAF rules — The MCP tool calls use standard WordPress REST API routes with valid authentication tokens. A WAF cannot distinguish legitimate admin MCP usage from unauthorized Subscriber MCP usage because the authorization failure is application-layer logic, not a malformed request.
WordPress file integrity monitoring — Tools like Sucuri SiteCheck detect file modifications, but this vuln is about data-plane abuse (reading/writing posts via API), not file-system tampering. No files are modified during exploitation.
Rate limiting alone — Royal MCP already rate-limits at 60 req/min per IP. The attacker only needs a handful of API calls to exfiltrate private content or enumerate users, well within normal rate limits.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No evidence. Not listed on CISA KEV. No reports from Wordfence, Sucuri, or Patchstack threat feeds of active exploitation campaigns targeting this CVE as of October 2026.
Proof of Concept	No public PoC found. Checked pocindex.io, GitHub repos (`CVE-2026-10750`), ExploitDB, and Nuclei templates — none indexed. The exploit is trivially scriptable (authenticated REST API calls) but no weaponized tooling has been published.
EPSS Score	0.0043 (0.43%) — bottom quartile. FIRST EPSS model gives this a <1% probability of exploitation in the next 30 days, consistent with the narrow install base and required preconditions.
CISA KEV Status	Not listed. No binding operational directive applies.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` — Network-accessible, low complexity, low privileges required, no user interaction. Scope unchanged. High confidentiality and integrity impact, no availability impact. The PR:L rating is accurate (Subscriber account + MCP token).
Affected Versions	Royal MCP < 1.4.26 (all prior versions since MCP tool registration was introduced). Current stable is 1.5.6.
Fixed Version	1.4.26 — adds per-tool `current_user_can()` checks and converts post-status filters to positive allowlists. No distro backports apply (WordPress plugin, not OS-packaged).
Install Base / Exposure	~10,000 active WordPress installs per wordpress.org. No meaningful Shodan/Censys/GreyNoise signature — the MCP endpoint is a standard WordPress REST route, not a distinct service port. Exposure is a subset of the ~10K installs where MCP is admin-enabled.
Disclosure Date	2026-07-01 (public disclosure). Researchers reported to vendor prior; fix shipped same day.
Researchers	Alessandro Greco (aka Aleff) and Giovanbattista Ianni, University of Calabria (UNICAL). Coordinated disclosure via WPScan.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Microscopic install base: Royal MCP has ~10,000 active installs across all of WordPress. An attacker targeting this CVE is fishing in a puddle, not an ocean. This alone cuts the reachable population by >99.99% vs. a WordPress core vuln.
MCP-not-default friction: The MCP integration must be explicitly enabled and configured by a site admin. The vulnerable code path is unreachable on installs where MCP is turned off. This further shrinks the exploitable surface to a fraction of the 10K installs.
Token acquisition barrier: Exploitation requires not just a Subscriber WordPress account, but a valid MCP API key or OAuth token. Well-configured deployments restrict token issuance to administrators. The PR:L rating in CVSS undersells this — it is effectively PR:L *plus* a second auth gate.
Content-only blast radius: The impact ceiling is WordPress content operations: reading private posts, enumerating users, modifying/deleting content. There is no path to RCE, database access, filesystem writes, or admin panel takeover. The plugin explicitly blocks theme/core file writes and raw SQL.
Role multiplier: WordPress is a CMS, not infrastructure. It does not serve as an identity provider, hypervisor, CI/CD pipeline, PKI, or domain controller. The high-value role analysis: (a) *Low-value role* — personal blogs, dev sandboxes: exploit yields nothing of value. (b) *Typical role* — corporate marketing sites, small business sites: private content exposure is embarrassing but not domain-takeover. (c) *High-value role* — WooCommerce stores with PII/financial data: this is the worst plausible case, but requires WooCommerce + Royal MCP + WooCommerce MCP integration all enabled, which represents a tiny fraction of 10K installs. Blast radius is single-site, single-tenant. No fleet, domain, or supply-chain escalation path exists. The high-value role floor does NOT apply because the component is not canonically infrastructure software, and no realistic deployment reaches domain/fleet/supply-chain impact.
No exploitation signals: EPSS 0.43%, no KEV listing, no public PoC, no in-the-wild reports from any WordPress threat intelligence feed. Three months post-disclosure with zero uptake.

Why not higher?

The vendor's HIGH 8.1 would be defensible if Royal MCP were a ubiquitous WordPress plugin (like Elementor at 5M+ installs) or if the flaw yielded RCE. Neither is the case. The install base is microscopic, the attack requires chained authentication steps (WP account + MCP token), and the impact is bounded to content-level CRUD on a single site. Upgrading this to HIGH would misallocate patching resources away from vulns with broader real-world reach.

Why not lower?

Despite the narrow exposure, the vuln is trivially exploitable once preconditions are met (no user interaction, no complex chain), the data exposed can include PII in WooCommerce contexts, and the fix is a simple plugin update. Dropping to LOW would understate the risk for the defenders who *do* run Royal MCP on content-sensitive or e-commerce sites. MEDIUM correctly signals 'patch within your normal cycle, no fire drill.'

06 · Verification

Crowdsourced verification payload.

Run this on any host with network access to the target WordPress site(s) and curl installed. No special privileges required. Example: bash check_cve_2026_10750.sh https://example.com. For fleet-wide checks, pipe a list of site URLs.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_10750.sh — Detect Royal MCP < 1.4.26 (CVE-2026-10750)
# Usage: bash check_cve_2026_10750.sh <wordpress_site_url>
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

SITE_URL="${1:?Usage: $0 <wordpress_site_url>}"
SITE_URL="${SITE_URL%/}"

# Try to fetch the plugin's readme.txt which contains Stable tag
README_URL="${SITE_URL}/wp-content/plugins/royal-mcp/readme.txt"
RESPONSE=$(curl -sS -o /tmp/royal_mcp_readme.txt -w "%{http_code}" "$README_URL" 2>/dev/null || true)

if [[ "$RESPONSE" != "200" ]]; then
  echo "UNKNOWN — Royal MCP plugin not detected at ${SITE_URL} (readme.txt returned HTTP ${RESPONSE})."
  echo "The plugin may not be installed, or directory listing is blocked."
  echo "Alternatively, run on the host: wp plugin get royal-mcp --field=version"
  exit 2
fi

# Extract version from Stable tag line
VERSION=$(grep -i '^Stable tag:' /tmp/royal_mcp_readme.txt | head -1 | sed 's/[Ss]table [Tt]ag:[[:space:]]*//' | tr -d '[:space:]')

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN — Could not parse version from readme.txt at ${SITE_URL}."
  exit 2
fi

echo "Detected Royal MCP version: ${VERSION}"

# Version comparison: vulnerable if < 1.4.26
FIXED="1.4.26"

version_lt() {
  [ "$(printf '%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ] && [ "$1" != "$2" ]
}

if version_lt "$VERSION" "$FIXED"; then
  echo "VULNERABLE — Royal MCP ${VERSION} is affected by CVE-2026-10750 (fixed in ${FIXED})."
  exit 0
else
  echo "PATCHED — Royal MCP ${VERSION} is >= ${FIXED}. CVE-2026-10750 does not apply."
  exit 1
fi