Summary
SuiteCRM's relationship API can update a target record's foreign key after checking view and list permissions, without requiring edit permission. An authenticated low-privileged user who can reach the endpoint may reassign records or change security-relevant relationships they should not be able to modify.
SuiteCRM's relationship API can update a target record's foreign key after checking view and list permissions, without requiring edit permission. An authenticated low-privileged user who can reach the endpoint may reassign records or change security-relevant relationships they should not be able to modify.
Affected context
The issue occurs in the SuiteCRM API endpoint for creating relationships between modules: POST /Api/V8/module/{moduleName}/{id}/relationships/{linkFieldName}. It is relevant when a one-to-many relationship write changes a target record's foreign key, but the authorization check verifies only view and list permissions rather than the edit permission needed for that write.
The issue occurs in the SuiteCRM API endpoint for creating relationships between modules: POST /Api/V8/module/{moduleName}/{id}/relationships/{linkFieldName}. It is relevant when a one-to-many relationship write changes a target record's foreign key, but the authorization check verifies only view and list permissions rather than the edit permission needed for that write.
Exploit preconditions
- Attack surface: The SuiteCRM V8 relationship API endpoint
- Required access: An authenticated account with low privileges and sufficient view/list access for the relevant records or relationship
- Trigger point: A one-to-many relationship request that writes a target record's foreign key
- Why exploitation is possible: The endpoint does not enforce the required edit permission before changing the relationship
- Attack surface: The SuiteCRM V8 relationship API endpoint
- Required access: An authenticated account with low privileges and sufficient view/list access for the relevant records or relationship
- Trigger point: A one-to-many relationship request that writes a target record's foreign key
- Why exploitation is possible: The endpoint does not enforce the required edit permission before changing the relationship
Why this happens
The endpoint performs a sensitive record modification without checking the authorization required for that operation. This is an authorization enforcement failure mapped to CWE-862: Missing Authorization: permissions to view or list records are treated as sufficient for a write that requires edit access.
The endpoint performs a sensitive record modification without checking the authorization required for that operation. This is an authorization enforcement failure mapped to CWE-862: Missing Authorization: permissions to view or list records are treated as sufficient for a write that requires edit access.
Potential impact
- A user may reassign records without the required edit permission
- Ownership or other security-relevant relationships could be altered
- Cross-user access may expand if relationship changes affect record visibility
- Workflows or business processes could be manipulated through unauthorized relationship changes
- A user may reassign records without the required edit permission
- Ownership or other security-relevant relationships could be altered
- Cross-user access may expand if relationship changes affect record visibility
- Workflows or business processes could be manipulated through unauthorized relationship changes
General mitigation guidance
Defensive patterns focus on matching authorization checks to the exact operation being performed.
- Require edit permission for every relationship write that modifies a target record
- Enforce authorization on the server for both the source and target records
- Apply object-level access checks consistently across API routes and relationship types
- Prefer deny-by-default policies and avoid treating read permissions as sufficient for writes
- Limit account privileges and review how relationship changes affect ownership and visibility
Defensive patterns focus on matching authorization checks to the exact operation being performed.
- Require edit permission for every relationship write that modifies a target record
- Enforce authorization on the server for both the source and target records
- Apply object-level access checks consistently across API routes and relationship types
- Prefer deny-by-default policies and avoid treating read permissions as sufficient for writes
- Limit account privileges and review how relationship changes affect ownership and visibility
How teams detect issues like this
- Review API handlers for write operations that rely only on view or list permission checks
- Use static analysis and code review rules to flag database or ORM writes without a corresponding authorization check
- Test relationship endpoints with accounts that have read access but lack edit access
- Enforce centralized authorization policies and add regression tests for source and target record permissions
- Automated code review tools can help identify permission checks that do not match the operation's sensitivity
- Review API handlers for write operations that rely only on view or list permission checks
- Use static analysis and code review rules to flag database or ORM writes without a corresponding authorization check
- Test relationship endpoints with accounts that have read access but lack edit access
- Enforce centralized authorization policies and add regression tests for source and target record permissions
- Automated code review tools can help identify permission checks that do not match the operation's sensitivity
