WordPress MCP Security: What Each Setup Exposes

Where a WordPress MCP request is actually authorised. Diagram by WPNeon, 29 August 2026, drawn from the WordPress/mcp-adapter transport-permissions documentation and the NVD entry for CVE-2026-15015.

WordPress MCP security starts with an account, not a firewall

The single most useful sentence written about WordPress MCP security comes from the WordPress Developer Blog, in Jonathan Bossenger’s introduction to the MCP Adapter on 4 February 2026: MCP clients “act as logged-in WordPress users.” That is the whole model. There is no separate AI permission layer, no sandbox, no read-only mode that WordPress applies on your behalf. When Claude, ChatGPT or Cursor calls a tool on your site, WordPress asks the same question it asks of any authenticated request: does this user have this capability?

This is genuinely good news, and most coverage of the topic misses why. WordPress already has two decades of capability plumbing — roles, current_user_can(), per-post checks. MCP inherits all of it for free. A subscriber connecting an AI client cannot suddenly publish posts, because the subscriber role does not include publish_posts and the ability layer checks that capability before it runs.

The bad news is the corollary. If you connect an AI client using an administrator account and an application password — which is the path of least resistance, and the one nearly every setup tutorial demonstrates — then that client can do everything an administrator can do. Install plugins. Edit users. Read every order in your store. The protocol did not weaken your site; the account you handed it did.

That is why the useful version of this discussion is about accounts, gates and defaults rather than about whether “MCP is safe.” Below, four gates, one real vulnerability, and what each of the shipping options actually gives you.

The four gates a request has to pass

Reading the WordPress/mcp-adapter repository and its transport-permissions guide, a request from an AI client crosses four checkpoints before it touches data. Each one can be loosened independently, and the request ends up as permissive as the weakest of the four.

1. The credential. Something has to prove who is calling. In practice this is a WordPress Application Password, an OAuth 2.1 flow, or a bearer token minted by the connector plugin. Application Passwords are the WordPress core default and are per-user, revocable and separate from the login password — which is better than it sounds, because revoking one does not lock the human out of wp-admin.

2. The transport gate. This is server-wide. The adapter’s documentation is explicit that transport permissions “act as a gatekeeper — if blocked here, users cannot access ANY abilities on that server.” When no permission callback is supplied, the adapter defaults to is_user_logged_in(), and exceptions thrown inside a custom callback fall back to that same check rather than failing open. Both are sensible defaults.

3. The ability gate. Each individual ability — each tool the AI can call — carries its own permission_callback. This is where a well-built integration says “this tool requires edit_posts” and a badly built one says __return_true. The WordPress Developer Blog guidance names this directly: verify the minimum required capability per ability, and do not use broad permissions for destructive operations.

4. The WordPress capability itself. Finally, core checks the user’s actual role. This is the gate you control without writing any code, simply by choosing which account the AI connects as.

Four gates sounds like defence in depth, and it is — but only gate four is on by default in a form you cannot accidentally disable. Gates two and three are code, and code can be written badly.

What CVE-2026-15015 actually shows

On 23 July 2026, NIST published CVE-2026-15015 against the MountDev AI MCP Connector for WordPress. The description is short enough to quote in full: the plugin “is vulnerable to authorization bypass in all versions up to, and including, 1.6.1. This is due to the plugin not properly verifying that a user is authorized to perform an action.”

It carries a CVSS 3.1 base score of 9.8, Critical, on vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Read that vector plainly: attackable over the network, low complexity, no privileges required, no user interaction, with total loss of confidentiality, integrity and availability. No privileges required is the part that matters. This was not a case of a low-privilege user escalating. It was gate three missing.

The NVD references point at four specific line numbers in includes/class-oauth-controller.php in the plugin’s 1.6.0 tag, alongside the changeset that fixed it. That detail is worth noting because it locates the failure precisely: the flaw sat in the OAuth controller — the component whose entire job is deciding who may do what.

Two things stop this from being a story about MCP being inherently dangerous. First, as listed on the WordPress.org plugin page for the MountDev AI MCP Connector on 29 August 2026, the plugin is now at version 1.6.5 and the affected range ended at 1.6.1 — this is patched, and it reached roughly 100 active installations, not a hundred thousand. Second, this is a plugin implementation bug, not a protocol flaw. The MCP specification itself forbids precisely this class of mistake.

What it does show is that the connector layer is where WordPress MCP security is currently won or lost. The protocol is fine. Core’s capability system is fine. The thin plugin in between, written quickly to catch a hot market, is the part that shipped an unauthenticated bypass to a live directory listing.

What the MCP specification requires of a server

The MCP security best practices document, revision 2026-07-28, is normative and short on ambiguity. Three of its requirements bear directly on WordPress deployments.

Token passthrough is forbidden. The specification’s language is that “MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.” A server that accepts a token minted for some other service, and forwards it downstream unvalidated, breaks the audience boundary OAuth exists to enforce and destroys the audit trail along with it.

Possession of a handle is not authentication. On state handle hijacking, the spec is blunt: “MCP servers MUST NOT treat possession of a state handle as authentication,” and servers should bind handles server-side to the authenticated user. This is the same mistake CVE-2026-15015 made in a different costume — trusting an identifier the caller supplied instead of the identity the token proved.

Proxy servers must obtain per-client consent. Where an MCP server brokers access to a third-party API using a static client ID, it must run its own consent screen before forwarding to the third party, or an attacker can ride an existing consent cookie to have authorization codes redirected to a server they control. This is the classic confused deputy problem, and it applies to any WordPress plugin acting as an OAuth proxy in front of another service.

None of these are exotic. They are the standard OAuth failure modes, restated for a new transport, and they are worth reading before trusting any connector that advertises OAuth support as a feature bullet.

What is actually shipping, and what each option is

Here is the state of the WordPress MCP landscape as recorded on 29 August 2026, from the WordPress.org plugin directory and the projects’ own repositories. Version numbers, install counts and ratings are as listed on those pages on that date. For the fuller picture of which packages are maintained and which have been archived, see our page on which WordPress MCP server packages are maintained and which are archived.

Option	Status, 29 Aug 2026	Authentication	Where it loses
WordPress/mcp-adapter Official AI Building Block	Active. Requires WordPress 6.9+ and PHP 7.4+. HTTP and STDIO transports.	Delegated to WordPress. Transport gate defaults to is_user_logged_in(); per-ability permission callbacks.	It is a developer library, not a turnkey product. You register the abilities and write the callbacks. Requires WordPress 6.9, which rules out older sites.
Enable Abilities for MCP Fabio Montenegro	v2.5.0, updated 4 days before capture. 2,000+ active installs, tested to WP 7.0.4, rated 5.0 from 8 reviews.	OAuth 2.1 via claude.ai, Application Passwords, optional bearer token. Abilities enforce WordPress capabilities; execution logged under the real user.	Eight reviews is a thin evidence base for a security-sensitive plugin. The optional single-admin bearer token is the weakest path it offers and should stay off.
MountDev AI MCP Connector	v1.6.5, updated roughly one month before capture. 100+ active installs, tested to WP 7.0.4, no reviews submitted.	OAuth 2.0 for ChatGPT; Application Passwords for Claude Desktop, Cursor and Windsurf. 389 advertised tools.	Carried CVE-2026-15015, a CVSS 9.8 authorization bypass, through 1.6.1. Patched, but 389 tools across WooCommerce, Yoast and Jetpack is a very large surface for a plugin with no reviews.
Automattic/wordpress-mcp	Archived. Last release v0.2.5, 24 July 2025. Repository directs users to WordPress/mcp-adapter.	Historic. Not maintained.	Do not deploy it. An archived repository receives no security fixes, and several third-party guides still recommend it.

Separately, two managed hosts ship platform-tied MCP servers: WordPress VIP documents “Secure MCP” on its own documentation site, dated 8 July 2026, and WP Engine publishes an MCP server page dated 16 August 2026. Both are only available to customers of those platforms, which is the honest answer to whether they are relevant to most readers of this page. We have not independently examined either implementation, and say so rather than repeating their feature lists as findings.

Where each WordPress MCP security model loses

Stating the weakness of each approach is more useful than ranking them, because the right answer depends on what you are running.

Application Passwords lose on scope. They are per-user and revocable, which is good, but they are not scoped. An application password for an administrator is an administrator credential; there is no way to mint one that only permits reading posts. The scoping has to come from the role you attach it to, which means the control is “create a limited user,” not “create a limited token.”

OAuth 2.1 loses on implementation surface. It is the stronger model on paper — per-client consent, PKCE, scoped grants — and it is also more code, which is more places to get it wrong. CVE-2026-15015 was a flaw in an OAuth controller, not in an application-password path. OAuth done properly beats application passwords; OAuth done hastily is worse than either.

Bearer tokens lose on identity. A single shared admin token collapses every user into one principal. Your audit log then tells you an action happened, but not who caused it. If a connector offers a bearer token as a convenience option, treat it as a development shortcut rather than a production setting.

The adapter loses on effort. The official adapter has the best defaults and the worst onboarding, because it is a library. Nothing works until you register abilities and write permission callbacks, and the temptation at that moment is to pass __return_true to make the demo run — which removes gate three permanently, for that ability, on that server.

A configuration that holds up

Combining the WordPress Developer Blog’s guidance with the specification’s requirements, this is the setup that keeps the gates intact. None of it requires a paid product.

Create a dedicated MCP user. Not your administrator account, and not a shared editorial login. Give it the narrowest role that lets the AI do the job you actually want. If you only need drafting, an account with edit_posts but not publish_posts means a compromised token produces drafts, not live pages. Our roundup of WordPress user role plugins covers the tools for building a custom role without code.

Keep exposed HTTP transports read-only. The developer blog’s recommendation for publicly reachable HTTP transports is to focus on read-only diagnostics, reporting and content access rather than write operations. A read-only endpoint that leaks is an information disclosure; a writable one is a defacement.

Use STDIO where you can. The MCP specification advises servers intended to run locally to use the STDIO transport specifically to limit access to just the MCP client. If your AI tooling runs on your own machine against your own site, there is no reason to open an HTTP endpoint to the internet.

Audit what the connector exposes before enabling it. A plugin advertising several hundred tools is exposing several hundred code paths, each of which needs its own permission check. Fewer, better-scoped abilities are safer than a large catalogue, whatever the marketing says.

Treat the MCP account like any other privileged access. Rotate its credential on the same schedule as the rest of your site, keep it out of shared password stores, and revoke it the moment the integration is no longer in use. The same discipline applies here as to any elevated account, which is worth pairing with the monitoring and hardening covered in our comparison of WordPress security plugins and our separate write-up of security plugins for site protection.

Have a restore path. An AI client with write access is a new way for content to be mass-modified in seconds, whether through a bug, a bad prompt or a stolen credential. Verified, recent, off-site backups are the control that makes that recoverable. Our list of WordPress backup plugins is the practical starting point.

What we could not verify

Saying what is uncertain is part of the point of this page, and this topic has more uncertainty than most because it is barely a year old.

WPNeon does not run a test rig, and nothing here comes from installing or attacking these plugins. Every claim above is drawn from the WordPress.org plugin directory, project repositories and their documentation, the WordPress Developer Blog, the MCP specification and the NVD record, all read on 29 August 2026, and it is stated that way deliberately. Our full method is set out at how WPNeon verifies what it publishes.

Three specific gaps are worth naming. We could not confirm the exact patch version for CVE-2026-15015 — the NVD entry records the affected range as up to and including 1.6.1 and links the fixing changeset, but does not state the fixed release, and the plugin has since moved to 1.6.5. We did not examine the WordPress VIP or WP Engine implementations, because both sit behind those platforms. And we found no other MCP-specific WordPress CVE in the public record as of this capture date, which is a genuine finding rather than a reassurance: the category is new, the install counts are small, and small install counts attract less security research, not less risk.

Search demand data is similarly thin. Keyword tools returned no volume at all for WordPress-scoped MCP security terms on this date. That is a signal about how early this is, not about whether it matters.

Frequently asked questions about WordPress MCP security

Is it safe to connect Claude or ChatGPT to my WordPress site?

It is as safe as the account you connect with. An MCP client acts as a logged-in WordPress user, so it inherits exactly that user’s capabilities. Connect through a dedicated account with a narrow role and the risk is bounded; connect as an administrator and the client can do anything you can.

Do I need an MCP plugin, or is the official adapter enough?

The official WordPress MCP Adapter is a developer library requiring WordPress 6.9 or later. If you write PHP and want control over which abilities are exposed, it is the better foundation. If you want something that works after activation, a directory plugin is the practical route — with the review burden that implies.

What was CVE-2026-15015 and am I affected?

It was a CVSS 9.8 authorization bypass in the MountDev AI MCP Connector, published 23 July 2026, affecting all versions up to and including 1.6.1. The plugin did not properly verify that a user was authorised to perform an action. You are affected only if you run that specific plugin below version 1.6.2.

Are Application Passwords or OAuth better for MCP?

OAuth 2.1 is the stronger model because it supports per-client consent and scoped grants, but it is also far more code and therefore more implementation risk. Application Passwords are simpler and revocable, but unscoped. In practice, a narrow WordPress role matters more than which of the two you choose.

Should I expose an MCP endpoint over HTTP?

Only if you need remote access. The MCP specification recommends the STDIO transport for locally run servers precisely to limit access to the client. If you do expose HTTP, the WordPress Developer Blog’s guidance is to keep those transports read-only rather than allowing write operations.

Does an MCP integration replace my security plugin?

No, and it adds a surface rather than removing one. MCP introduces a new authenticated path into your site, so the usual controls still apply: least-privilege accounts, credential rotation, monitoring and tested backups. Treat the MCP account as privileged access and secure it accordingly.

Where this leaves you

WordPress MCP security is currently in the phase every new integration surface goes through: the protocol is specified carefully, the platform’s own tooling has reasonable defaults, and the connector plugins racing to serve demand are the weak point. One of them shipped an unauthenticated authorization bypass to the plugin directory this July. That is a small install base and a patched bug, but it is the exact failure the specification and the adapter’s documentation both warn about, which suggests it will not be the last.

The defensive posture that survives all of this is unglamorous and account-shaped. Pick the narrowest role that does the job. Do not connect as an administrator because the tutorial did. Keep public endpoints read-only. Check what a connector actually exposes before you activate it, and check whether anyone has reviewed it. Keep a restore path.

If you are still deciding which package to build on, our companion page on the maintained and archived WordPress MCP server packages covers what happened to Automattic’s original implementation and where active development moved. And if your site handles transactions, the same least-privilege reasoning applies to every other integration you have authenticated — including the ones covered in our roundup of WordPress payment gateway plugins, our list of WordPress anti-spam plugins and our comparison of custom login plugins for WordPress.