CVE-2026-105849: Sensitive Data Exposure and Privilege Escalation in Payload CMS API Key Authentication

The affected component is Payload's default API key authentication mechanism. When a collection configuration enables useAPIKey, the CMS generates default authentication fields, specifically apiKey. In vulnerable versions, Payload fails to enforce adequate field-level read-authorization controls or default masking on this generated apiKey field.

Consequently, any user with ordinary read access to other authentication documents in that collection can retrieve active, unmasked API keys for other users.

This exposes a substantial attack surface, as low-privilege users can query the /api/users endpoint or custom authentication collections and retrieve active keys of higher-privilege administrative accounts. The bug falls under CWE-201 (Insertion of Sensitive Information Into Sent Data) and CWE-862 (Missing Authorization).

In Payload CMS, collections configured with authentication support can generate API keys to allow external integrations or API clients to execute operations. Setting useAPIKey to true dynamically inserts default fields into the collection schema, including enableAPIKey and apiKey.

The root cause of the vulnerability lies in the lack of read-level restrictions in the default field definition of apiKey under packages/payload/src/auth/baseFields/apiKey.ts. The default apiKey field definition did not implement explicit field-level access control, such as access.read = () => false. Consequently, the field inherited the read permissions of the parent document.

Furthermore, the field definition integrated an afterRead hook that mapped to decryptKey. Whenever a read operation was executed on a document within the collection, the database engine returned the ciphertext, the hook automatically decrypted it using the primary payload secret, and the plaintext API key was rendered directly in the output JSON.

An examination of the patch in commit 880d2e900be22cd66a9e939f2b3e702fa413180f reveals the structural remediation of this design flaw. The developer replaced the implicit read inheritance with a hard block on standard read operations. The access.read attribute is now explicitly defined as () => false for the apiKey field.

The patch also eliminates the automated decryption process during standard reads. The decryptKey hook was completely removed, replaced by the omitEncryptedAPIKey hook within afterRead, which guarantees that the raw or encrypted key cannot be leaked even if database extraction occurs. A new dedicated and secured reveal endpoint (/:id/api-key/reveal) was introduced, implementing granular verification checks that demand admin panel access capabilities alongside read and write permissions on the targeted document.

Exploitation requires that the attacker has authenticated credentials with standard read permissions to the user collection. In a standard multi-tenant or multi-user configuration, standard users or content authors might have permissions to view other profiles, or a lax API configuration might permit broad read access to the /api/users endpoint.

The attacker queries the endpoint using standard HTTP REST or GraphQL operations. Because the apiKey field is decrypted on read, the server returns the plaintext API keys in the response payload.

The attacker extracts the active API key of an administrative user and places it in the Authorization header of subsequent requests. Since the API key authentication middleware identifies the key and maps it to the target user context, the attacker assumes the full permissions of the administrative account, achieving complete privilege escalation.

An attacker who exploits this vulnerability gains full, unauthenticated administrative access over the affected CMS instance. Because API keys bypass multi-factor authentication and standard login logging protocols, the attacker's activities may remain undetected within standard authentication monitoring channels.

The vulnerability carries a CVSS v4.0 base score of 7.7, reflecting high confidentiality, integrity, and availability impacts within the local CMS instance. While the vulnerability is restricted to the Payload CMS application layer, administrative compromise allows complete data exfiltration, database tampering, and arbitrary execution of any integrated headless processes.

The primary remediation strategy is upgrading the Payload installation to version 3.90.0 or higher, or 4.0.0-canary.34 or higher. These releases implement the hardened field configuration and secure disclosure endpoints.

If upgrading is not immediately possible, security teams should implement immediate manual overrides. This includes modifying collection definitions to explicitly set the access.read constraint of the apiKey field to () => false.

Additionally, read permissions on user collections must be locked down using granular access rules so that non-administrative users can only read their own documents. Finally, any potentially exposed API keys must be immediately rotated to invalidate cached sessions.