SURIQ
WordPress plugins are quietly bolting on a machine-to-machine login layer so AI agents can act on the site, and that new attack surface keeps producing the same class of bug. The latest lands in AI Engine, a chatbot and Model Context Protocol (MCP) plugin installed on more than 100,000 sites. Tracked as CVE-2026-15988, it lets an attacker create a brand-new administrator account on a vulnerable site if they can get a logged-in admin to click a single link. No account, no password, and no existing foothold on the attacker's side. Wordfence, which assigned the CVE, rates it 8.8 (high). The fix shipped in version 3.6.6 on July 30; every release up to and including 3.6.5 is affected.
Model Context Protocol (MCP) is the standard that lets AI assistants call tools and act on a system. To support it, AI Engine adds an OAuth bridge so an agent can authenticate to the WordPress site. That bridge is where this bug lives.
What actually goes wrong
Cross-site request forgery (CSRF) is an old class of attack: your browser carries your login cookie on every request, so a malicious page can make your browser fire a request that acts with your privileges. WordPress defends against it with a nonce, a one-time token that proves a request was made on purpose. A request that rides in on your cookie but carries no valid nonce is treated as anonymous. That downgrade is the whole point of the protection.
AI Engine's OAuth bridge needed an exception. For its own authorize step it re-validates the WordPress login cookie, so a real user is recognized even without a REST nonce. The problem was how it decided a request was the authorize step: it looked at the raw request URL as a plain string and asked whether the text of its authorize path appeared anywhere in it. A URL's query string is part of that raw text. So appending the authorize path as a harmless-looking query parameter to any other REST request made the plugin treat that request as the authorize route and restore the logged-in user's full identity, on an endpoint that WordPress was treating as anonymous precisely because it arrived without a nonce.
That one check silently undid WordPress's CSRF protection for any URL that merely mentioned the authorize path. Pair it with WordPress's built-in method override, which lets a plain GET (the request a browser makes when someone clicks a link) be reinterpreted as a POST, and a top-level navigation to the REST users endpoint becomes an authenticated request that creates an administrator with attacker-chosen credentials. The admin only had to open the link. The vendor's own patch note for 3.6.6 describes the fix as correcting the MCP OAuth route match, and the fixed code now compares the resolved REST route exactly instead of substring-matching the raw URL.
Who is exposed, and how urgent is it
Any site running AI Engine 3.6.5 or earlier is exposed, as long as an attacker can phish a logged-in administrator (or any account WordPress would let create users) into opening a crafted link. The interaction requirement is the one piece of good news: this is not a fire-and-forget unauthenticated exploit, so the attacker still needs a click. Weigh that against the reward, which is a full administrator account, meaning complete control of the site.
| Version | Status |
|---|---|
| 3.6.5 and earlier | Vulnerable to CVE-2026-15988 |
| 3.6.6 (July 30, 2026) | Fixed: exact route match |
| 3.6.7 (current) | Fixed, latest release |
At the time of writing there is no public exploit code and no report of exploitation in the wild. That is the calm before the write-up, not a reason to wait. A CSRF-to-administrator bug on a plugin with six figures of installs is exactly the kind of flaw that gets a one-line demonstration soon after disclosure.
The pattern worth noticing
This is the second serious authentication problem in AI Engine's machine-login features in a matter of months. In November, CVE-2025-11749, rated 9.8, exposed a bearer token through the same MCP feature set when a no-authentication URL option was enabled. Different bug, same neighborhood.
The through-line is the machine-authentication layer itself. To let AI agents log in and act, these bridges reimplement authentication and request routing by hand, and hand-rolled routing is precisely where a substring match gets mistaken for an exact one. We have seen the shape before in other agent plumbing, from an unauthenticated AI agent bridge that ran code to header injection in an LLM tool layer. If you are adding an MCP or agent surface to anything you run, treat its auth path as new, untested code, because that is what it is.
Update now, then audit your administrator accounts
Three steps, in order:
- Update AI Engine to 3.6.6 or later (3.6.7 is the current release). This is the only complete fix.
- Because the flaw creates accounts, patching tells you nothing about whether you were already hit. Open your Users list and review every administrator, with an eye on recently created ones you do not recognize.
- Going forward, treat an unexpected privileged-account creation on a public-facing site as an incident, not a curiosity. A new administrator appearing outside your normal onboarding is the single clearest sign of this attack, and it is the kind of event a managed detection setup should surface and escalate rather than leave sitting in a log.
The click requirement will tempt some teams to file this under low priority. The right read is the opposite: an admin who clicks links is not a rare specimen, and the payoff here is the top of the privilege ladder. Patch it this week, then go count your admins.