Skip to main content

Payload CMS EUVDEUVD-2026-93506

| CVE-2026-105860 HIGH
Missing Authorization (CWE-862)
2026-10-06 GitHub_M GHSA-p96c-xwx8-3cqj
7.1
CVSS 4.0 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Authenticate as low-privilege tenant user
  2. Exploit
    Submit crafted write to user tenants array field
  3. Execution
    Assign own account to other tenants
  4. Impact
    Gain unauthorized cross-tenant access

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK

1 technique across 1 tactic: Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires an authenticated low-privilege account in the plugin's tenant-managed admin users collection, and the application must run @payloadcms/plugin-multi-tenant before 3.90.0 (or a canary before 4.0.0-canary.34) using the DEFAULT tenant array field access. The attacker writes to the user's tenants array field to add their own account to tenants they are not a member of. Exploitation is explicitly PREVENTED when the deployment replaces the default behavior with secured tenants arrayFieldAccess.create and tenants arrayFieldAccess.update functions, or when the user passes userHasAccessToAllTenants; the fixed versions also enforce membership in a beforeValidate hook that rejects such writes.

Impact

Signals are moderate and internally consistent. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) indicates a network-reachable, low-complexity flaw that nonetheless requires an authenticated low-privilege account (PR:L), and the impact is scoped to integrity of the tenant-isolation model (VI:H) with no confidentiality or availability impact declared. This matches CWE-862 (Missing Authorization): an already-authenticated user escalates cross-tenant assignment rather than breaking in from nothing. No EPSS score was supplied in the input, there is no CISA KEV listing, and no public exploit was referenced - exploitation status is 'no public exploit identified at time of analysis.' This is therefore a real but not emergency priority: dangerous specifically for multi-tenant SaaS deployments where tenant isolation is the security boundary, but gated behind authentication and limited to deployments running the plugin's default arrayFieldAccess behavior. Two caveats to verify: (1) the vendor rated VC:N, yet assigning one's own account into another tenant plausibly enables READING that tenant's data, so real-world confidentiality impact may be understated - verify against your data model; (2) deployments that override the defaults with secured tenants arrayFieldAccess.create/update functions are explicitly not affected, so actual exposure depends on configuration.

Exploit ScenarioDerived

An attacker holds or registers a low-privilege account in a Payload application using the multi-tenant plugin with its default tenant array field access. Over the normal authenticated API, they submit a write that adds their own user to tenants they do not belong to, gaining cross-tenant access to data and administration they were never granted. No public exploit code was referenced, and the attack requires only a valid authenticated session with low complexity.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 06, 2026

Broken tenant-level authorization in @payloadcms/plugin-multi-tenant for Payload CMS before 3.90.0 (and canary releases before 4.0.0-canary.34) lets an authenticated, low-privilege user in the tenant-managed admin users collection add their own account to tenants they are not members of, granting cross-tenant access. The flaw is a missing-authorization condition (CWE-862) in the plugin's default tenants array field access, so an attacker only needs a valid account (PR:L in the CVSS vector) and network reachability to the affected application; no public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (not in CISA KEV). Deployments that override the default behavior with secured tenants arrayFieldAccess.create/update functions, or that rely on userHasAccessToAllTenants, are unaffected, and the vendor has released fixes in 3.90.0 and 4.0.0-canary.34.

RemediationAI

Upgrade @payloadcms/plugin-multi-tenant to 3.90.0 or later, or to canary 4.0.0-canary.34 or later (vendor-released patch); the fixed code enforces tenant membership in a beforeValidate hook and restricts tenant field writes to the tenant-managed admin users collection. If an immediate upgrade is impossible, the primary compensating control is to replace the default tenant access with explicitly secured tenants arrayFieldAccess.create and tenants arrayFieldAccess.update functions that verify the requesting user is already a member of every tenant being written - the trade-off being that deployments must keep this logic in sync as tenant models evolve, and any custom or override behaviors must be tested against the plugin's own write-check semantics. Administrators should also audit existing user documents for tenant memberships that appear unexpected, since the flaw permits silent self-assignment of additional tenants. Note that filterOptions only controls the admin UI dropdown and does not restrict what the server accepts on write, so hardening must be applied at the access-control layer rather than the UI; deployments placing the tenant field themselves via customTenantField should pass userHasAccessToAllTenants to tenantField to avoid rejecting legitimate privileged writes. Refer to the GitHub advisory GHSA-p96c-xwx8-3cqj and the 3.90.0 release notes for full upgrade guidance.

Affected VersionsENISA

payload 4.0.0-canary.0, < 4.0.0-canary.34
payload < 3.90.0

Affected Packages

npm @payloadcms/plugin-multi-tenant fix: 3.90.0, 4.0.0-canary.34
euvd payload fix: 3.90.0
euvd payload_4_0_0_canary_0 fix: 4.0.0-canary.34

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 3 packages in npm, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Payload is an open-source, headless content management system, and @payloadcms/plugin-multi-tenant is its official plugin for partitioning content across tenants. The plugin attaches a tenant relationship field to tenant-enabled collections and, by default, relies on generic field access rather than enforcing tenant membership on write. Because of this missing authorization check (CWE-862), an authenticated user can write to the tenants array field on their own admin user document and append tenant references they do not legitimately belong to, effectively escalating their scope inside the CMS. The upstream fix (commit 19b58692d20d3947f31124bf7a88ac14a5ebf02e) adds a collection-level beforeValidate hook that compares any submitted tenant against the user's assigned tenants and rejects the write with a field validation error, while also locking the tenant field's create/update access to the tenant-managed auth collection only. Notably the hook runs on drafts and autosave saves, where Payload normally skips field validation, and it deliberately reads the user's explicit tenant assignments instead of resolving filterOptions (which would require a database read inside the write transaction). Local API calls without a user (seed scripts, migrations) remain exempt, and userHasAccessToAllTenants still permits intentional cross-tenant writes. CPE data identifies the affected component family as cpe:2.3:a:payloadcms:payload.

Know when Payload gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 7.1 HIGH
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
vuln.today AI 6.5 MEDIUM

Authenticated low-privilege user (PR:L) performs a low-complexity network write; impact is integrity of tenant isolation (I:H), with confidentiality/availability not clearly established, matching vendor scoping.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
Low
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
High
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

2
Patch available
Oct 06, 2026 - 18:19 EUVD
CVE Published
Oct 06, 2026 - 16:33 cve.org
HIGH 7.1

DescriptionCVE.org

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, the default tenant array field access allows an authenticated user to assign the user's own account to other tenants. Deployments that replace the default behavior with secured tenants arrayFieldAccess.create and tenants arrayFieldAccess.update functions are not affected by this behavior. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.

Technical POC Analysis

Evidence base: GHSA-p96c-xwx8-3cqj only.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

Payload CMS deployments using @payloadcms/plugin-multi-tenant before version 3.90.0 (and canary releases before 4.0.0-canary.34) contain a broken tenant authorization flaw that lets any authenticated user add their own account to tenants they do not belong to. This undermines the multi-tenant isolation model that customers rely on, potentially exposing one organization's data to another and creating compliance and trust risks. Leadership should act promptly because a low-privilege account is all that is needed to cross tenant boundaries.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 86% exploitable
Prevalence
Low
headless CMS plugin, niche multi-tenant deployments only
Threat Intel
1
1 source
Data Quality
6 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact
High
Technical Impact
Partial

Priority Score

36
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +36
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

CVE-2022-27952 CRITICAL POC
9.8 Apr 12

An arbitrary file upload vulnerability in the file upload module of PayloadCMS v0.15.0 allows attackers to execute arbit

CVE-2026-105844 CRITICAL POC
9.3 Oct 06

Prototype pollution in Payload CMS's @payloadcms/plugin-import-export module lets an unauthenticated remote attacker sub

CVE-2026-105851 CRITICAL POC
9.3 Oct 06

Field-level access control can be bypassed in Payload CMS's document duplicate operation, letting a caller with access t

CVE-2026-105850 HIGH POC
8.8 Oct 06

Duplicate order processing in @payloadcms/plugin-ecommerce allows remote, unauthenticated attackers to have a single Str

CVE-2026-105854 HIGH POC
8.7 Oct 06

Malformed multipart request bodies sent to Payload CMS versions 3.0.0 through 3.89.x and 4.0.0-canary.0 through 4.0.0-ca

CVE-2026-105849 HIGH POC
7.7 Oct 06

API key disclosure in Payload CMS lets an authenticated user with ordinary read access to other users' authentication do

CVE-2026-105855 HIGH POC
7.6 Oct 06

Authenticated users who can update an auth collection document in Payload CMS can change the password field on that docu

CVE-2026-105852 MEDIUM POC
6.9 Oct 06

Payload CMS versions before 3.90.0 and canary versions before 4.0.0-canary.34 contain an authorization bypass in relatio

CVE-2026-105857 CRITICAL
10.0 Oct 06

Unauthorized read access to stored form submissions and form email configuration in Payload CMS deployments running the

CVE-2026-105859 CRITICAL
9.8 Oct 06

Payload CMS releases before 3.90.0 (and canary builds before 4.0.0-canary.34) expose an orderable reorder endpoint that

CVE-2026-25544 CRITICAL POC
9.8 Feb 06

Payload CMS prior to 3.73.0 has a SQL injection vulnerability when querying structured data, enabling database compromis

CVE-2026-105845 CRITICAL POC
9.8 Oct 06

SQL injection in Payload CMS 3.0.0 through before 3.88.0 (and 4.0.0-canary builds before 4.0.0-canary.27) allows remote

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy