CVE-2026-86767 in Snipe-IT
Summary
by MITRE • 09/09/2026
Snipe-IT versions before 8.7.0 fail to apply company scope filtering to the GET /hardware/requested endpoint when Full Multiple Company Support is enabled, allowing authenticated users with assets.view permission to read pending asset requests from all companies. Attackers can retrieve cross-tenant data including requested asset names, requester display names and profile links, locations, and expected check-in dates without parameter manipulation.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Snipe-IT versions prior to 8.7.0 represents a critical failure in multi-tenancy isolation mechanisms within the application's access control logic. Specifically, the GET /hardware/requested endpoint does not correctly enforce company scope filtering when Full Multiple Company Support is enabled. This architectural flaw allows authenticated users who possess only the assets.view permission to bypass intended data segregation boundaries. In a properly secured multi-tenant environment, each tenant or company should be isolated such that users can only access resources and data associated with their specific organizational unit. The failure to apply these filters means that the application treats requests from different companies as if they belong to a single shared context, effectively breaking the logical separation between tenants.
From a technical perspective, this issue stems from an incomplete implementation of authorization checks within the backend API handler for pending asset requests. When Full Multiple Company Support is active, the system should intersect user permissions with company-specific scopes before returning data. However, in affected versions, the scope filtering logic is either skipped or incorrectly evaluated for this specific endpoint. Consequently, any authenticated user can query all pending asset requests across every organization hosted on the instance without needing to manipulate input parameters such as company IDs. The vulnerability relies solely on valid authentication and a low-level permission set, making it particularly dangerous because it does not require complex exploitation techniques or parameter tampering to trigger.
The operational impact of this vulnerability is significant for organizations relying on Snipe-IT for asset management across multiple distinct entities. Attackers can retrieve sensitive cross-tenant data including the names of requested assets, display names and profile links of requesters, physical locations associated with those requests, and expected check-in dates. This exposure facilitates unauthorized access to proprietary information regarding procurement processes and internal operations of other companies sharing the same instance. Furthermore, the disclosure of requester profiles and asset details can aid in social engineering attacks or further reconnaissance efforts against specific individuals within those organizations. The lack of parameter manipulation requirement means that automated scanning tools could easily exploit this flaw at scale across multiple tenants simultaneously.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting a failure to enforce proper authorization checks for cross-tenant data access. It also maps to MITRE ATT&CK technique T1530 Data from Cloud Storage Object or Internal Remote Service Discovery if viewed through the lens of enumerating internal resources, though more accurately it represents an unauthorized information disclosure due to broken object level permissions in a multi-tenant architecture. The core issue is that the application fails to verify that the requesting user has explicit permission to view data belonging to other companies, violating the principle of least privilege and strict tenant isolation required for secure SaaS or shared infrastructure deployments.
To mitigate this vulnerability, organizations running Snipe-IT must immediately upgrade to version 8.7.0 or later where these scope filtering mechanisms have been corrected. Until an upgrade is feasible, administrators should consider restricting access to the affected endpoint if possible through reverse proxy rules or WAF configurations that limit who can call GET /hardware/requested. Additionally, reviewing user permissions to ensure that only necessary personnel hold assets.view rights can reduce the blast radius of this flaw. It is also advisable to audit logs for any unusual patterns of data retrieval from this endpoint prior to patching, as attackers may have already exploited this weakness to exfiltrate sensitive cross-tenant information. Regular security assessments and penetration testing focused on multi-tenancy isolation are recommended to detect similar architectural flaws in other endpoints within the application.