Summary
Crater customer records are not consistently restricted to the authenticated user's company, allowing an authorized user from one company to access customer data belonging to another. Depending on granted abilities, this may permit cross-company disclosure, reassignment, or deletion, including cascading removal of related invoices and payments.
Affected context
The vulnerability occurs in Crater's customer authorization and lookup paths when company ownership is not included in authorization decisions or database queries. Customer policy methods check a broad Bouncer ability but omit the model's company relationship, while route-model binding and bulk deletion may retrieve records by identifier without restricting results to the active company.
Exploit preconditions
- Attack surface: Customer views, updates, deletes, route-model-bound customer operations, and bulk deletion functionality
- Required access: An authenticated Crater user with the relevant customer ability in one company
- Trigger point: Access to a customer record or operation identified without a company-scoped lookup
- Why exploitation is possible: Authorization relies on a blanket ability check, and customer retrieval does not consistently verify that the target belongs to the user's company
Why this happens
The underlying bug is an object-level authorization failure caused by separating permission checks from tenant ownership checks. Customer operations validate whether a user has a general ability but do not also require ownership of the target model through its company relationship. Unscoped identifier-based queries create the same weakness by allowing records from other companies to be selected. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, commonly associated with insecure direct object references and broken tenant isolation.
Potential impact
- Customer information may be disclosed across company boundaries
- Customer records could be reassigned to another company or otherwise modified
- Unauthorized users may delete another company's customer records
- Related invoices and payments may be deleted through cascading behavior
- Tenant confidentiality, integrity, and availability may be compromised
General mitigation guidance
Mitigation generally focuses on making tenant ownership a mandatory part of every customer authorization and retrieval path.
Common defensive patterns include:
- Combining ability checks with an explicit company-ownership check
- Applying company-scoped query constraints before route binding or record operations
- Reusing centralized tenant-aware authorization and repository patterns
- Ensuring bulk operations enforce the same per-record ownership rules as individual operations
- Restricting destructive actions through least-privilege permissions and appropriate administrative separation
- Treating identifiers supplied by clients as untrusted references rather than proof of access
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis rules for unscoped find, route binding, and bulk-delete queries in multi-tenant code
- Code review checks requiring tenant predicates on authorization and data-access paths
- Tests that attempt cross-company reads, updates, reassignment, and deletion using valid user abilities
- Policy checks that verify both action permission and model ownership
- Runtime monitoring for access to objects outside the authenticated user's company
- Automated security review tools that flag direct object references without tenant constraints
