CVE-2026-86739: Snipe-IT acceptance finalization without stored evidence verification

CVE-2026-86739 · Severity: low · CVSS 3.1 · Published 2026-09-09

Snipe-IT is an open-source asset-management system used to track equipment and employee acknowledgements. When acceptance records (such as equipment-receipt or EULA-acknowledgement confirmations) are submitted, the system can incorrectly mark them as complete even if the supporting evidence files (signatures and PDFs) failed to save to storage. This creates fraudulent compliance records that appear accepted but have no actual evidence, undermining audit trails and regulatory compliance documentation.

Technologies: Snipeitapp Snipe-It. Vendors: Snipeitapp.

Quick answers

Is CVE-2026-86739 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-86739 being exploited in the wild.
How severe is CVE-2026-86739?
Low severity, with a CVSS score of 3.1, published 9 September 2026.
Which products and versions are affected?
Grokability Snipe-IT 8.6.3 and earlier.
Is there a fix for CVE-2026-86739?
A patch was published on 2026-09-09: Fixed in version 8.7.0 Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-86739 attacked?
It is attacked over the network, in a web application.
Am I affected by CVE-2026-86739?
Check whether you run Snipeitapp Snipe-It. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

Technical details

The vulnerability is an unchecked return value in Account\AcceptanceController::store() where Storage::put() calls for signature PNG and acceptance PDF files do not verify success before proceeding. On non-throwing filesystem drivers (local disk with restricted permissions, S3 with expired credentials, or quota-exhausted backends), write failures silently return false but execution continues into $acceptance->accept(), which populates accepted_at, signature_filename/eula_filename fields, creates action-log entries, and dispatches notifications despite the evidence files never being stored. Attack precondition: an authenticated user must complete an acceptance workflow while the storage backend is in a silent-failure state; an attacker cannot directly force that condition. The fix (released in 8.7.0) checks both Storage::put() return values and halts execution with an error message if either write fails, preventing the acceptance record from being finalized with missing evidence.

Affected products

  • Grokability Snipe-IT 8.6.3 and earlier

Timeline

  • 2026-08-24: disclosed
  • 2026-09-09: advisory
  • 2026-09-09: patched: Fixed in version 8.7.0

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.