# CVE-2026-86739

## Summary

- **CVE ID:** CVE-2026-86739
- **Severity:** LOW
- **CVSS Score:** 3.1 (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)
- **CWE:** CWE-252
- **Published:** Sep 9, 2026
- **Last Modified:** Sep 9, 2026

## 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.

## Affected Products

- grokability — snipe-it (0)
- grokability — snipe-it (8.7.0)

## References

- [CNA](https://github.com/grokability/snipe-it/security/advisories/GHSA-h543-58f9-v6mj)
- [CNA](https://www.vulncheck.com/advisories/snipe-it-before-8.7.0-acceptance-finalization-without-stored-evidence)

---
_Exported from OnDuty AI Vulnerability Intelligence on 2026-09-10._