CVE-2026-86739
Low
No strong exploitation signal.
CVSS breakdown
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
| Attack Vector | N | Network |
| Attack Complexity | H | High |
| Privileges Required | L | Low |
| User Interaction | N | None |
| Scope | U | Unchanged |
| Confidentiality | N | None |
| Integrity | L | Low |
| Availability | N | None |
Timeline
- 2026-09-09 — Published (NVD)
- 2026-09-18 — Last modified (NVD)
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.