CVE-2026-86766 in Snipe-IT
Summary
by MITRE • 09/09/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Snipe-IT versions up to and including 8.6.3 represents a classic Time-of-Check-to-Time-of-Use (TOCTOU) race condition within the consumable checkout API endpoint, specifically POST /api/v1/consumables/{consumable_id}/checkout. This flaw arises from an improper synchronization mechanism in the application logic that handles inventory management for consumable items. The core technical deficiency lies in the sequence of operations performed during a checkout request. When a user initiates a checkout, the system first validates whether the requested quantity is available by comparing it against the current count of remaining units stored in the database. This validation occurs outside of any atomic transaction block or database lock mechanism. Once this check passes, the application proceeds to create the necessary checkout records within a database transaction. However, because the consumable row was not locked during this interval and no re-validation is performed inside the transaction boundary, there exists a critical window where concurrent requests can bypass the intended inventory controls.
This architectural flaw allows an authenticated user with appropriate permissions to exploit the race condition by submitting multiple simultaneous checkout requests for the same consumable item. Since each request independently checks the availability before committing changes, two or more concurrent requests may both observe sufficient stock and proceed to create their respective checkout records. Consequently, the system over-allocates inventory, resulting in a negative remaining balance that contradicts physical reality. For instance, if a specific consumable has only one unit left in stock, an attacker can trigger two parallel checkouts for one unit each. Both requests will pass the initial availability check because neither sees the other's pending modification until after it is committed. The final state of the inventory record may then show -1 units remaining, indicating that more items were issued than actually exist. This not only corrupts data integrity but also undermines trust in the asset management system, potentially leading to operational disruptions when physical stock does not match digital records.
From a security classification perspective, this vulnerability aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization of Actions. The lack of proper locking or atomic operations on shared resources allows multiple threads of execution to interfere with each other in an unsafe manner. Furthermore, the exploitation technique falls under MITRE ATT&CK T1078: Valid Accounts, as it requires authentication and valid permissions to execute, although the impact is primarily integrity-related rather than confidentiality or availability focused. The ability to manipulate inventory counts negatively could be leveraged by malicious insiders to hide theft of physical assets or cause confusion in supply chain logistics within an organization.
The issue was addressed in Snipe-IT version 8.7.0 through a robust fix that enforces strict database-level concurrency control. The updated implementation re-fetches the parent consumable row using a lockForUpdate mechanism inside the transaction block. This ensures that any subsequent checkout request for the same item must wait until the previous transaction completes, thereby serializing access to the inventory count. Additionally, the system now performs a secondary validation of availability within the locked context before committing the changes. This approach guarantees atomicity and consistency, preventing over-allocation by ensuring that only one transaction can modify the stock level at any given time. Organizations running affected versions should upgrade immediately to 8.7.0 or later to mitigate this risk. Until upgrading is possible, implementing application-level rate limiting on the checkout endpoint may reduce the likelihood of successful concurrent exploitation, though it does not fully resolve the underlying race condition. Regular audits of inventory logs and reconciliation with physical stock counts are also recommended to detect any potential data corruption resulting from prior exploits.