Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "2.2",
  "pubDate": "2026-09-09T14:17:23.130Z",
  "pubdate": "2026-09-09T14:17:23.130Z",
  "executiveSummary": "Snipe-IT versions 8.6.3 and earlier are susceptible to a race condition vulnerability within the asset checkout workflow. The vulnerability manifests in the Api\\AssetsController::checkout() and Assets\\AssetCheckoutController::store() controllers, where the application fails to enforce atomicity during the asset availability check and subsequent assignment process.\nBy leveraging precise concurrent timing, an authenticated user with sufficient privileges can bypass asset availability constraints. This allows for the simultaneous checkout of a single asset, resulting in data inconsistency, corrupted audit trails, and inaccurate utilization reporting. Although the primary asset state remains singular, the duplicated history entries compromise the integrity of reconciliation processes. Exploitation requires an active, authenticated session with the 'assets.checkout' permission and the ability to trigger concurrent requests. This flaw highlights a critical synchronization failure in the application’s state management logic, necessitating an immediate update to the remediated version.",
  "technicalDetails": "The vulnerability originates from a Time-of-Check to Time-of-Use (TOCTOU) race condition located within the asset management logic of Snipe-IT. The application utilizes the Asset::availableForCheckout() function to verify if an asset is eligible for assignment. However, this check is executed outside of a synchronized mutation path, such as a database transaction or a row-level lock.\nThe vulnerable controllers, specifically Api\\AssetsController::checkout() and Assets\\AssetCheckoutController::store(), follow a flawed execution sequence. First, the application queries the database to confirm availability. Second, it proceeds to invoke Asset::checkOut() to finalize the assignment. Because the initial check and the subsequent write operation are not atomic, there exists a temporal window between the check and the mutation.\nDuring this window, a secondary request can perform its own availability check while the first process is still in the middle of its execution flow. If both processes evaluate the asset as available, they will both proceed to commit the checkout. This results in the database recording two checkout-history entries, incrementing the checkout_counter twice, and triggering multiple CheckoutableCheckedOut events for a single, non-sharable asset.\nThe attack flow requires an attacker to possess valid credentials and the 'assets.checkout' permission (or superuser status). The attacker must then initiate multiple concurrent requests targeting the same asset identifier. By manipulating the timing of these requests—often using automated tools to flood the endpoint—the attacker forces the race condition to trigger. While the final database state for 'assigned_to' remains singular due to the nature of the database update, the underlying audit logs become corrupted.\nThis behavior significantly undermines the reliability of asset management and reconciliation reporting. It effectively allows for the bypass of business logic that enforces one-to-one asset assignment, creating discrepancies in utilization tracking and complicating audit trail verification. The flaw is inherent in the design of the checkout controller methods in all versions prior to 8.7.0, where the absence of proper locking mechanisms—such as SELECT FOR UPDATE—allows state inconsistencies to persist under high-concurrency conditions."
}