Skip to main content
CVE-2026-86739VulnerabilityPublished 09/09/2026Updated 09/18/2026

CVE-2026-86739: Unchecked Return Value in grokability snipe-it

Affects grokability snipe-itSource CVE Database V5

0

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

CVSS 4.0 base score
2.3Low
How severe the flaw is on the 0–10 CVSS scale.
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:N

What to do

Affected software

ProductAffectedFixed in
grokabilitysnipe-itAffected
  • <8.7.0
Fixed in
  • 8.7.0
GitHubgrokability/snipe-itpkg:github/grokability/snipe-itOther threatsAffected
  • <=8.6.3
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.

References

Community reviews

Loading reviews…