Skip to main content
Vulnerability Database/CVE-2026-105864

CVE-2026-105864: Payload CMS Multi-Tenant Auth Bypass

CVE-2026-105864 is an authentication bypass flaw in Payload CMS Multi-Tenant Plugin that allows authenticated users to create records in unauthorized tenants. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-105864 Overview

CVE-2026-105864 is an authorization flaw in the @payloadcms/plugin-multi-tenant package used by Payload, an open source headless content management system. An authenticated user scoped to a single tenant can create a record inside another tenant when at least one tenant-enabled collection exists in the installation. The flaw is categorized as improper authorization [CWE-863] and affects versions of the plugin prior to 3.90.0 and canary releases before 4.0.0-canary.34. Reads and direct edits of existing documents in the target tenant are not bypassed, which limits the blast radius to record creation. Maintainers released fixes in versions 3.90.0 and 4.0.0-canary.34.

Critical Impact

An authenticated low-privilege user bound to one tenant can create records in another tenant, breaking tenant isolation guarantees for multi-tenant Payload deployments.

Affected Products

  • @payloadcms/plugin-multi-tenant versions prior to 3.90.0
  • @payloadcms/plugin-multi-tenant canary versions prior to 4.0.0-canary.34
  • Payload CMS deployments that configure at least one tenant-enabled collection

Discovery Timeline

  • 2026-10-06 - CVE-2026-105864 published to the National Vulnerability Database
  • 2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-105864

Vulnerability Analysis

The @payloadcms/plugin-multi-tenant package enforces tenant scoping on documents through a tenant field attached to each tenant-enabled collection. The plugin derives the acting tenant from a cookie and uses that value when resolving default tenant assignment during document creation. The authorization check that validated the tenant cookie against the authenticated user's tenant membership did not fully constrain creation operations. As a result, a user with access to only one tenant could cause the server to assign a different tenant on create, producing a document owned by a tenant the user does not belong to. Read and update operations against pre-existing documents in that other tenant remain blocked, so the primary impact is unauthorized record insertion.

Root Cause

The tenant resolution logic in packages/plugin-multi-tenant/src/fields/tenantField/index.ts relied on the raw result of req.payload.count when validating the tenant extracted from the cookie. The handler treated the response as a boolean validity signal rather than extracting the totalDocs numeric count. This caused the validation branch to accept tenant values that should have been rejected, allowing a mismatched tenant to flow through to the default tenant assignment during document creation.

Attack Vector

The attack is network-reachable and requires an authenticated session for a user scoped to a single tenant. The attacker issues a create request against a tenant-enabled collection while supplying or steering the tenant cookie toward a target tenant identifier. Because the server validates the cookie incorrectly, the created record is persisted under the target tenant. No user interaction is required beyond the attacker's own authenticated session.

typescript
         })
         const tenantFromCookie = getTenantFromCookie(req.headers, idType)
         if (tenantFromCookie) {
-          const isValidTenant = await req.payload.count({
+          const { totalDocs } = await req.payload.count({
             collection: tenantsCollectionSlug,
             overrideAccess: false,
             req,

Source: Payload commit b8fc06a

The patch destructures totalDocs from the count response so the subsequent validity check compares an integer rather than an object reference, closing the bypass path.

Detect Identity Attacks the Moment Authentication Fails

Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.

Stop Identity Attacks

Detection Methods for CVE-2026-105864

Indicators of Compromise

  • Documents in tenant-enabled collections whose tenant field references a tenant that the creating user is not a member of.
  • Create requests from authenticated users where the payload-tenant cookie value does not match any tenant assigned to that user account.
  • Spikes in create operations against tenant-scoped collections originating from a small number of low-privilege accounts.

Detection Strategies

  • Audit application logs for create operations on tenant-enabled collections and correlate the authenticated user's tenant memberships with the resulting document's tenant field.
  • Add server-side logging around getTenantFromCookie to record the cookie-derived tenant alongside the acting user and compare the two values.
  • Query the database directly for records whose createdBy user has no membership in the referenced tenant.

Monitoring Recommendations

  • Monitor Payload admin and API endpoints for anomalous document creation volume from accounts limited to a single tenant.
  • Alert on cross-tenant writes by baselining expected tenant membership per account and flagging deviations in production telemetry.
  • Forward Payload application logs to a centralized logging or SIEM platform for retention and correlation with authentication events.

How to Mitigate CVE-2026-105864

Immediate Actions Required

  • Upgrade @payloadcms/plugin-multi-tenant to version 3.90.0 or later, or to canary release 4.0.0-canary.34 or later.
  • Review all tenant-enabled collections for documents whose owner-user does not belong to the document's tenant and remediate any orphaned or cross-tenant records.
  • Rotate session tokens and revoke suspicious authenticated sessions if cross-tenant creation activity is suspected.

Patch Information

The fix is available in Payload release v3.90.0 and canary release 4.0.0-canary.34. Technical details are documented in the GitHub Security Advisory GHSA-xhm9-gwgw-3q2q and the upstream commit.

Workarounds

  • If upgrading is not immediately possible, enforce additional access control hooks on tenant-enabled collections that reject create operations when the authenticated user's tenant list does not include the submitted tenant value.
  • Restrict administrative API tokens so that low-privilege accounts cannot submit tenant identifiers that fall outside their membership scope.
bash
# Upgrade the plugin to a patched release
npm install @payloadcms/plugin-multi-tenant@^3.90.0

# Or for canary users
npm install @payloadcms/plugin-multi-tenant@4.0.0-canary.34

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.