CVE-2026-86739: Unchecked Return Value in grokability snipe-it
Affects grokability snipe-itSource CVE Database V5
Not known to be exploited · CVSS 2.3 Low · patch available : update grokability snipe-it when convenient.
Data as of 10/24/2026, 22:16:05 UTC
- Exploitation
Not in CISA KEV, no exploitation reported
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 28% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:NWhat to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| grokabilitysnipe-it | Affected
| Fixed in
|
GitHubgrokability/snipe-itpkg:github/grokability/snipe-itOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
A patch is available in Snipe-IT version 8.7.0 that fixes this issue by properly checking the return value of Storage::put() and preventing acceptance completion if file storage fails. Users should upgrade to version 8.7.0 or later to remediate this vulnerability. Since this is a cloud-hosted service, the vendor manages remediation for the cloud environment. Check the vendor advisory for confirmation and further guidance.
Description
Snipe-IT 8.6.3 and earlier do not check the return value of Storage::put() when writing the signature PNG and the generated acceptance PDF in Account\AcceptanceController::store(). On filesystem drivers that return false instead of throwing on a write failure (for example the local disk with restrictive permissions, S3 with expired credentials, or a storage backend that is out of quota), execution continues into $acceptance->accept(), which sets accepted_at and the signature_filename/eula_filename fields, creates the 'accepted' action-log entry, and dispatches completion notifications even though the evidence files were never stored. The result is an acceptance record marked complete whose supporting evidence files do not exist, yielding a materially incomplete compliance artifact for EULA acknowledgement or equipment-receipt workflows. The condition is triggered when an authenticated user completes an acceptance while the storage backend is silently failing writes; an attacker cannot directly force the storage backend into that state. Fixed in Snipe-IT 8.7.0.
Impact
The vulnerability causes acceptance records to be marked as complete even when the supporting evidence files (signature PNG and acceptance PDF) are not successfully stored. This leads to materially incomplete compliance artifacts, potentially undermining EULA acknowledgement or equipment receipt workflows. There is no direct exploitation to cause storage failure; the issue arises only if the storage backend is already failing silently. The CVSS score is low (2.3), reflecting limited impact and exploitability.
Summary
Snipe-IT versions 8.6.3 and earlier do not check the return value of Storage::put() when writing signature and acceptance PDF files in Account\AcceptanceController::store(). On storage backends that return false on write failure without throwing exceptions (such as local disk with restrictive permissions, expired S3 credentials, or quota-exhausted storage), the application proceeds to mark acceptance as complete and dispatch notifications despite the files not being stored. This results in acceptance records lacking the necessary evidence files, compromising compliance workflows. The vulnerability requires an authenticated user to complete an acceptance while the storage backend is failing silently. It cannot be directly forced by an attacker. The issue is resolved in Snipe-IT 8.7.0.