CVE-2026-86750 in Snipe-IT
Summary
by MITRE • 09/09/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Snipe-IT versions prior to 8.7.0 represents a critical authorization bypass within the REST API implementation for user management operations. Specifically, the Api\UsersController methods store and update fail to enforce proper access control checks before persisting data to the database. This architectural flaw allows attackers with valid authentication credentials but limited privileges to manipulate company assignments in ways that violate tenant isolation boundaries. The core issue lies in the sequence of operations where user record creation or modification occurs immediately upon receiving a request, without first validating whether the actor is authorized to assign specific companies to the target user account.
In environments utilizing Full Multiple Companies Support, which enables multi-tenancy features within Snipe-IT, this flaw has severe implications for data isolation and security boundaries. A non-superuser possessing users.create or users.edit permissions can submit company identifiers that fall outside their permitted scope. The system accepts these identifiers and writes the user record to the database before executing any authorization checks against Company::getIdsForCurrentUser(). This race condition-like behavior, though technically a logical ordering error rather than a timing attack, results in unauthorized data persistence. Even if subsequent filters attempt to correct the assignment by removing foreign company IDs, the initial write operation has already occurred, potentially leaving residual artifacts or triggering side effects associated with record creation that cannot be easily rolled back without database transaction support.
The impact is particularly acute when the configuration setting null_company_is_floater is enabled, which is often set to 1 in many deployments. Under this configuration, if a user account ends up with no valid company associations after post-hoc filtering removes unauthorized IDs, the system persists the record as a floater entity. Floater accounts possess cross-company visibility by design, effectively bypassing tenant isolation mechanisms. This allows an attacker to create new user accounts or relocate existing ones across different organizational tenants without proper authorization. Such actions compromise the confidentiality and integrity of multi-tenant data structures, potentially exposing sensitive asset information, license details, and access logs belonging to other companies within the same Snipe-IT instance.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Escalation due to insufficient authorization checks during resource creation or modification. It also relates closely to CWE-862 Missing Authorization as the system fails to verify user permissions before performing state-changing operations on company associations. In terms of adversary tactics, this flaw facilitates lateral movement within a multi-tenant environment and could be leveraged for privilege escalation by gaining access to resources belonging to other tenants. The ATT&CK framework categorizes such behaviors under techniques involving unauthorized resource access or manipulation of identity management systems, specifically highlighting the risk of abusing API endpoints that lack robust input validation and authorization gating.
Mitigation strategies must prioritize immediate patching to version 8.7.0 or later where this logic has been corrected. Administrators should ensure that all instances are updated promptly given the severity of cross-tenant data exposure risks. For environments unable to upgrade immediately, implementing a Web Application Firewall rule set can help mitigate risk by restricting access to user management API endpoints based on IP reputation or rate limiting, though this is not a substitute for fixing the underlying code flaw. Additionally, reviewing database configurations and application settings related to floater accounts may reduce exposure if null_company_is_floater is disabled, although complete remediation requires addressing the root cause in the controller logic by enforcing authorization checks prior to any database persistence operations.