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.
Published: 2026-09-09
Score: 7.1 High
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Analysis and contextual insights are available on OpenCVE Cloud.

Remediation

No vendor fix or workaround currently provided.

Additional remediation guidance may be available on OpenCVE Cloud.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 09 Sep 2026 15:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'poc', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Wed, 09 Sep 2026 13:45:00 +0000

Type Values Removed Values Added
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.
Title Snipe-IT 8.6.3 Race Condition via Consumable Checkout
First Time appeared Snipeitapp
Snipeitapp snipe-it
Weaknesses CWE-362
CPEs cpe:2.3:a:snipeitapp:snipe-it:*:*:*:*:*:*:*:*
Vendors & Products Snipeitapp
Snipeitapp snipe-it
References
Metrics cvssV3_1

{'score': 6.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N'}

cvssV4_0

{'score': 7.1, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N'}

Subscriptions

Snipeitapp Snipe-it
cve-icon MITRE

Status: PUBLISHED

Assigner: VulnCheck

Published:

Updated: 2026-09-09T14:18:02.631Z

Reserved: 2026-09-08T11:33:02.642Z

Link: CVE-2026-86766

cve-icon Vulnrichment

Updated: 2026-09-09T14:17:39.313Z

cve-icon NVD

Status : Received

Published: 2026-09-09T14:17:26.963

Modified: 2026-09-09T15:17:19.990

Link: CVE-2026-86766

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-09T15:45:04Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')