CVE-2026-105851: Privilege Escalation via Field Access Control Bypass in Payload CMS Duplication Mechanism

Payload CMS contains a critical privilege escalation vulnerability, designated as CVE-2026-105851, in its document duplication mechanism. When duplicating an existing collection document, the application initializes a document creation pipeline that copies properties from a specified source document to a new one. This behavior exposed an expanded attack surface within authentication-enabled and highly restricted collections.\n\nThe core of the vulnerability lies in the improper registration and exposure of duplication endpoints, coupled with a complete bypass of field-level access controls. An attacker holding low-privilege access can send duplication requests targeting high-privilege documents, such as administrative accounts. The system then populates the new record with sensitive and restricted properties from the target, bypassing standard authorization rules.\n\nThe security impact of this flaw is significant, mapped to CWE-284 (Improper Access Control) and CWE-863 (Incorrect Authorization). It permits authenticated users to execute unauthorized operations, duplicate administrative configurations, and acquire higher privilege contexts without triggering validation checks. The vulnerability affects Payload CMS installations across the 3.x and 4.x canary branches prior to the release of patched versions.

The root cause of CVE-2026-105851 involves two distinct security omissions in the Payload CMS architecture: endpoint exposure and the lack of field-level validation during cloning operations. In a standard deployment, developers use the disableDuplicate flag to restrict document cloning on sensitive collections, particularly those handling authentication. However, in vulnerable versions, this flag failed to inhibit the REST API endpoint /:id/duplicate from registering, allowing clients to send programmatic requests to cloning paths on all collections.\n\nmermaid\ngraph LR\n Attacker["Attacker (Low Privilege)"] -->|"POST /:id/duplicate"| DuplicationEndpoint["Duplication Endpoint (/duplicate)"]\n DuplicationEndpoint -->|"Bypasses disableDuplicate Check"| InternalPipeline["Internal Duplication Pipeline"]\n InternalPipeline -->|"Directly Copies Fields"| SourceDoc["Source Administrator Document (Roles: ['admin'])"]\n SourceDoc -->|"Clones Sensitive Properties"| NewDoc["Created User (Inherits: ['admin'])"]\n\n\nWhen a duplication is triggered, Payload CMS executes an internal creation process powered by createOperation containing a duplicateFromID reference. Instead of passing through a standard sanitization and field-level permission pipeline, the application copied the source document's field values directly into the database insertion payload. This mechanism bypassed the user-level permissions typically enforced during standard create operations.\n\nConsequently, fields marked as hidden or protected by custom access.read or access.create hooks were successfully cloned. Because the field-level access control functions were never invoked against the caller's context during the duplication routine, restricted fields like administrative roles, API tokens, and operational flags were directly duplicated into the newly created account. This enabled privilege escalation by allowing standard users to inherit the capabilities of the duplicated source user.

To mitigate this vulnerability, the developers introduced multiple layers of security validations in commit 099ef12e2682f076aa8e8d0ccb790536b4e1027f to ensure duplication settings are consistently enforced across both REST and programmatic interfaces.\n\nFirst, duplication is now explicitly disabled by default for all authentication-enabled collections within packages/payload/src/collections/config/sanitize.ts:\n\ntypescript\nif (sanitized.auth) {\n // disable duplicate for auth enabled collections by default\n sanitized.disableDuplicate = sanitized.disableDuplicate ?? true\n}\n\n\nSecond, the system ensures that the /duplicate endpoint is omitted during route registration if disableDuplicate is enabled, blocking external access to the REST endpoint:\n\ntypescript\nfor (const endpoint of defaultCollectionEndpoints) {\n if (endpoint !== duplicateEndpoint || sanitized.disableDuplicate !== true) {\n sanitized.endpoints.push(endpoint)\n }\n}\n\n\nThird, programmatic calls are protected inside the core creation operation in packages/payload/src/collections/operations/create.ts:\n\ntypescript\nconst isDuplicating = duplicateFromID !== undefined && duplicateFromID !== null\n\nif (isDuplicating && collectionConfig.disableDuplicate === true) {\n throw new APIError(\n `The collection with slug ${String(collectionConfig.slug)} cannot be duplicated.`,\n 400,\n )\n}\n\n\nFinally, to resolve the field-level bypass, the validation pipeline now enforces granular field checks. In packages/payload/src/fields/hooks/beforeValidate/promise.ts, the application evaluates isDocumentValueAllowed against the caller's active context. If access is unauthorized, the application redirects the value retrieval to a secure default or fallback handler rather than cloning the original document's properties:\n\ntypescript\nif (typeof siblingData[field.name!] === 'undefined' && !req.context?.isRestoringVersion) {\n const isDocumentValueAllowed = operation === 'update' || isAccessAllowed\n\n siblingData[field.name!] =\n !fallbackResult.executed || !isDocumentValueAllowed\n ? await getFallbackValue({ field, isDocumentValueAllowed, req, siblingDoc })\n : fallbackResult.value\n}\n\n\nInside getFallbackValue.ts, the isDocumentValueAllowed flag acts as a gate, ensuring that unauthorized users cannot clone restricted database values during duplication:\n\ntypescript\nif (isDocumentValueAllowed && typeof siblingDoc[field.name] !== 'undefined') {\n fallbackValue = cloneDataFromOriginalDoc(siblingDoc[field.name])\n} else if ('defaultValue' in field && typeof field.defaultValue !== 'undefined') {\n fallbackValue = await getDefaultValue({ ... })\n}\n

Exploitation of CVE-2026-105851 requires that the attacker has authenticated access to the target Payload CMS instance, holding at least standard user privileges. The target collection must expose duplicate capabilities (either because it is not an authentication collection, or because it runs a vulnerable version that fails to enforce the disableDuplicate setting). Additionally, the collection must contain high-privilege configuration fields such as roles or boolean flags that grant operational permissions.\n\nTo perform the exploit, the attacker must identify a target user ID containing the desired privilege context. The attacker then issues a POST request to the duplication endpoint of the target collection, pointing to the target administrative document in the path. In the request body, the attacker supplies their own credentials, such as a modified email address and password:\n\nhttp\nPOST /api/users/64f0a2e31bc2a9001bfa8290/duplicate HTTP/1.1\nHost: target-application.local\nAuthorization: JWT <low-privilege-jwt-token>\nContent-Type: application/json\nConnection: close\n\n{\n "email": "escalated-user@target-domain.com",\n "password": "OperationalPassword123!"\n}\n\n\nUpon receiving the request, the vulnerable server executes the duplication logic. It duplicates all fields of the user 64f0a2e31bc2a9001bfa8290, including the roles: ['admin'] array, because it fails to perform field-level verification against the standard user's session context. The server registers the new user account with administrative roles, allowing the attacker to authenticate using the newly created credentials and achieve complete administrative control over the application.

The technical impact of CVE-2026-105851 is characterized by a complete compromise of the authorization model within affected Payload CMS installations. An authenticated attacker can escalate their privileges from a standard or guest role to a full administrator role. Once administrative access is achieved, the attacker can execute arbitrary read, write, and delete operations across all collections, modify system configurations, and retrieve sensitive application configurations.\n\nThe vulnerability is assigned a CVSS v4.0 score of 9.3, indicating extreme severity. This calculation underscores that the attack vector is network-based, requires low complexity, requires no user interaction, and yields a high impact on integrity. Because authentication collections often map directly to administrative users, bypassing access controls on these documents constitutes a direct path to full infrastructure compromise.\n\nCurrently, there is no evidence of active exploitation in the wild, and CISA has not listed the vulnerability within its Known Exploited Vulnerabilities catalog. However, because the logical flow of the exploit is straightforward, organizations running vulnerable instances must prioritize remediation to prevent the weaponization of proof-of-concept scripts.

The primary remediation for CVE-2026-105851 is upgrading the affected Payload CMS package to a secure version. For deployments built on the 3.x release line, teams must update the dependencies to version 3.90.0 or higher. For projects tracking the 4.x canary branch, the application must be updated to version 4.0.0-canary.34 or higher. These updates ensure that both the REST endpoints and the internal creation operation correctly restrict duplication settings.\n\nIf upgrading is not immediately feasible, organizations must apply immediate configuration-based workarounds. Specifically, administrators must explicitly define disableDuplicate: true inside the schema configuration of all authentication-enabled and high-security collections:\n\ntypescript\nexport const Users: CollectionConfig = {\n slug: 'users',\n auth: true,\n disableDuplicate: true,\n fields: [\n // Field definitions...\n ]\n}\n\n\nAdditionally, developers can restrict sensitive fields manually by implementing custom validation or hooks. For example, registering a beforeChange hook on fields like roles allows developers to verify if the incoming modification is part of a duplication process and actively strip high-privilege parameters when the request context does not authorize them.\n\nAn evaluation of the patch indicates that the fix is robust. By disabling duplication on auth collections by default, removing the endpoint route registration, and executing isDocumentValueAllowed checks during the field fallback sequence, the developers have closed both the network-facing routes and the internal program paths that led to the access bypass.