CVE-2026-105864 in Payload
Summary
by MITRE • 10/06/2026
Payload is a free and open source headless content management system. In @payloadcms/plugin-multi-tenant versions before 3.90.0 and canary versions before 4.0.0-canary.34, an authenticated user limited to one tenant can create a record in another tenant when at least one tenant-enabled collection exists. Reads and direct edits of existing documents in the target tenant are not bypassed. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Payload CMS plugin-multi-tenant prior to version 3.90.0 represents a critical failure in multi-tenancy isolation mechanisms, specifically allowing for unauthorized cross-tenant data injection. In a properly secured multi-tenant architecture, the system must enforce strict boundaries between distinct tenant contexts, ensuring that an authenticated user associated with one specific tenant cannot interact with resources belonging to another. However, due to insufficient validation of the target context during record creation operations, an attacker who has obtained valid credentials for a single tenant can exploit this flaw to create new records within the database schema of a different tenant. This bypass is possible provided that at least one collection in the system is configured as tenant-enabled, which serves as the vector for the injection despite the user lacking explicit permissions or awareness of the target tenant's existence.
From a technical perspective, this issue stems from inadequate server-side enforcement of tenant scoping during write operations. While read and direct edit operations are correctly restricted by existing access controls, the creation endpoint fails to bind the new document strictly to the authenticated user’s assigned tenant ID. Instead, it likely defaults to a global state or allows implicit context leakage where the system accepts input that effectively targets another tenant's namespace without verifying ownership. This asymmetry between read/write permissions creates a significant security gap, as attackers can pollute other tenants' data stores with malicious content, spam, or misleading information without triggering standard authorization errors during the write phase.
The operational impact of this vulnerability is severe in terms of data integrity and confidentiality within multi-tenant deployments. Although direct reading or editing of existing documents remains restricted, the ability to inject new records allows an attacker to disrupt business operations for other tenants by flooding their databases with noise, creating fake entities that may trigger automated workflows incorrectly, or embedding malicious links and content into shared systems. This undermines the fundamental promise of multi-tenancy, which is data isolation and security independence between customers sharing the same infrastructure. It also complicates audit trails and forensic analysis, as actions appear to originate from legitimate users but affect unrelated organizational units.
This vulnerability aligns with CWE-269 Improper Privilege Management, specifically regarding the failure to enforce role-based access controls for cross-resource operations. Furthermore, it relates to CWE-798 Use of Hard-coded Credentials if the exploitation relies on default configurations, though more accurately it fits CWE-862 Missing Authorization where the system fails to verify that the user has permission to perform the action on the specific resource instance being created. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1078 Valid Accounts and potentially T1539 Steal Web Session Cookie if credential theft is involved in gaining initial access, but primarily it represents a privilege escalation through logical flaws rather than technical exploitation of code execution vulnerabilities.
To mitigate this risk, organizations must immediately upgrade the payloadcms/plugin-multi-tenant package to version 3.90.0 or later for stable releases, and version 4.0.0-canary.34 or higher for canary builds. These versions contain patches that enforce strict tenant context validation during all database write operations, ensuring that new records are irrevocably bound to the authenticated user’s designated tenant ID regardless of input parameters. Additionally, developers should implement rigorous integration tests that simulate cross-tenant access attempts using automated security testing tools to verify isolation boundaries before deploying updates to production environments. Regular audits of multi-tenancy configurations and strict adherence to principle of least privilege for all API endpoints are essential practices to prevent similar logical flaws in future development cycles.