CVE-2026-85616 in Snipe-IT
Summary
by MITRE • 09/04/2026
Snipe-IT versions before 8.6.2 contain an authorization bypass vulnerability in checkout-acceptance report actions when Full Multiple Company Support is enabled. Authenticated users with reports.view permission can enumerate sequential acceptance IDs and soft-delete or trigger reminder emails for acceptances belonging to other companies by exploiting a null check on the legacy users.company_id column.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in Snipe-IT versions prior to 8.6.2 represents a critical authorization bypass within the asset checkout management subsystem, specifically affecting operations related to acceptance reports when multi-company support is enabled. This flaw allows authenticated users who possess only the basic reports.view permission to perform actions that should be restricted to administrators or specific company-level managers. The core of the issue lies in how the application handles data isolation between distinct organizational entities within a single installation. When Full Multiple Company Support is active, Snipe-IT relies on legacy database structures where user associations are stored in a column named users.company_id. This architectural choice creates an opportunity for attackers to manipulate request parameters to bypass intended access controls.
The technical mechanism of the exploit involves the manipulation of sequential acceptance identifiers during checkout-acceptance report actions. The application fails to perform adequate validation checks on these identifiers against the current user's authorized company scope before processing requests. Specifically, there is a null check deficiency regarding the legacy users.company_id column that should enforce strict boundary enforcement between companies. By enumerating sequential IDs for asset acceptances belonging to other organizations within the same Snipe-IT instance, an attacker can craft malicious HTTP requests targeting these specific acceptance records. Because the backend logic does not sufficiently verify that the requesting user has explicit permission over the target company's data, the system processes actions intended for higher privileges or different organizational units.
The operational impact of this vulnerability is severe due to its potential for both information disclosure and denial of service through unauthorized state changes. An attacker can enumerate valid acceptance IDs across multiple companies by iterating through sequential numerical values, effectively mapping out asset distribution records that should remain confidential within their respective organizations. Beyond mere enumeration, the vulnerability permits two distinct malicious actions: soft-deleting acceptance records or triggering reminder emails for checkout acceptances belonging to other companies. Soft deletion of these records can disrupt audit trails and compliance reporting mechanisms essential for IT asset management integrity. Furthermore, sending unauthorized reminder emails constitutes a form of abuse that can lead to operational disruption, spamming recipients with irrelevant notifications, and potentially exposing sensitive contact information associated with those acceptance records.
This vulnerability aligns closely with CWE-284 Improper Access Control, as it involves the failure to enforce proper restrictions on authorized users accessing resources belonging to other entities within a multi-tenant environment. It also reflects aspects of CWE-639 Authorization Bypass Through User-Controlled Key, where sequential identifiers are used without sufficient validation against user context. From an offensive security perspective, this behavior maps to ATT&CK techniques related to Account Enumeration and Data Staged or Exfiltration via Application Layer Protocol, as the attacker leverages legitimate application functions to gather intelligence and manipulate data states outside of their designated scope. The reliance on legacy database columns for company isolation highlights a technical debt issue where older architectural patterns have not been fully secured against modern multi-tenant security requirements.
Mitigation strategies must prioritize immediate upgrading to Snipe-IT version 8.6.2 or later, which addresses the null check deficiency and enforces stricter authorization checks during checkout-acceptance report actions. For organizations unable to upgrade immediately due to compatibility constraints, implementing a Web Application Firewall rule set that monitors for anomalous patterns in acceptance ID enumeration may provide partial protection by detecting rapid sequential requests targeting different company records. Additionally, auditing user permissions is crucial; administrators should ensure that the reports.view permission is granted only to users who genuinely require access to cross-company reporting data, thereby reducing the attack surface available to potential exploiters. Regular security assessments focusing on multi-tenant isolation integrity are recommended to identify similar flaws in other modules where legacy database structures might still influence authorization logic.