Summary
Krayin CRM contains a broken object level authorization flaw in EmailController write actions, allowing an authenticated but scope-restricted user to operate on emails belonging to other users by supplying numeric identifiers. Depending on the endpoint and parameters used, an attacker may modify, resend, move to trash, permanently delete, or disclose email-related data.
Krayin CRM contains a broken object level authorization flaw in EmailController write actions, allowing an authenticated but scope-restricted user to operate on emails belonging to other users by supplying numeric identifiers. Depending on the endpoint and parameters used, an attacker may modify, resend, move to trash, permanently delete, or disclose email-related data.
Affected context
The issue occurs in Krayin CRM deployments where authenticated users can reach EmailController update, destroy, mass-update, or mass-destroy actions and email records are selected directly by user-supplied numeric IDs. Risk is higher when authorization checks validate the user's general ability to use an action but do not confirm ownership or scope access for each referenced email and its related lead or person data.
The issue occurs in Krayin CRM deployments where authenticated users can reach EmailController update, destroy, mass-update, or mass-destroy actions and email records are selected directly by user-supplied numeric IDs. Risk is higher when authorization checks validate the user's general ability to use an action but do not confirm ownership or scope access for each referenced email and its related lead or person data.
Exploit preconditions
- Attack surface: Authenticated EmailController write endpoints
- Required access: A valid account with access to the affected CRM functions; elevated administrative privileges may not be necessary
- Trigger point: Supplying identifiers for email records to update, resend, trash, or delete operations
- Why exploitation is possible: Object-level authorization is insufficient or missing after the application resolves records by numeric ID, allowing cross-user email actions and related-data disclosure
- Attack surface: Authenticated EmailController write endpoints
- Required access: A valid account with access to the affected CRM functions; elevated administrative privileges may not be necessary
- Trigger point: Supplying identifiers for email records to update, resend, trash, or delete operations
- Why exploitation is possible: Object-level authorization is insufficient or missing after the application resolves records by numeric ID, allowing cross-user email actions and related-data disclosure
Why this happens
The underlying bug is a failure to enforce authorization at the individual object level. EmailController actions appear to rely on a caller's broader action permission or on the supplied record identifier without consistently verifying that the requested email belongs to the caller's permitted scope. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, a weakness in which user-controlled object references can access records outside the intended authorization boundary.
The underlying bug is a failure to enforce authorization at the individual object level. EmailController actions appear to rely on a caller's broader action permission or on the supplied record identifier without consistently verifying that the requested email belongs to the caller's permitted scope. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, a weakness in which user-controlled object references can access records outside the intended authorization boundary.
Potential impact
- An attacker may modify emails belonging to other users
- Email messages may be resent or otherwise triggered through unauthorized actions
- Attackers could move messages to trash or permanently delete them
- Email subjects, bodies, and linked lead or person data may be disclosed
- CRM records and communication workflows could be disrupted
- An attacker may modify emails belonging to other users
- Email messages may be resent or otherwise triggered through unauthorized actions
- Attackers could move messages to trash or permanently delete them
- Email subjects, bodies, and linked lead or person data may be disclosed
- CRM records and communication workflows could be disrupted
General mitigation guidance
Mitigation generally focuses on enforcing object-level authorization consistently for every email operation.
Common defensive patterns include:
- Authorizing each referenced email against the authenticated user's tenant, role, ownership, and permitted scope
- Applying the same authorization checks to single-record and bulk operations
- Avoiding direct trust in numeric identifiers supplied by clients
- Restricting query results to authorized objects before updates, deletes, or disclosure
- Separating sensitive actions such as resend and permanent deletion behind explicit, least-privilege permissions
- Returning uniform responses that do not reveal whether unauthorized object identifiers exist
Mitigation generally focuses on enforcing object-level authorization consistently for every email operation.
Common defensive patterns include:
- Authorizing each referenced email against the authenticated user's tenant, role, ownership, and permitted scope
- Applying the same authorization checks to single-record and bulk operations
- Avoiding direct trust in numeric identifiers supplied by clients
- Restricting query results to authorized objects before updates, deletes, or disclosure
- Separating sensitive actions such as resend and permanent deletion behind explicit, least-privilege permissions
- Returning uniform responses that do not reveal whether unauthorized object identifiers exist
How teams detect issues like this
Organizations commonly detect this class of issue through:
- Static analysis and code review checks for record lookups based directly on request parameters
- Review of controller actions for missing ownership, tenant, role, or scope predicates
- Tests that exercise object identifiers belonging to other users and authorization scopes
- API policy checks requiring object-level authorization for read, update, and delete operations
- Monitoring for repeated cross-scope identifier access, bulk mutations, unexpected resend activity, and deletion attempts
Automated application security testing can help identify inconsistent authorization across single-object and bulk endpoints.
Organizations commonly detect this class of issue through:
- Static analysis and code review checks for record lookups based directly on request parameters
- Review of controller actions for missing ownership, tenant, role, or scope predicates
- Tests that exercise object identifiers belonging to other users and authorization scopes
- API policy checks requiring object-level authorization for read, update, and delete operations
- Monitoring for repeated cross-scope identifier access, bulk mutations, unexpected resend activity, and deletion attempts
Automated application security testing can help identify inconsistent authorization across single-object and bulk endpoints.
