Payload CMS EUVD-2026-93513

Exploitation requires ALL of: (1) an authenticated user account (PR:L); (2) @payloadcms/storage-s3 before 3.90.0 (or canary before 4.0.0-canary.34); (3) client uploads enabled (clientUploads: true) for multiple upload collections; (4) those collections sharing the same S3 bucket; and (5) useCompositePrefixes set to false or left unset. Under these conditions the attacker can request a signed URL and overwrite an existing object owned by a different collection, bypassing that collection's access controls and prior file validation. Limiting factors: it is NOT remote-unauthenticated (a valid session is needed), and deployments not using S3 client uploads with a shared bucket, or those with useCompositePrefixes enabled, are not affected.

This is a genuine but moderate-priority, access-control integrity flaw rather than a critical remote-code issue. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L) scores 7.1 (High): network-reachable, low complexity, but requiring low-level privileges (PR:L) - i.e. an authenticated user - and delivering high integrity impact (object overwrite) with low availability impact and NO confidentiality impact. This aligns with CWE-639 (authorization bypass via user-controlled key / IDOR). No EPSS score, no CISA KEV listing, and no public exploit code are present in the input, so exploitation status is: no public exploit identified at time of analysis. The absence of KEV/EPSS data combined with the authenticated-only, config-dependent nature strongly suggests this is not a mass-exploitation candidate. The main caveat is that exploitation is gated behind a specific, non-default-ish configuration (clientUploads enabled across multiple collections sharing one bucket with useCompositePrefixes false/unset), which materially narrows the exposed population below what the raw 7.1 implies. Prioritize patching for Payload deployments that use the S3 client-upload feature; deprioritize for those not using shared-bucket client uploads.

In a Payload instance where multiple upload collections share one S3 bucket with client uploads enabled and useCompositePrefixes off, an authenticated low-privilege user requests a signed upload URL for a filename matching an object in another collection, then PUTs their own content to overwrite the victim object - bypassing that collection's access controls and file validation. No public exploit code is identified; the attack requires only a valid authenticated session and knowledge/guessing of a target key.