CVE-2025-11749 Exposes a Privileged MCP Credential
AI Engine provides a Model Context Protocol server that allows AI clients to call WordPress-management tools. CVE-2025-11749 affects every release through 3.1.3 and carries a critical CVSS score of 9.8. The vulnerable configuration is conditional: MCP's `No-Auth URL` option must be enabled and a bearer token must be set. Under those conditions, an unauthenticated visitor can obtain the token from the public REST API route index. The disclosure alone does not create a WordPress account, but it gives the attacker the credential needed to enter the plugin's privileged MCP path and attempt high-impact actions without supplying WordPress login credentials. AI Engine has more than 100,000 active installations, although only sites using the affected MCP configuration expose this attack path.
The Secret Is Embedded in Publicly Listed Route Names
Version 3.1.3 reads `mcp_bearer_token` and, when `mcp_noauth_url` is enabled, concatenates the token into REST paths for SSE and message traffic. The resulting paths follow `/mcp/v1/{bearer-token}/sse` and `/mcp/v1/{bearer-token}/messages`. A token in a URL can serve as a credential only while that URL remains secret, but the vulnerable route registrations use WordPress's default index behavior. REST API discovery therefore publishes the complete registered path, including the bearer token, to unauthenticated visitors. This is sensitive-information exposure rather than a token-guessing attack: WordPress reveals the value through metadata generated from the plugin's own route definitions.
AI Engine Converts the Token Into Administrator Context
After recovering the token, an attacker can use the token-bearing routes or send it in an authorization header. `auth_via_bearer_token()` compares the supplied value with the configured secret and calls `wp_set_current_user()` with an administrator selected by the plugin. The No-Auth route takes a similar path: `handle_noauth_access()` checks that the route contains the token and then sets the current user to that administrator. From there, an MCP client can enumerate tools and submit a `tools/call` request. One registered tool is `wp_create_user`; its role is derived from the caller's arguments and passed to `wp_insert_user()`. Requesting the `administrator` role can therefore create an attacker-controlled privileged account, after which the attacker may establish an ordinary WordPress session and take administrative actions.
Version 3.1.4 Hides Token-Bearing Routes From REST Discovery
AI Engine 3.1.4 adds `'show_in_index' => false` to each token-bearing SSE and message route. WordPress can still route a client that already knows the complete No-Auth URL, preserving the feature's intended behavior, but it no longer advertises that secret URL in public REST API discovery data. The plugin's changelog describes the release as REST API security hardening, and the source diff confirms the index-visibility change. Administrators assessing exposure should treat any token published by an affected release as disclosed: install a corrected release, replace the MCP bearer token, disable No-Auth URL when it is unnecessary, and review MCP, user-account, and authentication activity for unexpected access.
BitFire RASP Blocks Unauthorized Administrator Creation
BitFire PRO RASP protects the database outcome where this privilege-escalation chain must succeed. Its login and authentication controls track whether the request's identity was established through valid WordPress login credentials. A custom API token invented by a plugin does not satisfy that requirement, even when vulnerable plugin code calls `wp_set_current_user()` and proceeds as though an administrator were authenticated. When the compromised MCP path reaches `wp_insert_user()` with the `administrator` role, RASP denies the unauthorized administrator-account creation. This control does not claim to conceal the leaked token or authorize AI Engine correctly; it supplies a separate final boundary against the specific account-creation outcome described by the CVE.
Conclusion: Privileged Operations Need Independent Access Controls
CVE-2025-11749 shows why application-managed bearer tokens cannot be the only boundary around powerful WordPress operations. A route-discovery mistake exposed the token, and the plugin then translated that token into administrator context capable of invoking user-management tools. Site administrators need a security solution with built-in access controls and zero-day protection for sensitive operations such as administrator creation. BitFire PRO RASP enforces that boundary from authentication through the database: its policy is already active before a CVE-specific signature exists, requires valid login credentials for administrator-account creation, and refuses to accept a custom plugin API token as a substitute.
