CVE-2025-11749

What it actually does

The vulnerability exposes a bearer token through the AI Engine WordPress plugin's unauthenticated `/mcp/v1/` REST API endpoint when the plugin's `No-Auth URL` capability is enabled. Because the token can be retrieved without authentication, an attacker can use it as a valid authorization credential to access plugin/API functionality and perform privileged actions. The described impact includes session takeover-like access and privilege escalation, including creation of a new WordPress administrator account. The CVSS 9.8 rating reflects network-exploitable, unauthenticated exploitation with high confidentiality, integrity, and availability impact.

Why it matters to the business

A public WordPress site running a vulnerable AI Engine plugin configuration may allow an internet-based attacker to obtain administrative-level access without knowing a password. Successful exploitation can lead to website takeover, malicious administrator creation, content modification, malware or skimmer injection, SEO spam, data exposure, service disruption, and use of the compromised site for phishing or further attacks. EPSS is high at approximately 0.75 and the exploit maturity is listed as weaponized, so organizations should treat exposed installations as urgent even though the issue is not currently listed in CISA KEV and is not specifically marked as ransomware-used.

How an attack unfolds

An attacker first identifies a WordPress site using the AI Engine plugin and probes for the exposed MCP REST endpoint, typically under `/wp-json/mcp/v1/` or a related `/mcp/v1/` route. If the site is running AI Engine version 3.1.3 or earlier and `No-Auth URL` is enabled, the endpoint may return sensitive configuration or session material including the bearer token. The attacker extracts the token from the response and replays it in an `Authorization: Bearer` header to access functionality that should require authentication. With that access, the attacker can perform privileged operations, such as creating a new administrator account, modifying site/plugin settings, planting webshells through theme/plugin editors where available, or adding malicious content. Because exploitation requires no prior credentials and can be automated, broad scanning and opportunistic compromise are plausible.

How to fix it

Upgrade the AI Engine WordPress plugin to a vendor-fixed release newer than 3.1.3 as soon as it is available through the official WordPress plugin repository or vendor distribution channel. If no fixed version is available in the local package source, immediately disable `No-Auth URL` functionality and restrict or disable the MCP REST endpoint until the plugin can be updated. Remove or rotate any exposed bearer tokens, invalidate active sessions, and review all WordPress administrator accounts after remediation. Where possible, place compensating controls in front of WordPress such as a WAF rule blocking unauthenticated access to `/mcp/v1/` and `/wp-json/mcp/v1/`, restrict REST API access to trusted sources if operationally feasible, and disable plugin/theme file editing from the WordPress dashboard. Back up the site before applying updates, then update the plugin through normal WordPress administrative workflows, WP-CLI, or managed hosting controls.

How to confirm the fix worked

Confirm the installed AI Engine plugin version is newer than 3.1.3 or otherwise confirmed fixed by the vendor. Verify that `No-Auth URL` is disabled unless explicitly required and protected by compensating controls. From an unauthenticated session, request the MCP route, such as `/wp-json/mcp/v1/`, and confirm it does not disclose bearer tokens or other sensitive authorization material. Validate that unauthenticated requests to MCP functionality return an authorization failure rather than plugin configuration or token values. Review WAF or reverse proxy rules to ensure direct requests to `/mcp/v1/` and `/wp-json/mcp/v1/` are blocked or tightly controlled where the feature is not needed. Finally, confirm token rotation and session invalidation occurred by testing that previously issued bearer tokens no longer authorize API actions.

Typical attack path

1. Scan internet-facing WordPress sites for AI Engine plugin exposure and REST API routes.
2. Request the vulnerable `/mcp/v1/` REST API endpoint, commonly through `/wp-json/mcp/v1/`, without authentication.
3. Check whether `No-Auth URL` behavior is enabled and whether the response leaks a bearer token.
4. Extract the leaked bearer token from the API response.
5. Replay the token in an `Authorization: Bearer` request to access protected plugin or WordPress functionality.
6. Use the gained access to create a new administrator account or otherwise escalate privileges.
7. Persist by adding users, modifying plugins/themes, uploading malicious files, or changing site configuration.
8. Monetize or abuse the compromised site through data theft, malware injection, redirect campaigns, spam, phishing, or service disruption.

How to detect it

To determine whether exploitation already occurred, review web server, CDN, reverse proxy, WAF, and WordPress application logs for unauthenticated access to `/mcp/v1/` or `/wp-json/mcp/v1/`, especially responses with HTTP 200 status codes and unusual user agents, high request rates, or requests from unfamiliar IP addresses. Correlate those requests with subsequent authenticated API calls using bearer authorization, administrator account creation, plugin/theme changes, option changes, file uploads, or edits to PHP files. Review WordPress audit logs, if available, for new administrator users, password resets, role changes, plugin installation, theme editing, and changes to AI Engine configuration. Examine database-independent WordPress artifacts such as `wp-content/uploads/`, `wp-content/plugins/`, and `wp-content/themes/` for recently modified PHP files, suspicious one-line scripts, encoded payloads, or unexpected admin tooling. Check authentication/session logs for new logins from unusual geographies, hosting providers, or IPs shortly after MCP endpoint access. Since the vulnerability exposes a reusable bearer token, also look for repeated `Authorization: Bearer` API requests from sources that did not previously authenticate normally.

• /mcp/v1/
• /wp-json/mcp/v1/
• GET /mcp/v1/
• GET /wp-json/mcp/v1/
• POST /mcp/v1/
• POST /wp-json/mcp/v1/
• Authorization: Bearer
• Bearer Token
• No-Auth URL
• wp-content/plugins/ai-engine/
• wp-content/uploads/*.php
• wp-content/themes/*.php
• wp-content/plugins/*.php
• user role changed to administrator
• new administrator user
• administrator account created

What your security team should do

• Inventory all WordPress sites for the AI Engine plugin and prioritize any installation running version 3.1.3 or earlier.
• Immediately upgrade AI Engine to a vendor-fixed version newer than 3.1.3, or disable the plugin if a fixed version is not yet available.
• Disable `No-Auth URL` and block unauthenticated access to `/mcp/v1/` and `/wp-json/mcp/v1/` unless there is a documented business requirement.
• Rotate exposed bearer tokens, invalidate WordPress sessions, and reset credentials for administrator accounts after patching.
• Hunt for suspicious API requests to MCP endpoints, especially unauthenticated requests followed by administrator account creation or plugin/theme changes.
• Review WordPress users for newly created, unexpected, or recently modified administrator accounts.
• Inspect web roots, uploads directories, plugin directories, and theme directories for recently modified PHP files or webshell-like artifacts.
• Deploy temporary WAF or reverse proxy rules to detect and block requests for `/mcp/v1/` paths while remediation is underway.
• Because EPSS is high and exploit maturity is weaponized, treat internet-exposed vulnerable sites as potentially compromised until log review and account validation are complete.