Description

Snipe-IT versions <= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested company_id / company_ids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where null_company_is_floater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a "floater" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-09T14:17:24.030Z",
  "pubdate": "2026-09-09T14:17:24.030Z",
  "executiveSummary": "This vulnerability is an Improper Authorization flaw within Snipe-IT versions <= 8.6.3, specifically affecting deployments utilizing Full Multiple Companies Support (FMCS).\nThe issue stems from insufficient input validation during user persistence operations within the REST API. An attacker with standard administrative permissions, such as users.create or users.edit, can bypass organizational boundaries to assign or relocate user accounts to companies outside their authorized scope.\nThis allows for cross-tenant data exposure and unauthorized modification of account associations.\nThe vulnerability requires authenticated access with specific user management privileges. By manipulating the API request to include unauthorized company identifiers, a malicious actor can compromise the multi-tenancy isolation model of the application.\nThe impact includes the potential for unauthorized privilege escalation via cross-company user movement and systemic erosion of organizational segmentation.",
  "technicalDetails": "The vulnerability resides in the Api\\UsersController::store() and Api\\UsersController::update() methods. The root cause is a race condition in logic where the user record is persisted to the database before the application verifies the authorization of the requested company_id or company_ids[] parameters against the current actor's permitted companies.\nIn environments where Full Multiple Companies Support (FMCS) is enabled, the system relies on Company::getIdsForCurrentUser() to enforce isolation. However, the controller performs the database save operation using the request data before this filter is applied.\nThe attack flow begins when an attacker, possessing users.create or users.edit permissions, crafts a REST API request containing company identifiers associated with restricted entities. When the application processes the store or update call, the record is initially persisted with the unauthorized company attributes.\nIf the instance configuration includes null_company_is_floater=1, the post-hoc validation logic results in an empty company pivot if the unauthorized IDs are stripped. This causes the account to be persisted as a 'floater,' effectively stripping the account of its company assignment and granting it visibility across all tenant boundaries.\nThis behavior facilitates the 'sideways' movement of user accounts, allowing an attacker to move users between distinct tenants or create accounts that exist outside the intended security perimeter. Because the record is written to the database prior to the authorization check, the security boundary is effectively bypassed.\nThe flaw affects all Snipe-IT installations running versions 8.6.3 and earlier. Successful exploitation requires an authenticated session with sufficient privileges to modify user records, making this an authorization bypass vulnerability rather than an unauthenticated entry point. Post-exploitation impact includes the loss of multi-tenant integrity and unauthorized access to assets or information restricted by company-based partitioning."
}