Summary
A field-level authorization flaw in Payload's MongoDB adapter allows an authenticated user who can update a document to modify fields they are not permitted to change. The issue becomes risky when document updates rely on adapter-side enforcement that does not consistently preserve field-level write access controls.
A field-level authorization flaw in Payload's MongoDB adapter allows an authenticated user who can update a document to modify fields they are not permitted to change. The issue becomes risky when document updates rely on adapter-side enforcement that does not consistently preserve field-level write access controls.
Affected context
The vulnerability affects Payload deployments using the @payloadcms/db-mongodb adapter in affected releases. It requires a user to have legitimate permission to update a document, while field-level write restrictions are expected to prevent changes to particular attributes. The Postgres and SQLite adapters are not affected according to the available vulnerability description.
The vulnerability affects Payload deployments using the @payloadcms/db-mongodb adapter in affected releases. It requires a user to have legitimate permission to update a document, while field-level write restrictions are expected to prevent changes to particular attributes. The Postgres and SQLite adapters are not affected according to the available vulnerability description.
Exploit preconditions
- Attack surface: Authenticated document-update functionality backed by MongoDB - Required access: A valid account with permission to update at least one target document - Trigger point: Processing and persistence of a document update - Why exploitation is possible: The update path may permit changes to fields
whose field-level write access rules should deny modification
- Attack surface: Authenticated document-update functionality backed by MongoDB - Required access: A valid account with permission to update at least one target document - Trigger point: Processing and persistence of a document update - Why exploitation is possible: The update path may permit changes to fields
whose field-level write access rules should deny modification
Why this happens
The underlying bug is an authorization enforcement failure in document updates. The MongoDB adapter does not reliably apply field-level write restrictions when an authorized user submits changes to a document. This behavior maps primarily to CWE-639, authorization bypass through a user-controlled key, and is also related to CWE-915, where dynamically selected object attributes can be modified without adequate control.
The underlying bug is an authorization enforcement failure in document updates. The MongoDB adapter does not reliably apply field-level write restrictions when an authorized user submits changes to a document. This behavior maps primarily to CWE-639, authorization bypass through a user-controlled key, and is also related to CWE-915, where dynamically selected object attributes can be modified without adequate control.
Potential impact
- An authenticated user may modify protected document fields
- Business rules represented by restricted attributes could be bypassed
- Content integrity and workflow state may be altered
- Sensitive or privileged metadata could be changed if exposed to the update path
- Downstream applications may act on unauthorized document values
- An authenticated user may modify protected document fields
- Business rules represented by restricted attributes could be bypassed
- Content integrity and workflow state may be altered
- Sensitive or privileged metadata could be changed if exposed to the update path
- Downstream applications may act on unauthorized document values
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the final update boundary rather than trusting the submitted field set. Common defensive patterns include using deny-by-default field policies, deriving writable fields from the authenticated user's privileges, filtering unauthorized attributes before persistence, and applying the same checks consistently across all update paths. Reducing client control over sensitive fields, validating ownership and tenant boundaries, and running application operations with least privilege can further limit impact.
Mitigation generally focuses on enforcing authorization at the final update boundary rather than trusting the submitted field set. Common defensive patterns include using deny-by-default field policies, deriving writable fields from the authenticated user's privileges, filtering unauthorized attributes before persistence, and applying the same checks consistently across all update paths. Reducing client control over sensitive fields, validating ownership and tenant boundaries, and running application operations with least privilege can further limit impact.
How teams detect issues like this
Detection approaches can include static and dynamic checks for update handlers that merge client-controlled attributes directly into stored documents. Code review should examine whether field-level access decisions are applied after request parsing and before database writes, including bulk and nested update paths. Policy enforcement can require authorization tests for every protected field, with negative cases confirming that users cannot alter restricted attributes. Automated security review tools may help identify unchecked dynamic property assignment and inconsistent adapter behavior.
Detection approaches can include static and dynamic checks for update handlers that merge client-controlled attributes directly into stored documents. Code review should examine whether field-level access decisions are applied after request parsing and before database writes, including bulk and nested update paths. Policy enforcement can require authorization tests for every protected field, with negative cases confirming that users cannot alter restricted attributes. Automated security review tools may help identify unchecked dynamic property assignment and inconsistent adapter behavior.
