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.
Advisories
No advisories yet.
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Wed, 09 Sep 2026 13:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | Snipe-IT before 8.7.0 Acceptance Finalization Without Stored Evidence | |
| First Time appeared |
Snipeitapp
Snipeitapp snipe-it |
|
| Weaknesses | CWE-252 | |
| CPEs | cpe:2.3:a:snipeitapp:snipe-it:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Snipeitapp
Snipeitapp snipe-it |
|
| References |
| |
| Metrics |
cvssV3_1
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: VulnCheck
Published:
Updated: 2026-09-09T13:32:05.761Z
Reserved: 2026-09-08T11:31:38.679Z
Link: CVE-2026-86739
No data.
Status : Received
Published: 2026-09-09T14:17:22.387
Modified: 2026-09-09T14:17:22.387
Link: CVE-2026-86739
No data.
OpenCVE Enrichment
No data.
Weaknesses