Summary
SuiteCRM's V8 JSON:API update flow can allow an authenticated user to change a record identifier supplied during an update. If the owner-only authorization check relies on that user-controlled identifier or related authorization state, the user may bypass the check and modify another person's record, including its ownership.
SuiteCRM's V8 JSON:API update flow can allow an authenticated user to change a record identifier supplied during an update. If the owner-only authorization check relies on that user-controlled identifier or related authorization state, the user may bypass the check and modify another person's record, including its ownership.
Affected context
The issue occurs in SuiteCRM's V8 JSON:API record-update path, where updateRecord() processes user-supplied attributes through processAttributes() before assigning them to a SugarBean. The flow fails to remove the id attribute before assignment, which can affect identifier handling and owner-only authorization. SuiteCRM releases before 7.15.2 and 8.10.2 are described as affected.
The issue occurs in SuiteCRM's V8 JSON:API record-update path, where updateRecord() processes user-supplied attributes through processAttributes() before assigning them to a SugarBean. The flow fails to remove the id attribute before assignment, which can affect identifier handling and owner-only authorization. SuiteCRM releases before 7.15.2 and 8.10.2 are described as affected.
Exploit preconditions
- Attack surface: The V8 JSON:API record-update endpoint
- Required access: An authenticated account able to invoke the update operation
- Trigger point: Processing user-supplied attributes during a record update
- Why exploitation is possible: The
idattribute is not removed before assignment, allowing attacker-controlled record identification or authorization state to influence an owner-only access check
- Attack surface: The V8 JSON:API record-update endpoint
- Required access: An authenticated account able to invoke the update operation
- Trigger point: Processing user-supplied attributes during a record update
- Why exploitation is possible: The
idattribute is not removed before assignment, allowing attacker-controlled record identification or authorization state to influence an owner-only access check
Why this happens
The update path treats a user-supplied record identifier as trusted while assigning attributes and performing authorization-sensitive operations. This is an insecure direct object reference and authorization-by-user-controlled-key pattern associated with CWE-639: Authorization Bypass Through User-Controlled Key. The underlying weakness is failing to keep the target record identity and authorization decision bound to trusted, server-side state.
The update path treats a user-supplied record identifier as trusted while assigning attributes and performing authorization-sensitive operations. This is an insecure direct object reference and authorization-by-user-controlled-key pattern associated with CWE-639: Authorization Bypass Through User-Controlled Key. The underlying weakness is failing to keep the target record identity and authorization decision bound to trusted, server-side state.
Potential impact
- An authenticated user may modify records they do not own
- Record ownership may be hijacked
- Unauthorized changes could affect the integrity of CRM data
- Changes to sensitive records could disrupt business workflows
- An authenticated user may modify records they do not own
- Record ownership may be hijacked
- Unauthorized changes could affect the integrity of CRM data
- Changes to sensitive records could disrupt business workflows
General mitigation guidance
Mitigations generally focus on keeping record identity and authorization decisions under server-side control.
- Exclude immutable identifiers such as record IDs from mass-assignment and attribute-processing paths
- Resolve the target record using trusted request context, then authorize actions against that specific record
- Enforce object-level access controls for every update, including owner-only restrictions
- Use explicit allowlists for writable fields and reject unexpected security-sensitive attributes
- Apply least privilege to user roles and limit access to update operations where appropriate
Mitigations generally focus on keeping record identity and authorization decisions under server-side control.
- Exclude immutable identifiers such as record IDs from mass-assignment and attribute-processing paths
- Resolve the target record using trusted request context, then authorize actions against that specific record
- Enforce object-level access controls for every update, including owner-only restrictions
- Use explicit allowlists for writable fields and reject unexpected security-sensitive attributes
- Apply least privilege to user roles and limit access to update operations where appropriate
How teams detect issues like this
- Use static analysis to flag mass assignment of request attributes to model or bean objects, especially where identifiers or authorization fields are included
- Review update flows for differences between the record used in authorization checks and the record ultimately modified
- Test object-level authorization policies with users attempting to update records they do not own
- Enforce API schemas and field allowlists that prohibit client-supplied changes to identifiers and ownership or authorization state
- Use automated code review tools as a supplementary way to identify risky attribute-assignment patterns
- Use static analysis to flag mass assignment of request attributes to model or bean objects, especially where identifiers or authorization fields are included
- Review update flows for differences between the record used in authorization checks and the record ultimately modified
- Test object-level authorization policies with users attempting to update records they do not own
- Enforce API schemas and field allowlists that prohibit client-supplied changes to identifiers and ownership or authorization state
- Use automated code review tools as a supplementary way to identify risky attribute-assignment patterns
