The Royal MCP WordPress plugin before 1

Royal MCP is a WordPress plugin that exposes the site to LLM agents (Claude, ChatGPT, Gemini) via the Model Context Protocol, publishing up to 126 tools covering posts, users, media, options, WooCommerce, Elementor, and integration surfaces. In versions prior to 1.4.26, the plugin verified the OAuth 2.1 bearer token / API key at the request boundary but then failed to run a per-tool current_user_can() check on the majority of those tools. That means a token issued to a *subscriber*, *customer*, or any low-privileged role could invoke tools gated conceptually behind edit_others_posts, manage_categories, list_users, manage_woocommerce, or even manage_options — the last of which is effective site takeover.

There is no vendor CVSS. Looking at reality: this is a classic broken access control (CWE-862 / CWE-285) bug in a plugin that ships a *huge* exposed capability surface. The vendor's fixed release adds per-tool map_meta_cap object-level checks across content, user, term, comment, and integration tools — the diff confirms the pre-1.4.26 state was effectively unauthorized privilege escalation for anyone holding a token. On sites with open registration or WooCommerce customer accounts, the *authentication* bar is essentially the ground floor.

Why this verdict

• Trivial exploitation once authenticated: the fix diff is a one-line-per-tool current_user_can() addition, meaning pre-patch the code path is a direct dispatch. No memory corruption, no race, no oracle — just call the tool.
• Authentication bar is often ground-floor: WooCommerce customer accounts and open subscriber registration are common. PR:L is the honest privilege rating and often collapses to PR:N in practice.
• Blast radius = full site compromise: the exposed tool set includes user creation and options manipulation, which is a direct path to administrator, which is a direct path to RCE via theme/plugin editor.
• Role multiplier — line-of-business WordPress site (typical role): chain succeeds; blast radius = single site takeover, potential PII/PCI exposure if WooCommerce is present. Not fleet-scale, not identity-plane.
• Role multiplier — WordPress as identity or SSO backend (rare role): chain succeeds; if the site brokers logins to other apps, blast radius extends to those downstream apps. Still not canonical high-value-role territory for this plugin.
• Downward pressure — small install base: Royal MCP is a young plugin (published 2026), estimated low-thousands of installs. This caps aggregate risk vs. a vuln in a plugin with 1M+ installs.
• Downward pressure — not KEV, no PoC yet: as of 2026-07-01 there is no observed exploitation and no weaponized PoC in public repos.

Why not higher?

Not CRITICAL because the affected component is not a canonical identity/hypervisor/backup/PKI/edge role — blast radius stops at the single WordPress instance. Install base is also modest (thousands, not millions), so aggregate fleet exposure is bounded. No KEV, no in-the-wild activity, no supply-chain pivot.

Why not lower?

Not MEDIUM because the exploitation cost after any authentication is essentially zero (single HTTP call to an MCP tool endpoint), and the success outcome is full site takeover — that combination is textbook HIGH. WooCommerce and membership sites collapse the PR:L prerequisite to near-PR:N, and the public fix diff is a roadmap for exploit developers.

1. Upgrade Royal MCP to 1.4.26 or later — This is the actual fix — per-tool capability checks land here. Deploy within 30 days per the noisgate HIGH mitigation SLA; ideally within the week given the public fix diff exposes the missing checks.
2. Disable the plugin if not actively used — If your site installed Royal MCP experimentally and is not routing agent traffic through it, deactivate immediately. Zero operational cost, eliminates the attack surface entirely.
3. Revoke all existing OAuth tokens and API keys — Assume any pre-patch token may have been used to plant persistence. Rotate tokens after upgrade and audit issued clients for anything you do not recognize. Do this at the same time as the plugin upgrade.
4. Close open registration temporarily — If the site accepts self-service subscriber or customer registration, disable that (Settings → General → Membership) until 1.4.26 is deployed. This removes the free authentication path attackers would otherwise use.
5. Front the MCP endpoint with a WAF rule blocking /wp-json/royal-mcp/v1/mcp — A Wordfence / Cloudflare / Sucuri rule blocking that path (or restricting it by source IP) removes the attack surface until you can patch. Deploy within 72 hours as an interim control.
6. Audit the royal_mcp activity log for anomalous tool invocations — Look for wp_create_user, wp_update_option, wp_update_user, and any settings-touching tool called by non-admin actors between plugin installation date and patch deployment. Any such entry is presumptive compromise.

Run this on the WordPress host (or any auditor workstation with wp-cli and SSH to the host). Invoke as ./check_royal_mcp.sh /var/www/html where the argument is the WordPress installation root. Requires read access to wp-content/plugins/royal-mcp/ — no elevated privileges needed beyond that.

#!/usr/bin/env bash
# noisgate — CVE-2026-10750 Royal MCP capability-check bypass
# Usage: ./check_royal_mcp.sh <wordpress-root>
# Exit 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -u
WP_ROOT="${1:-/var/www/html}"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/royal-mcp"
FIXED_VER="1.4.26"

if [[ ! -d "$PLUGIN_DIR" ]]; then
  echo "UNKNOWN: royal-mcp plugin directory not found under $WP_ROOT"
  exit 2
fi

HEADER_FILE="$PLUGIN_DIR/royal-mcp.php"
if [[ ! -f "$HEADER_FILE" ]]; then
  HEADER_FILE=$(grep -lE '^\s*\*\s*Plugin Name:\s*Royal MCP' "$PLUGIN_DIR"/*.php 2>/dev/null | head -n1)
fi
if [[ -z "${HEADER_FILE:-}" || ! -f "$HEADER_FILE" ]]; then
  echo "UNKNOWN: could not locate plugin header PHP file"
  exit 2
fi

INSTALLED=$(grep -iE '^\s*\*\s*Version:' "$HEADER_FILE" | head -n1 | awk -F: '{print $2}' | tr -d ' \t\r')
if [[ -z "$INSTALLED" ]]; then
  echo "UNKNOWN: could not parse Version from $HEADER_FILE"
  exit 2
fi

# semver compare: returns 0 if $1 >= $2
ver_ge() {
  [[ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" == "$2" ]]
}

if ver_ge "$INSTALLED" "$FIXED_VER"; then
  echo "PATCHED: Royal MCP $INSTALLED (>= $FIXED_VER)"
  exit 0
else
  echo "VULNERABLE: Royal MCP $INSTALLED (< $FIXED_VER) — CVE-2026-10750"
  echo "  Action: upgrade to $FIXED_VER, revoke all OAuth tokens, audit royal_mcp activity log"
  exit 1
fi

Sources

1. Royal MCP plugin on WordPress.org
2. royalplugins/royal-mcp on GitHub
3. Royal MCP official product page
4. Royal MCP documentation
5. Royal MCP troubleshooting thread (WordPress.org support)
6. Model Context Protocol specification
7. CWE-862: Missing Authorization
8. Wordfence Intelligence — WordPress plugin vulnerabilities