CVE-2026-86739

Snipe-IT before 8.7.0 Acceptance Finalization Without Stored Evidence

Published Sep 9, 2026 CVSS 4.0 · 2.3 Low EPSS < 1% KEV · Not listed
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.

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

No advisories available
History
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
First Time appeared Grokability
Grokability snipe-it
Vendors & Products Grokability
Grokability snipe-it
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

{'score': 3.1, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N'}

cvssV4_0

{'score': 2.3, 'vector': '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'}

Weaknesses

Sources

Status
PUBLISHED
Assigner
VulnCheck
Published
Updated
Sep 18, 2026, 5:23 PM
Reserved
Sep 8, 2026, 11:31 AM
Status
Analyzed
Published
Sep 9, 2026, 2:17 PM
Modified
Sep 18, 2026, 6:17 PM