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.
Published: 2026-09-09
Score: 2.3 Low
EPSS: < 1% Very Low
KEV: No
Impact: Accurate compliance records not guaranteed
Action: Patch
AI Analysis

Impact

The vulnerability arises because Snipe‑IT versions prior to 8.7.0 do not validate the success of file writes when storing acceptance evidence. If the storage backend silently fails, the application proceeds to mark the acceptance as completed. This produces a record indicating completion, but the signature and acceptance PDF files are absent, leading to a material deficiency in compliance artifacts for EULA acknowledgement or equipment‑receipt processes.

Affected Systems

Affected versions are 8.6.3 and earlier of the Snipe‑IT application provided by grokability. The vulnerability exists in the AcceptanceController::store() path of the product, and the fix is included in the 8.7.0 release.

Risk and Exploitability

The CVSS score is 2.3, and the EPSS score is not available, indicating a low severity and uncertain exploitation likelihood. The vulnerability does not allow remote code execution or privilege escalation. The primary risk appears when the storage backend is misconfigured or exhausted; attackers cannot directly induce the silent failure. Consequently, the risk to confidentiality or high‑profile availability is minimal, but the integrity of compliance reporting is compromised.

Generated by OpenCVE AI on September 9, 2026 at 15:50 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Snipe‑IT instance to version 8.7.0 or later.
  • Verify that the configured storage backend (local disk, S3, etc.) has sufficient write permissions and quota, and that file writes succeed.
  • Introduce application logic to confirm that signature and PDF files are successfully stored before finalizing the acceptance record.
  • If an upgrade is not immediately feasible, monitor storage operations and reject completion attempts when file storage returns an error.

Generated by OpenCVE AI on September 9, 2026 at 15:50 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 18 Sep 2026 21:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

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

Thu, 10 Sep 2026 18:00:00 +0000

Type Values Removed Values Added
First Time appeared Grokability
Grokability snipe-it
Vendors & Products Grokability
Grokability snipe-it

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

{'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'}

Subscriptions

Grokability Snipe-it
Snipeitapp Snipe-it
cve-icon MITRE

Status: PUBLISHED

Assigner: VulnCheck

Published:

Updated: 2026-09-18T17:23:08.827Z

Reserved: 2026-09-08T11:31:38.679Z

Link: CVE-2026-86739

cve-icon Vulnrichment

Updated: 2026-09-18T17:17:41.406Z

cve-icon NVD

Status : Analyzed

Published: 2026-09-09T14:17:22.387

Modified: 2026-09-18T18:17:19.093

Link: CVE-2026-86739

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-10T17:45:16Z

Weaknesses