AI Engine plugin for WordPress, unauthenticated sensitive information exposure to privilege escalation (AI Engine MCP Token Leak)

Overview

AI Engine is a widely deployed WordPress plugin (active on more than 100,000 sites) that adds chatbots, content generation, and a Model Context Protocol (MCP) integration. CVE-2025-11749 is a critical sensitive-information-exposure flaw (CWE-200) in all versions up to and including 3.1.3. When the plugin's optional 'No-Auth URL' feature is enabled for MCP, the /mcp/v1/ REST API endpoint discloses the MCP bearer token to unauthenticated callers. Because that token authorizes privileged MCP operations, leaking it collapses into a full authentication bypass and privilege escalation. The issue was reported through the Wordfence Bug Bounty Program by Emiliano Versini and fixed by the developer in version 3.1.4. NVD assigns the maximum CVSS 3.1 base score of 9.8.

Technical Details

The AI Engine MCP module exposes a REST route under /mcp/v1/. The 'No-Auth URL' option is intended to let MCP clients connect without a separate login by embedding authentication into the URL path. However, in vulnerable builds the endpoint returns the server's bearer token in its response to unauthenticated requests, rather than keeping the secret server-side. An attacker who can reach the WordPress REST API over the network simply queries the exposed endpoint, reads the bearer token from the response, and then replays it as a valid credential. The NVD primary vector is network-accessible (AV:N), low-complexity (AC:L), no privileges required (PR:N), and no user interaction (UI:N), with high confidentiality, integrity, and availability impact (C:H/I:H/A:H). Once authenticated as a privileged MCP principal, the attacker can invoke MCP actions that read and modify site data, ultimately reaching administrative-equivalent control. The fix in 3.1.4 stops the endpoint from returning the token to unauthenticated requests.

Impact

• Unauthenticated, remote disclosure of the AI Engine MCP bearer token via the /mcp/v1/ REST endpoint when 'No-Auth URL' is enabled.
• Reuse of the leaked token to obtain a valid, privileged session (authentication bypass).
• Privilege escalation to administrative-level control of the WordPress site through MCP actions.
• Potential for full site compromise, including content modification, data theft, and persistence (new admin users, malicious plugins/themes).
• High impact to confidentiality, integrity, and availability of the affected WordPress installation.

Mitigation

1. Update the AI Engine plugin to version 3.1.4 or later via the WordPress admin dashboard (Plugins > Updates) or by downloading the current release from the WordPress.org repository.
2. If immediate patching is not possible, disable the 'No-Auth URL' feature for the MCP module to remove the token-exposure path.
3. After updating, rotate the AI Engine MCP bearer token (and any AI provider API keys configured in the plugin) in case the previous token was already exposed.
4. Audit WordPress user accounts, plugins, and themes for unauthorized changes, and remove any unexpected administrator accounts.
5. Confirm the new version is active and verify that an unauthenticated request to /mcp/v1/ no longer returns the bearer token.

Detection

Start with version verification: any AI Engine installation at or below 3.1.3 with the MCP 'No-Auth URL' feature enabled is exposed. Confirm the installed version under Plugins in wp-admin or by reading the plugin header, and check the plugin's MCP settings to see whether the no-auth option is active.

For active-probing detection, examine web server and WordPress access logs for unauthenticated GET or POST requests to paths containing /mcp/v1/ or wp-json/mcp/v1/. Repeated requests to that endpoint from unfamiliar IP addresses, especially from automated scanners or hosting/VPN ranges, are a strong signal that an attacker is harvesting the token. Because the leak is delivered in a normal HTTP response, the request itself looks benign; pair endpoint hits with what follows.

The more decisive indicators come after token capture. Look for privileged REST API or admin-ajax activity, MCP action invocations, or content changes that are not tied to a legitimate interactive admin login in the same session window. Watch for the creation of new administrator accounts, installation or modification of plugins and themes, edits to active theme files, and unexpected scheduled tasks (WP-Cron entries). Sudden outbound requests to AI provider APIs or unfamiliar hosts can indicate the attacker is abusing the captured credentials.

If a Web Application Firewall is present, enable virtual patching or rules that block unauthenticated access to the MCP endpoint and review historical WAF logs for prior hits. On the database side, audit the wp_users and wp_usermeta tables for accounts with administrator capabilities created during the exposure window, and review the wp_options table for unexpected changes. Because this plugin is popular and the flaw is trivially exploitable once the feature is enabled, treat any confirmed token exposure as a potential full compromise: rotate all secrets, force password resets for privileged users, and restore from a known-good backup if unauthorized administrative changes are found. After remediation, verify the fix by confirming the endpoint no longer discloses the token to anonymous callers.