CVE-2026-86739

Snipe-IT 8.6.3 and earlier fails to check the return value of Storage::put() when persisting the signature PNG and acceptance PDF in Account\AcceptanceController::store(), so a silently failing storage backend (local disk with restrictive permissions, expired S3 credentials, or an out-of-quota store) still results in the acceptance being recorded as complete with accepted_at set, an 'accepted' action-log entry, and completion notifications dispatched. The flaw is triggered by an authenticated user completing an EULA acknowledgement or equipment-receipt acceptance while the storage backend is failing writes without throwing; an attacker cannot directly force that state, and no confidentiality or availability impact occurs. The practical impact is integrity-only: compliance artifacts that are marked complete but whose supporting signature and PDF evidence files do not exist, which can undermine audit and legal workflows. All self-hosted Snipe-IT deployments on 8.6.3 or earlier that use acceptance/EULA workflows are affected. The issue is fixed in Snipe-IT 8.7.0, and there is no indication of exploitation in the wild.

What to do: Upgrade to Snipe-IT 8.7.0, which checks the Storage::put() return value before marking an acceptance complete. In the meantime, verify storage backend health and permissions (local disk write access, S3 credential validity, quota) and add monitoring/alerting for failed writes. Audit existing acceptance records from before the upgrade for missing signature_filename/eula_filename files and re-collect signatures where evidence is absent.