CVE-2026-86744 in Snipe-IT
Summary
by MITRE • 09/09/2026
Snipe-IT 8.6.3 and earlier (and develop pre-release commits prior to the fix) contain a race condition in the asset checkout paths. Api\AssetsController::checkout() and Assets\AssetCheckoutController::store() call Asset::availableForCheckout() outside the mutation path and then invoke Asset::checkOut() without taking a row lock or re-checking availability, so two concurrent checkout requests for the same available asset can both observe it as available and both commit. This produces duplicate checkout-history rows, a doubled checkout_counter, and two CheckoutableCheckedOut events for a single-assignment asset, corrupting the audit trail and utilization/reconciliation reporting; the asset's final assigned_to remains singular, so the visible assignment stays intact. Exploitation requires an authenticated session holding the assets.checkout permission (or superuser) and precise concurrent timing. Fixed in 8.7.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Snipe-IT versions prior to 8.7.0 represents a critical race condition within the asset checkout workflow, specifically affecting both the API endpoint Api\AssetsController::checkout() and the web interface controller Assets\AssetCheckoutController::store(). This flaw stems from a classic check-then-act pattern where the system verifies an asset's availability for checkout via Asset::availableForCheckout() outside of any database transaction or row-level locking mechanism. Following this verification, the application proceeds to invoke Asset::checkOut() without re-validating the state or acquiring exclusive locks on the relevant database rows. This architectural oversight allows multiple concurrent requests targeting the same available asset to bypass the availability check simultaneously. Since both threads observe the asset as unassigned at the moment of their respective checks, they each proceed to commit a checkout operation independently.
The operational impact of this race condition is significant for data integrity and audit compliance. When two or more users successfully execute concurrent checkout requests against a single-assignment asset, the system generates duplicate entries in the checkout history table. This results in an inflated checkout_counter value that does not reflect actual usage patterns and triggers multiple CheckoutableCheckedOut events for what should be a singular assignment event. While the final state of the asset's assigned_to field typically remains consistent due to subsequent updates overwriting previous values, the intermediate corruption creates substantial discrepancies in audit trails. For organizations relying on Snipe-IT for strict compliance with standards such as ISO 27001 or NIST SP 800-53 regarding accurate inventory tracking and change management logs, this data inconsistency undermines trust in reporting mechanisms used for reconciliation and utilization analysis.
From a technical classification perspective, this vulnerability aligns closely with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition). The failure to implement proper synchronization primitives, such as database row locks or optimistic locking versions during the critical section of updating asset status, allows for non-deterministic behavior under concurrent load. In terms of adversary tactics, this could be leveraged within ATT&CK technique T1530: Data from Cloud Object Storage if an attacker were to exploit these duplicate records to obfuscate their activities or create noise in logs to evade detection systems that rely on unique event identifiers for anomaly detection. Although exploitation requires authenticated access with assets.checkout permissions, the precision required for timing suggests it is more likely a result of automated scripts or high-concurrency scenarios rather than manual attack attempts by external threat actors without internal credentials.
Mitigation strategies must focus on enforcing atomicity in database operations involving asset state changes. The primary remediation involves modifying the checkout logic to utilize row-level locking, such as SELECT FOR UPDATE in SQL databases, which ensures that only one transaction can modify a specific record at a time. Alternatively, implementing optimistic concurrency control by checking and updating version numbers during the write operation can prevent stale data overwrites. Until an upgrade is performed, administrators should monitor for unusual spikes in checkout history entries or discrepancies between reported asset status and actual assignment records. The definitive fix was released in Snipe-IT version 8.7.0, which addresses these synchronization gaps by ensuring that availability checks are coupled with exclusive locks during the mutation phase of the asset lifecycle.