Description

Snipe-IT versions before 8.7.0 fail to enforce checkout authorization when assignment fields are submitted to the asset update endpoint. Authenticated users with edit permission but explicitly denied checkout permission can reassign assets, bypass check-in procedures, and alter custody records by submitting assigned_user, assigned_asset, or assigned_location parameters to PATCH /api/v1/hardware/{id}.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-09T14:17:26.780Z",
  "pubdate": "2026-09-09T14:17:26.780Z",
  "executiveSummary": "A broken access control vulnerability exists in Snipe-IT versions prior to 8.7.0, specifically within the hardware asset update API.\nThe vulnerability allows authenticated users with standard edit permissions to bypass explicit checkout authorization restrictions.\nBy manipulating specific assignment parameters during a PATCH request to the hardware endpoint, an attacker can reassign assets, circumvent mandatory check-in/check-out procedures, and manipulate organizational custody records.\nThis flaw represents a significant risk to asset integrity and audit trail reliability, as users without the necessary administrative check-out privileges can effectively modify asset ownership and location without triggering proper system validation or workflow requirements.\nExploitation requires an authenticated session with existing edit permissions, making it a privilege escalation vector that undermines the principle of least privilege within the asset management framework.",
  "technicalDetails": "The root cause of this vulnerability lies in an improper authorization check within the Snipe-IT API controller responsible for processing hardware updates. Specifically, the PATCH /api/v1/hardware/{id} endpoint fails to validate whether the authenticated user possesses the 'checkout' permission when assignment-related fields are included in the request payload.\nWhile the application correctly restricts UI-based check-out actions based on user roles, the API backend relies on the edit permission granted to the asset resource, failing to secondary-validate the specific authorization for assignment changes.\nThe attack flow commences with an attacker, possessing 'edit' but not 'checkout' permissions, constructing a malicious PATCH request directed at an asset ID. The payload includes parameters such as 'assigned_user', 'assigned_asset', or 'assigned_location'.\nUpon receipt of the request, the server-side logic processes the update. Because the authorization layer fails to intercept the inclusion of these specific assignment fields, the application updates the database record for the asset. This effectively reassigns the item to a new entity or location, bypassing the internal state machine that governs asset movement and custody logging.\nThis vulnerability is present in versions of Snipe-IT prior to 8.7.0. The exploit does not require remote code execution or specialized network access beyond an authenticated session; rather, it utilizes the existing, legitimate API infrastructure to perform unauthorized state transitions.\nThe post-exploitation impact includes the loss of accurate audit logs, the potential for asset theft or mismanagement due to falsified custody records, and the ability to circumvent institutional compliance workflows that require formal check-out documentation.\nBy failing to enforce secondary authorization logic at the API controller level, Snipe-IT allows users to perform administrative actions on assets that should be restricted to users with elevated checkout privileges."
}