Description

Snipe-IT through 8.6.4 (fixed in 8.7.0) does not enforce the components.view permission on the authenticated endpoint GET /api/v1/hardware/<asset-id>/assigned/components. The endpoint authorizes only assets.view on the parent asset before returning linked component details; the components.view check is applied only to the response's available_actions.view flag and not to the returned data. As a result, an authenticated user holding only assets.view can enumerate component IDs, names, assigned quantities, and notes that are otherwise protected — the direct GET /api/v1/components/<id> endpoint correctly returns 403 Forbidden for such users.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-09T14:17:26.597Z",
  "pubdate": "2026-09-09T14:17:26.597Z",
  "executiveSummary": "This vulnerability is an improper access control flaw within the Snipe-IT asset management system, specifically affecting the API endpoint responsible for retrieving components assigned to hardware assets.\nThe vulnerability allows an authenticated user with limited 'assets.view' privileges to bypass mandatory 'components.view' authorization checks when querying the /api/v1/hardware/<asset-id>/assigned/components endpoint.\nBy exploiting this flaw, an attacker can enumerate sensitive information regarding components, including component identifiers, names, assigned quantities, and internal notes, which are otherwise restricted based on the user's assigned role and permissions.\nThe primary risk lies in unauthorized information disclosure and the potential for an attacker to gain internal reconnaissance data about organizational inventory without possessing the requisite administrative or component-level viewing privileges.\nThe vulnerability exists in all versions of Snipe-IT up to and including 8.6.4. While the application correctly enforces access controls on the direct component lookup endpoint, the nested hardware component relationship endpoint fails to implement the same security logic.",
  "technicalDetails": "The root cause of this vulnerability is a flaw in the authorization logic governing the /api/v1/hardware/<asset-id>/assigned/components API endpoint. In the Snipe-IT application, the authorization framework is designed to enforce granular permissions based on specific resources. However, when requesting a list of components assigned to a specific hardware asset, the application performs an authorization check only against the parent asset's 'assets.view' permission.\nWhile the application correctly restricts direct access to specific component data via the /api/v1/components/<id> endpoint—returning a 403 Forbidden status for users lacking 'components.view'—it fails to extend this restriction to the hardware-nested component endpoint. Although the application attempts to filter the 'available_actions.view' flag in the response based on the 'components.view' permission, it inadvertently returns the actual underlying component data, including IDs, names, quantities, and private notes, regardless of whether the authenticated user has explicit permission to view components.\nAn attacker can exploit this by authenticating as a standard user with 'assets.view' access. Once authenticated, the attacker sends a GET request to the vulnerable endpoint: /api/v1/hardware/<asset-id>/assigned/components. Because the backend code validates the user's relationship to the hardware asset but fails to perform an independent authorization check on the individual component objects being fetched, the server serializes the full component metadata to the response body.\nThis behavior results in an authorization bypass where the confidentiality of component data is compromised. The attack flow is straightforward: 1) Authenticate with a low-privileged account possessing 'assets.view'. 2) Enumerate valid hardware asset IDs. 3) Query the hardware-assigned components endpoint for each asset ID. 4) Extract restricted component details from the JSON response. This provides the attacker with a means to map out the organization's inventory infrastructure, potentially identifying hardware setups or sensitive notes attached to components that the user is not authorized to interact with or view."
}