CVE-2026-105806 in Payload CMS
Summary
by MITRE • 10/06/2026
Payload is a free and open source headless content management system. In @payloadcms/plugin-mcp versions from 3.61.0 until 3.88.0, an authenticated user can manage MCP API keys outside the intended account, enabling privilege escalation through account takeover. This issue is fixed in version 3.88.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Payload CMS plugin-mcp versions ranging from 3.61.0 to 3.88.0 represents a critical authentication and authorization flaw that allows authenticated users to manipulate Multi-Protocol Communication API keys associated with accounts other than their own. This issue stems from an insufficient verification of resource ownership during the management operations for MCP API keys. In typical secure implementations, any action involving sensitive credentials such as API key generation, modification, or deletion must be strictly bound to the identity and permissions of the currently authenticated user session. However, in this specific range of versions, the backend logic fails to adequately validate that the target account associated with the requested operation belongs to the requesting user. This oversight creates a direct pathway for privilege escalation through account takeover mechanisms, as an attacker can leverage their own valid credentials to perform administrative actions on victim accounts without possessing those victims' actual login details or secondary authentication factors.
From a technical perspective, this flaw aligns closely with CWE-284 Improper Access Control and CWE-639 Authorization Bypass Through User-Controlled Key. The root cause lies in the application's reliance on client-supplied identifiers to locate resources for modification without cross-referencing these against the session context of the authenticated user. When a user initiates an API key management request, the system retrieves the specified account identifier and proceeds with the operation assuming that access is granted based solely on the presence of valid authentication tokens. It does not enforce strict object-level authorization checks to ensure that the resource being modified is owned by or explicitly shared with the authenticated principal. This architectural weakness effectively decouples the action from the actor, allowing malicious actors to escalate their privileges within the application ecosystem by taking control of API keys belonging to other users or administrative accounts.
The operational impact of this vulnerability is severe due to its potential for widespread account compromise and data exfiltration. Since MCP plugins often facilitate integrations with external services such as large language models or automated workflows, possessing valid API keys grants an attacker the ability to act on behalf of the compromised account. This can lead to unauthorized access to sensitive content stored within Payload CMS, manipulation of published materials, and potential integration abuse where malicious payloads are executed through connected third-party services. Furthermore, because the vulnerability allows for privilege escalation, attackers could potentially gain administrative capabilities if they target accounts with elevated roles, thereby compromising the entire instance's integrity and confidentiality. The ability to manage API keys outside the intended account also undermines audit trails and accountability measures, making it difficult to trace malicious activities back to specific individuals when multiple users share infrastructure or have overlapping permissions.
Mitigation strategies must prioritize immediate patching alongside robust access control enforcement. Organizations running affected versions should upgrade directly to version 3.88.0 or later where this issue has been resolved by implementing strict ownership verification during API key management operations. In the interim, before an upgrade can be performed, administrators should restrict direct database access and review application logs for anomalous patterns indicating unauthorized attempts to modify resources belonging to other users. Implementing additional middleware that validates resource ownership against session data at every step of the request lifecycle is essential to prevent exploitation. Security teams should also enforce multi-factor authentication across all user accounts to add a layer of defense-in-depth, ensuring that even if an attacker gains access via this vulnerability, they cannot easily authenticate into external services using stolen API keys without additional verification steps. Regular security audits and penetration testing focused on authorization bypasses are recommended to identify similar flaws in other parts of the application architecture.