Payload patches MCP plugin flaw that allowed account takeover

Payload has patched an access control flaw in its Model Context Protocol plugin that let an authenticated user manage MCP API keys outside their own account, according to a GitHub security advisory published on 6 October 2026.

The advisory, tracked as GHSA-2q76-m6w6-qgc6 and CVE-2026-105806, affects the npm package @payloadcms/plugin-mcp. The advisory says that "under certain conditions, an authenticated user could manage MCP API keys outside their intended account allowing an attacker to escalate privileges through account takeover".

MCP is the Model Context Protocol, a standard way for AI agents and assistants to connect to external tools and data sources. The Payload plugin exposes a CMS through that protocol, and MCP API keys are the credentials that let a client authenticate to it. Keys that can be managed by the wrong user are, in effect, keys that can be handed to the wrong user.

The advisory does not describe the specific conditions under which the flaw could be triggered, and does not say whether it has been exploited. It also does not state who found the issue.

According to the advisory, applications that do not use @payloadcms/plugin-mcp are not affected. That limits the blast radius to sites that have deliberately installed the plugin to expose their Payload instance to AI agent tooling.

Payload says users should upgrade to version 3.88.0 or later. For those who cannot upgrade immediately, the advisory lists two workarounds: disable the MCP plugin, or restrict MCP API-key management to trusted users. The company recommends upgrading rather than relying on the workarounds.

The pattern here is a familiar one in software, but it matters more in agent deployments. An API key for an MCP server is not a single permission. It is the gateway to whatever set of tools and content the server exposes. Where a traditional content management system would hand a compromised account the ability to edit pages, an MCP key can hand an automated client the ability to call tools on behalf of whoever the key belongs to. Privilege escalation through account takeover, as the advisory describes it, means an attacker starting from an ordinary logged-in account could end up with the access of a more privileged one.

The root cause recorded for the issue is excessive permissions: the key management functionality was reachable by users who should not have been able to reach it. That is a familiar failure mode for any feature that manages credentials on behalf of multiple tenants or accounts, where ownership checks have to be applied at every entry point rather than assumed from the fact that a user is logged in at all.

Administrators running the plugin should check which version they have deployed. Because the vulnerability requires an authenticated session, the practical exposure depends on how many accounts exist on a given instance and how easy it is to obtain one. Sites that allow self-registration have a larger pool of potential starting points than those where accounts are created only by administrators.

The advisory records the issue as confirmed. No further technical detail, proof-of-concept or timeline for discovery beyond the publication date has been released at the time of writing.