Summary
A broken access-control vulnerability in Snipe-IT allows a company-scoped user operating in FMCS floater mode to access users whose company association is null. Depending on the endpoint and action, this may expose personal data and licenses or permit unauthorized profile changes, user merges, soft deletion, and asset transfers.
Affected context
The issue occurs in Snipe-IT deployments using FMCS floater mode when company-scoped access controls are not applied consistently across broad API queries and bulk web actions. Relevant operations include user and license retrieval, bulk profile editing, and user merging, particularly where records have a null company_id or fall outside the requesting user's company scope.
Exploit preconditions
- Attack surface: Snipe-IT user-management APIs and web actions
- Required access: An authenticated company-scoped user account operating in FMCS floater mode
- Trigger points: User listing, user-license retrieval, bulk profile editing, or user-merge operations
- Why exploitation is possible: Some queries and actions do not consistently enforce the
isCurrentUserHasAccessauthorization decision, allowing out-of-scope records to be read or modified
Why this happens
The underlying flaw is inconsistent authorization enforcement across related code paths. Broad queries and bulk operations can process user records without applying the same company-scope checks used by other requests, allowing a user to interact with records that should be outside their authorization boundary. This behavior maps to CWE-863: Incorrect Authorization, where access-control decisions are missing, incomplete, or applied inconsistently.
Potential impact
- Personal information and user records may be disclosed
- Assigned license information may be exposed
- Out-of-scope user profiles may be modified
- User accounts may be soft-deleted through unauthorized merges
- Assigned assets may be transferred to unintended users
- Organizational data integrity and auditability may be reduced
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every data-access and state-changing boundary.
Common defensive patterns include:
- Applying centralized, deny-by-default company-scope checks to API queries and web actions
- Reusing the same authorization policy for individual, bulk, and merge operations
- Treating null or missing ownership attributes as requiring explicit authorization rather than as broadly accessible
- Limiting bulk actions to records independently verified as in scope
- Requiring elevated privileges for user merges, soft deletion, and asset transfers
- Returning only fields and records permitted by the caller's effective scope
- Recording and reviewing sensitive administrative actions
How teams detect issues like this
Organizations can look for authorization inconsistencies through:
- Static analysis and code review checks for database queries or bulk handlers that omit centralized access predicates
- Review signals involving direct use of request-controlled identifiers without an authorization decision
- Tests covering null ownership fields, cross-company records, bulk operations, and merge workflows
- Policy enforcement requiring authorization checks before both reads and state-changing operations
- Monitoring for unusual user-listing, license-access, bulk-edit, merge, deletion, or asset-transfer activity
- Automated security testing that compares permissions across equivalent API and web workflows
