Get Started
CVE July 22, 2026 5 min read

CVE-2025-11749: AI Engine Plugin Leaked Admin Bearer Tokens on 100,000+ WordPress Sites (CVSS 9.8)

A critical flaw in the popular AI Engine plugin exposed a secret Bearer Token through an unauthenticated REST API endpoint, letting attackers hijack an admin session and take over the site. It affects versions up to 3.1.3 and is fixed in 3.1.4. Here is how it works and what to do.

AI Engine is one of the most widely used AI plugins for WordPress, powering chatbots, content generators, and AI-assisted workflows on more than 100,000 active sites. In October 2025, security researchers disclosed a critical vulnerability in the plugin that let unauthenticated attackers steal a secret authentication token and use it to take full control of the site. Tracked as CVE-2025-11749 and rated CVSS 9.8 (Critical), the flaw is a textbook example of how one convenience feature, left exposed, can hand an attacker the keys to your entire WordPress install.

If you run AI Engine, this is one to act on quickly. Below we break down exactly what went wrong, what an attacker could do with it, how to check whether your site is affected, and how to fix it.

CVE Details at a Glance

  • CVE ID: CVE-2025-11749
  • Plugin: AI Engine (by Jordy Meow / Meow Apps)
  • CVSS Score: 9.8 (Critical)
  • Vulnerability type: Sensitive Information Exposure leading to Privilege Escalation
  • Affected versions: All versions up to and including 3.1.3
  • Patched version: 3.1.4 (released October 19, 2025)
  • Active installations: 100,000+
  • Authentication required: None (unauthenticated)
  • Reported by: Emiliano Versini via the Wordfence Bug Bounty Program

How the Vulnerability Works

Recent versions of AI Engine include support for the Model Context Protocol (MCP), a standard that lets external AI tools and agents connect to your WordPress site and perform actions on it. Because MCP is designed for machine-to-machine communication, AI Engine protects it with a secret Bearer Token — a long, random string that acts like a password. Any request carrying the correct Bearer Token is trusted and allowed to run privileged operations through the plugin.

The problem lies in an optional feature called the “No-Auth URL.” When a site owner enabled this option, the plugin’s MCP REST API endpoint (/mcp/v1/) returned the Bearer Token value in its response — and that endpoint could be reached by anyone, with no login and no authentication of any kind. In other words, the very secret that was supposed to gate access to the site’s most powerful functions was being handed out to any anonymous visitor who asked for it.

To exploit it, an attacker needed nothing more than the ability to send a web request to the vulnerable endpoint. There was no need to guess passwords, trick an administrator, or already hold an account on the site. Once the attacker read the token from the exposed endpoint, they could turn around and present that same token to the MCP interface as a fully trusted client.

Real-World Impact

Holding a valid Bearer Token effectively gave an attacker a trusted session with the site. Through the MCP interface, that access could be used to perform high-privilege actions — most dangerously, creating a brand-new administrator account. From there, the consequences are the familiar full-compromise scenario:

  • Logging in as a new administrator and taking complete control of the dashboard
  • Installing malicious plugins or themes to establish a persistent backdoor
  • Injecting spam, SEO spam, or malicious redirects that damage your search rankings and reputation
  • Planting web shells or malware to serve drive-by downloads to your visitors
  • Stealing customer data, user records, or order information
  • Locking you out of your own site entirely

Because the flaw requires no authentication and can be automated, vulnerabilities like this are typically swept up quickly by bots that scan the entire internet for exposed WordPress sites. A CVSS score of 9.8 reflects exactly this combination: easy to exploit remotely, no privileges needed, and total loss of confidentiality, integrity, and availability if successful.

How to Check If You’re Affected

Work through the following steps to determine your exposure:

  • Confirm the plugin is installed. In your WordPress dashboard go to Plugins → Installed Plugins and look for “AI Engine” (also branded under Meow Apps). If it is not present, you are not affected by this particular flaw.
  • Check the version number. On the same Plugins screen, read the version listed beneath AI Engine. Any version up to and including 3.1.3 is vulnerable. Version 3.1.4 or later contains the fix.
  • Check whether the risky feature was enabled. The token was only exposed when the MCP “No-Auth URL” option was turned on. Sites that never enabled MCP or the No-Auth URL had less exposure — but you should still update regardless, because relying on a setting to stay safe is fragile.
  • Look for signs of compromise. Review your list of administrator users under Users → All Users for accounts you don’t recognize, and check for unexpected plugins, themes, or scheduled tasks. Unfamiliar admin accounts are the clearest red flag for this type of attack.

How to Fix It

The single most important action is to update the plugin:

  • Update AI Engine to version 3.1.4 or later. Go to Plugins → Installed Plugins, and if an update is available for AI Engine, apply it immediately. You can also update from Dashboard → Updates. This closes the hole by no longer exposing the Bearer Token through the unauthenticated endpoint.
  • Rotate the Bearer Token after updating. If your site ran a vulnerable version with the No-Auth URL enabled, assume the token may already have been captured. Regenerate or reset the MCP Bearer Token in the plugin settings so any previously leaked value becomes useless.
  • Disable features you don’t use. If you are not actively using MCP or the No-Auth URL, turn those options off. Reducing your attack surface is one of the cheapest security wins available.
  • Audit for unauthorized changes. Remove any administrator accounts you did not create, review recently installed plugins and themes, and scan the site for malware. If you find evidence of compromise, treat it as a full incident: restore from a known-good backup, change all passwords, and rotate secret keys.
  • Add a layer of monitoring. A web application firewall (WAF) or a reputable security plugin can block exploit attempts against endpoints like this — useful protection for the window between a disclosure and the moment you actually apply the patch.

The Takeaway

CVE-2025-11749 is a reminder that new capabilities bring new risk. AI features and machine-to-machine integrations like MCP are genuinely useful, but every new endpoint is a new door — and a door that hands out its own key to anyone who knocks is worse than no door at all. The good news is that the plugin’s developer patched the issue promptly, and the fix is a routine update away.

The broader lesson is the same one that protects WordPress sites against nearly every plugin vulnerability: keep everything updated, enable only the features you actually need, use a firewall, take regular backups, and periodically review who has administrator access. None of these steps is glamorous, but together they turn a critical, site-ending flaw into a non-event you patched before it ever became a problem.

Related Articles