Summary
Payload's multi-tenant plugin may allow an authenticated user to assign their own account to tenants they are not authorized to access. The risk arises when the default tenant array field access behavior is used without custom checks that validate tenant membership and authorization.
Payload's multi-tenant plugin may allow an authenticated user to assign their own account to tenants they are not authorized to access. The risk arises when the default tenant array field access behavior is used without custom checks that validate tenant membership and authorization.
Affected context
The issue occurs in deployments using the Payload multi-tenant plugin with its default tenant array field access behavior. It may affect applications where authenticated users can update account tenant assignments and where custom create and update authorization functions have not been configured for the tenants array field.
The issue occurs in deployments using the Payload multi-tenant plugin with its default tenant array field access behavior. It may affect applications where authenticated users can update account tenant assignments and where custom create and update authorization functions have not been configured for the tenants array field.
Exploit preconditions
- Attack surface: Tenant membership or account update functionality exposed by the application
- Required access: An authenticated user account with permission to submit relevant account or tenant-assignment changes
- Trigger point: Creation or update of the user's tenant array field
- Why exploitation is possible: Default field access behavior may fail to verify that each selected tenant is authorized for the requesting user
- Attack surface: Tenant membership or account update functionality exposed by the application
- Required access: An authenticated user account with permission to submit relevant account or tenant-assignment changes
- Trigger point: Creation or update of the user's tenant array field
- Why exploitation is possible: Default field access behavior may fail to verify that each selected tenant is authorized for the requesting user
Why this happens
The underlying bug is an authorization failure mapped to CWE-862, Missing Authorization. The tenant array field's default create and update access behavior does not sufficiently enforce tenant-specific authorization before accepting membership changes. This creates an insecure pattern in which authenticated identity is treated as sufficient authority to modify authorization-related tenant assignments.
The underlying bug is an authorization failure mapped to CWE-862, Missing Authorization. The tenant array field's default create and update access behavior does not sufficiently enforce tenant-specific authorization before accepting membership changes. This creates an insecure pattern in which authenticated identity is treated as sufficient authority to modify authorization-related tenant assignments.
Potential impact
- An attacker may gain access to data belonging to additional tenants
- An attacker could perform actions within tenants they should not access
- Cross-tenant data exposure or modification may occur
- Tenant isolation and audit assumptions can be weakened
- An attacker may gain access to data belonging to additional tenants
- An attacker could perform actions within tenants they should not access
- Cross-tenant data exposure or modification may occur
- Tenant isolation and audit assumptions can be weakened
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the tenant
membership field and reducing trust in client-supplied tenant identifiers.
Common defensive patterns include:
- Defining explicit, deny-by-default authorization functions for tenant array creation and updates
- Verifying every requested tenant against the authenticated user's permitted scope
- Enforcing tenant isolation on reads, writes, and administrative operations
- Preventing users from self-assigning privileged or unrelated tenant memberships
- Applying least privilege to roles that can modify account and membership records
- Revalidating authorization on the server rather than relying on client-side controls
Mitigation generally focuses on enforcing authorization at the tenant
membership field and reducing trust in client-supplied tenant identifiers.
Common defensive patterns include:
- Defining explicit, deny-by-default authorization functions for tenant array creation and updates
- Verifying every requested tenant against the authenticated user's permitted scope
- Enforcing tenant isolation on reads, writes, and administrative operations
- Preventing users from self-assigning privileged or unrelated tenant memberships
- Applying least privilege to roles that can modify account and membership records
- Revalidating authorization on the server rather than relying on client-side controls
How teams detect issues like this
Organizations can identify similar authorization issues through:
- Static analysis and code review of access-control callbacks on tenant and membership fields
- Tests that attempt cross-tenant membership changes with ordinary authenticated accounts
- Review of policies for deny-by-default behavior and object-level authorization
- Monitoring audit logs for unexpected tenant membership additions or changes
- Automated security checks that flag writable authorization-related fields without explicit authorization logic
Organizations can identify similar authorization issues through:
- Static analysis and code review of access-control callbacks on tenant and membership fields
- Tests that attempt cross-tenant membership changes with ordinary authenticated accounts
- Review of policies for deny-by-default behavior and object-level authorization
- Monitoring audit logs for unexpected tenant membership additions or changes
- Automated security checks that flag writable authorization-related fields without explicit authorization logic
