AI Engine MCP Token Leak: 100K WordPress Sites at Risk (CVE-2025-11749)

The AI Engine plugin for WordPress shipped a configuration that printed its Model Context Protocol bearer token directly into the public /wp-json/ index. Any unauthenticated visitor could fetch that index, copy the token, and use it to call privileged MCP commands like wp_update_user. One HTTP request to read the index. One more to make yourself an administrator. Hundreds of thousands of sites had this turned on by April 2026.

The flaw is tracked as CVE-2025-11749, with a CVSS score of 9.8. It affected every version up to and including 3.1.3 of AI Engine, and was fixed in 3.1.4. If you run AI Engine and you ever enabled the "No-Auth URL" feature, you need to update right now and rotate every credential the plugin had access to.

What AI Engine Is and Why MCP Matters

AI Engine is the most widely installed AI-management plugin in the WordPress ecosystem. It connects WordPress sites to large language models from OpenAI, Anthropic, and other providers, exposes a chatbot widget, and ships a Model Context Protocol server so external AI agents (Claude, ChatGPT, Cursor, custom agents) can read and write to the WordPress site.

MCP is the protocol that lets an AI agent call structured "tools" on a remote server. In AI Engine's case those tools include wp_create_post, wp_update_user, wp_install_plugin, and similar operations. The protocol uses bearer-token authentication: the agent presents a long-lived secret in the Authorization header, and the server treats every request from that token as authorized.

That model works as long as the bearer token stays secret. The whole security boundary is the token. Once it leaks, an attacker has the same powers as a fully connected AI agent: read posts, edit users, install plugins. There's no second factor.

The Specific Flaw: A Missing show_in_index

WordPress REST routes are registered with register_rest_route(). The fourth argument is an array of options, one of which is show_in_index. When set to true (the default), that route appears in the public /wp-json/ index alongside its arguments and metadata. When set to false, the route is still callable but won't be advertised.

AI Engine's "No-Auth URL" mode generated a per-site MCP URL that included the bearer token in the path itself, like /wp-json/mcp/v1/<token>/.... The intent was convenience: drop the URL into your AI client, no separate auth header needed. But the route was registered with show_in_index left at the default. So the full URL, token included, was published in the JSON returned by https://example.com/wp-json/.

That JSON is fetched constantly. Search engines index it. Uptime monitors hit it. Security scanners crawl it. The token sat there in plain text, inside a public endpoint that needs to stay public for WordPress itself to work.

Once an attacker had the token, they could call any MCP tool the plugin exposed. The shortest path to full takeover is a single wp_update_user call elevating an existing low-privilege account to administrator, or a wp_create_user followed by role assignment. From there: install a malicious plugin, drop a PHP backdoor, exfiltrate the database, pivot.

Why This Plugin Specifically

CVE-2025-11749 isn't the first serious bug in AI Engine. The Wordfence and WPScan databases list 22 disclosed vulnerabilities for the plugin, and the recent run is heavy on the same MCP surface:

The repeated SSRF and file-upload findings tell you the plugin is large, the MCP surface is large, and the threat model has been catching up to the implementation in real time. That's not unique to AI Engine. It's the shape of every plugin that bolts a powerful new protocol onto WordPress quickly.

What Makes "AI on WordPress" Particularly Risky

WordPress was designed for human administrators. Roles, capabilities, nonces, and the REST API permission callbacks all assume a person is on the other end. AI agents change three things at once:

Long-lived tokens replace session cookies. WordPress's nonce system protects against CSRF and token replay by tying each token to a user, an action, and a 24-hour window. MCP bearer tokens have none of those bindings. They authenticate any request that presents them, from anywhere, until the admin rotates them. Most admins never rotate them.

One credential controls every tool. A traditional WordPress integration has scoped permissions: a backup plugin gets read-only access to the database, a deployment tool gets file-system writes. An MCP server typically exposes the union of every tool the plugin authors decided to ship. The bearer token grants all of them.

The audit trail is sparse. WordPress logs administrator actions with the user ID. MCP tool calls run as a synthetic "agent" user. If the token leaks and an attacker creates accounts, the action log just shows "agent created user X" — it doesn't tell you whether the call came from your real Claude session or a stranger on the internet.

The same pattern caused the supply chain backdoor in EssentialPlugin: a powerful, under-monitored channel into WordPress was sold without scrutiny, and the new owner used it to push malicious code through a trusted update.

How to Tell If Your Site Is Affected

Three checks. Do them now.

1. Confirm the plugin and version.

In wp-admin → Plugins, check whether "AI Engine" is installed and what version. If you're on 3.1.3 or older, you're vulnerable. Update to 3.1.4 or higher (current stable is well past that point). If you can't update right away, deactivate the plugin until you can.

2. Check whether No-Auth URL was ever enabled.

The bug only fires if "No-Auth URL" was turned on at some point. In AI Engine settings, go to the MCP section and look for the "No-Auth URL" toggle. If it's currently on, switch it off. If it's currently off but you don't remember whether it was ever on, assume yes.

3. Audit the user table.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Look for accounts you don't recognize, especially any registered after November 2025. Cross-reference with the signs your WordPress site has been hacked checklist for additional indicators.

If you find an unfamiliar admin, treat the site as compromised and follow the WordPress malware removal guide. Rotate every secret: WordPress salts, database password, AI Engine API keys, OpenAI/Anthropic provider keys, any MCP tokens.

Defense in Depth for AI-Connected WordPress

Patching this one CVE is necessary, not sufficient. If you're going to keep an AI integration on WordPress, harden the surface:

• Treat the MCP token as a production secret. Store it in a password manager. Don't commit it to repos. Rotate quarterly even when there's no incident.
• Disable any "no-auth URL" or "magic link" feature that puts a credential in a URL path. URLs leak through referrer headers, server logs, browser history, and JSON indexes (as this CVE proved).
• Restrict the MCP endpoint by IP at the web-server level. Most agents call from a small, known set of addresses. An nginx allow/deny block in front of /wp-json/mcp/ raises the bar substantially.
• Subscribe to the plugin's security advisories. AI Engine ships fast. The 22-CVE history means you'll see another disclosure within months.
• Run a WordPress security scan weekly. WP Vanguard's free scanner picks up unpatched plugins, exposed admin accounts, and suspicious files. See our security checklist for the wider hardening pass.

The honest summary for plugin authors integrating AI into WordPress: the threat model isn't "what could this AI do if it goes rogue." It's "what could a stranger on the internet do if they steal the credential that lets the AI do anything." Build accordingly.

References

• Wordfence advisory: 100,000 WordPress Sites Affected by Privilege Escalation Vulnerability in AI Engine
• ZeroPath analysis of CVE-2025-11749
• WPScan AI Engine vulnerability database
• Cyberpress: Privilege Escalation in AI Engine WordPress Plugin
• eSecurity Planet coverage of the disclosure