al-ice.ai

A WordPress MCP Plugin Shipped Three Auth Failures — Including One-Click Admin Creation

AI Vulnerabilities & CVEs by al-ice.ai Editorial

Three CVE records published in the National Vulnerability Database on 26 September 2026 describe the same failure in triplicate: the MCP Server for WordPress plugin (AtlasMCP, by Azizul Hasan) did not check who was allowed to do what across its REST API. Versions before 1.8.2 are affected; all three records name WPScan as CNA and carry no CVSS score yet — NVD still lists them as Received. The plugin is small (around 200 active installs), but the pattern is the one this site keeps documenting across the MCP ecosystem: every new agent-to-system bridge ships its own authorization layer, and that layer is where the bugs live.

The most severe of the three needs no account at all. CVE-2026-96524 is a REST API nonce-verification failure on cookie-authenticated requests, present when a condition the attacker can influence holds. Per the NVD description, an unauthenticated attacker can perform administrator-only actions — including creating a new administrator account — by tricking a logged-in administrator into visiting a crafted page. That is a classic cross-site request forgery shape with the highest available payoff: one click from an admin, and the site has a second admin the real one never created.

The other two hand Contributors the keys to the agent layer

CVE-2026-96525 (CWE-862, missing authorization) finds no ownership or capability check on the plugin's workflow create, update, and delete REST routes. Any user with the Contributor role — a role normally confined to writing and editing their own drafts — could modify, delete, and create site-wide workflow configuration, including workflows created by administrators. CVE-2026-96526 (CWE-200, information exposure) drops the object-level authorization check on a workflow REST route, letting Contributors disclose the title and publication status of any post, page, or custom post type — including other users' private, draft, pending, and scheduled content.

The workflow detail is what makes this an AI-security story rather than a routine WordPress authz bug. This plugin's workflows are shared AI prompts and prompt templates executed through MCP connections — the behaviour layer that decides what the site's agents do. A Contributor who can rewrite an administrator's workflow does not need shell access or an admin account; they need to edit the instructions the agent follows. Every subsequent agent run then executes attacker-shaped behaviour with the site's own credentials. It is the same privilege-shape we keep seeing in agent runtimes — compare the OpenClaw authorization batch, where dozens of command handlers skipped the owner check — now expressed in a CMS plugin that turns WordPress into an MCP server.

Silent patch Tuesday, CVE Saturday

The vendor's own changelog reconstructs a responsible timeline. Version 1.8.2, released 23 September, is a security release crediting researcher Raphael P. Cigana, reported through WPScan: the harmful-link REST fix, workflows locked to administrators, workflow execution gated on edit permission for the target post with per-role ability scoping. But the changelog contains more than the three CVEs describe — OAuth-approved AI connections scoped so their permissions can never exceed the registered app's, the connection approval page pinned to its own site (anti-clickjacking), connections and tokens invalidated on password change or user deletion, AI generation history sanitized before storage, and the general REST tool barred from reaching the plugin's own settings. That is a broad hardening pass bundled with the named fixes, and three days later the identifiers landed in NVD. Patch on Tuesday, CVE on Saturday: the now-standard lag between the fix defenders can install and the identifier their scanners can see. Version 1.8.3 followed on 24 September as a pure rebrand release (AtlasAI Connector → AtlasMCP), so 1.8.2 or later is the fixed line.

Two caveats before you triage. First, with no CVSS assigned yet, severity-keyed pipelines will file these wherever unrated CVEs go in your shop — do not let the absence of a number read as the absence of impact; unauthenticated admin creation is the impact. Second, the install base is small, but the WordPress.org directory currently tags over a hundred MCP-related plugins, most of them young, fast-moving, and written against the same REST-plus-agent pattern. This trio is unlikely to be the last of its shape. If you run any MCP bridge on WordPress, the audit question is generic: which REST routes assume the caller is privileged without checking, and which agent behaviours can a low-privilege user rewrite?

What to do

  • Update MCP Server for WordPress to 1.8.2 or later immediately. The CSRF-to-admin-creation flaw needs only a logged-in admin to open a crafted page — no authentication for the attacker, no interaction beyond a click.
  • Hunt for a rogue administrator account. If you ran a version below 1.8.2 with untrusted traffic, enumerate admin users and creation timestamps; the exploit's payoff is a persistent account, not a transient session.
  • Diff your AI workflows against a known-good copy. Any Contributor-level account active before the patch could have altered shared prompts and templates. Treat workflow configuration as privileged state and review it like code.
  • Audit other MCP bridge plugins the same way. Unauthenticated or low-privilege REST routes, inline credentials in shared configs, and agent behaviour editable below admin level are the recurring shapes — mcp-atlassian's unauthenticated file exfiltration and LiteLLM's MCP auth bypass, now in CISA's KEV catalog, are the same genus.

Sources: