Description

Snipe-IT versions up to and including 8.6.3 contain a race condition (TOCTOU) in the consumable checkout API endpoint (POST /api/v1/consumables/{consumable_id}/checkout). The requested quantity is validated against the number of remaining units before the database transaction begins, and the transaction then creates the checkout records without locking the consumable row or re-checking availability. An authenticated user with permission to check out consumables can submit concurrent checkout requests for the same consumable so that both requests pass the availability check and succeed, over-allocating stock and driving the remaining inventory negative (e.g., a consumable with 1 remaining unit ends at -1 after two concurrent 1-unit checkouts). The issue is fixed in 8.7.0, which re-fetches the parent row under lockForUpdate inside the transaction and re-validates availability.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-09T14:17:26.963Z",
  "pubdate": "2026-09-09T14:17:26.963Z",
  "executiveSummary": "Snipe-IT versions up to and including 8.6.3 are susceptible to a Time-of-Check to Time-of-Use (TOCTOU) race condition within the consumables checkout API.\nThis vulnerability allows an authenticated user with appropriate checkout permissions to circumvent inventory constraints by submitting simultaneous requests.\nThe flaw stems from a lack of atomicity between the availability validation check and the subsequent database write operation, failing to implement row-level locking.\nSuccessful exploitation results in inventory over-allocation, causing stock counts to drop into negative values, effectively bypassing business logic controls.\nThe impact is primarily a compromise of inventory integrity and audit reliability within the asset management system.\nExploitation requires an authenticated session with sufficient authorization to perform consumable checkouts.",
  "technicalDetails": "The vulnerability resides within the POST /api/v1/consumables/{consumable_id}/checkout endpoint of the Snipe-IT application. The application logic performs a validation check to ensure that the requested quantity of a consumable does not exceed the remaining inventory. However, this validation occurs outside of a secured database transaction or locking mechanism.\nThe root cause is a classic TOCTOU race condition where the 'Check' (availability validation) and the 'Use' (database record creation) are decoupled. In affected versions, the application verifies the availability of the item and subsequently initiates a database transaction to create the checkout records. Because the system does not utilize pessimistic locking (such as SELECT FOR UPDATE) during the initial check, the state of the consumable row can change between the validation check and the transaction commit.\nAn attacker can exploit this by firing multiple concurrent HTTP POST requests to the checkout API for the same consumable ID. If the inventory has a single unit remaining, multiple concurrent threads can execute the initial availability check before any single thread completes its write operation. Each request verifies that there is at least one unit available, passes the application's check, and proceeds to the transaction phase. The database then processes multiple checkout records, resulting in an inventory count that reflects the sum of all requests rather than the available supply.\nThis behavior leads to a state where the consumable's remaining inventory is driven into negative values (e.g., an inventory of 1 becomes -1 if two concurrent 1-unit requests are processed simultaneously). The vulnerability exists because the application fails to enforce atomicity or isolation between the business logic check and the persistent storage update, allowing inconsistent states to propagate through the system.\nThe remediation, implemented in version 8.7.0, addresses this by utilizing a database-level lock (lockForUpdate) during the transaction. This forces subsequent requests to queue or wait until the initial transaction has committed and the inventory has been recalculated, ensuring that re-validation occurs against an accurate, locked record."
}