Payload Multi-Tenant EUVD-2026-93510

Requires an authenticated user whose access is limited to one tenant (PR:L), AND at least one tenant-enabled collection must exist in the deployment, AND the installed @payloadcms/plugin-multi-tenant must be before 3.90.0 (or canary before 4.0.0-canary.34). Exploitation is strictly limited to CREATING new records in the foreign tenant - the description explicitly states reads and direct edits of existing documents in the target tenant are NOT bypassed, which meaningfully caps impact to integrity-only data injection. No end-user interaction is required.

This is a genuine but modest-severity authorization flaw (CWE-863), not a high-priority emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) scores 5.3 (medium) and is internally consistent with the description: network-reachable, low complexity, but requiring an authenticated low-privilege account (PR:L) and yielding only limited integrity impact (VI:L) with zero confidentiality or availability impact - consistent with the description noting that reads and direct edits of existing documents are NOT bypassed, only creation of new records in another tenant. No EPSS score, no CISA KEV listing, and no public exploit code were provided in the input, so there is no signal of active or widespread exploitation; absence of these is not evidence of safety but does argue against urgency. The SSVC framework is not supplied. The signals do not conflict: a low-privilege, integrity-only, create-only cross-tenant write in a specific plugin is a real multi-tenancy isolation bug worth patching promptly in affected deployments, but it is not a drop-everything issue. Note the input Tag 'Authentication Bypass' overstates the flaw - this is an authorization/tenant-isolation bypass by an already-authenticated user, not an authentication bypass.

An attacker holds a legitimate account scoped to a single tenant in a multi-tenant Payload deployment that has at least one tenant-enabled collection. They issue a create request targeting a collection while supplying a tenant identifier belonging to a different tenant; the faulty tenant-validation check accepts it, letting them inject a new record into a tenant they should have no write access to. No public proof-of-concept was identified in the input, but the fixing commit is public and reveals the flawed logic, lowering the barrier to reproduction.