Summary
InvoiceShelf contains an authorization flaw in multi-company installations that can let an owner of one company access or modify user accounts belonging to another company. By addressing users through a global identifier without confirming company membership, the issue may enable cross-tenant data disclosure and account takeover.
Affected context
The vulnerability occurs in InvoiceShelf deployments that support multiple companies on the same installation and expose the user management API. Risk is present when authorization checks confirm that the requester owns their current company but do not also verify that the target user belongs to that same company.
Exploit preconditions
- Attack surface: Authenticated user-management API endpoints
- Required access: Ownership-level access to at least one company in a multi-company installation
- Target condition: A user account associated with a different company on the same installation
- Trigger point: User retrieval or update operations addressed by a global user identifier
- Why exploitation is possible: Authorization is evaluated against the requester's company without enforcing ownership or tenancy constraints for the target account
Why this happens
The underlying issue is an object-level authorization failure mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The application resolves a target user by a globally unique primary key, then applies a policy that verifies the requester's company ownership but does not confirm that the target object belongs to that company. This insecure pattern allows a valid identifier to cross a tenant boundary.
Potential impact
- An attacker may read personal or account-related data belonging to users in other companies.
- An attacker could overwrite email or password values and take over another account.
- An attacker may reassign an account to a different company or alter its access context.
- The vulnerability could enable broader cross-tenant compromise if affected accounts have elevated privileges.
General mitigation guidance
Mitigation generally focuses on enforcing object-level and tenant-scoped authorization for every read and write operation.
Common defensive patterns include:
- Resolve and authorize target users within the requester's permitted company scope.
- Require explicit ownership or membership checks for the target object, not only for the requester.
- Avoid trusting globally supplied object identifiers without applying tenant constraints.
- Centralize authorization policies and fail closed when company context is missing or ambiguous.
- Limit account-management privileges according to least-privilege principles.
- Add regression tests covering cross-company reads, updates, and account reassignment attempts.
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis and code review rules that flag direct object lookup by user-controlled identifiers.
- Review of authorization policies for missing target-tenant or object-ownership checks.
- Endpoint tests that attempt access to equivalent object types across company boundaries.
- Runtime monitoring for authenticated users reading or modifying records outside their normal tenant scope.
- Policy enforcement requiring tenant-scoped queries and authorization checks before serialization or mutation.
Automated security review tools may help detect missing object-level authorization, but coverage should be supplemented with multi-tenant integration testing.
