{"id":"CVE-2026-86744","aliases":["EUVD-2026-74921","GHSA-h992-9438-26v8","GHSA-q6gf-g3vm-vprw"],"status":"published","title":"snipe-it before 8.7.0 Race Condition in Asset Checkout","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.","severity":{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00271,"percentile":0.1958,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-362"],"published":"2026-09-09T13:32:09Z","modified":"2026-10-28T02:30:26Z","products":[{"vendor":"grokability","product":"snipe-it"},{"vendor":"grokability, inc.","product":"snipe-it"},{"vendor":"snipeitapp","product":"snipe-it"}],"references":[{"url":"https://github.com/grokability/snipe-it/security/advisories/GHSA-h992-9438-26v8","tags":["vendor-advisory","Exploit","Mitigation","Patch","Vendor Advisory","advisory"]},{"url":"https://github.com/grokability/snipe-it/commit/f71806b1e0efbd3bc2b6be61994ad2a5d5d6c206","tags":["patch","Patch","fix"]},{"url":"https://www.vulncheck.com/advisories/snipe-it-before-8.7.0-race-condition-in-asset-checkout","tags":["third-party-advisory","Third Party Advisory","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-86744","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-q6gf-g3vm-vprw"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/86xxx/CVE-2026-86744.json","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-86744","title":"snipe-it before 8.7.0 Race Condition in Asset Checkout","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.","status":"published","published":"2026-09-09T13:32:09.284Z","modified":"2026-09-18T17:23:08.679Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low","assessor":"cna"},{"version":"3.1","score":2.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N","level":"low","assessor":"cna"}],"cwes":["CWE-362"],"updated_at":"2026-11-02T13:49:42.666099Z"}],"euvd":[{"id":"EUVD-2026-74921","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.","status":"published","published":"2026-09-09T13:32:09Z","modified":"2026-09-18T17:23:08Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"}],"updated_at":"2026-11-02T17:28:08.412343Z"}],"ghsa":[{"id":"GHSA-q6gf-g3vm-vprw","title":"Snipe-IT 8.6.3 and earlier (and develop pre-release commits prior to the fix) contain a race...","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.","status":"published","published":"2026-09-09T15:35:12Z","modified":"2026-09-09T15:35:16Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"low"},{"version":"3.1","score":2.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N","level":"low"}],"cwes":["CWE-362"],"updated_at":"2026-11-02T15:11:38.712835Z"}],"nvd":[{"id":"CVE-2026-86744","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.","status":"published","published":"2026-09-09T14:17:23.13Z","modified":"2026-09-18T18:17:19.88Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"low","assessor":"secondary"},{"version":"3.1","score":2.2,"vector":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N","level":"low","assessor":"secondary"}],"cwes":["CWE-362"],"updated_at":"2026-11-02T14:12:45.93749Z"}],"osv":[{"id":"CVE-2026-86744","title":"snipe-it before 8.7.0 Race Condition in Asset Checkout","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.","status":"published","published":"2026-09-09T13:32:09.284Z","modified":"2026-10-28T02:30:26.8860164Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-362"],"updated_at":"2026-11-02T15:45:19.210277Z"}]}}