Snipe-IT CVE-2026-86749

Exploitation requires: (1) a user authenticated to Snipe-IT with permissions to upload images for any image-carrying model (assets, users, companies, etc. - low-privilege roles with image-upload rights qualify); and (2) a coincident transient failure of the configured storage backend at the moment the upload request is processed - examples include AWS S3 network timeout, NFS mount unavailability, local filesystem permission error, or disk quota exhaustion. The storage failure condition is not directly attacker-controllable in standard deployments without prior infrastructure access. Exploitation is further limited by: the requirement for simultaneous authenticated user activity and a storage failure event, the absence of any confidentiality or code-execution impact, and the fact that impact manifests as data loss rather than a security boundary crossing. Deployments using dedicated local filesystem storage with abundant capacity and no external dependencies face the lowest realistic exposure.

The provided CVSS 4.0 base score of 7.0 (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:H/VA:L) reflects network accessibility and high integrity impact, which is consistent with the data-destruction outcome. However, real-world exploitability is materially lower than the score suggests because the triggering condition - a coincident storage-layer failure - is not within attacker control in standard deployments. An adversarial use of this flaw would require an attacker to first induce infrastructure-level failures (exhaust S3 quota, disrupt network paths, fill local disks) while a legitimate user concurrently submits an image upload - a multi-step, environment-dependent chain. No CISA KEV listing exists, no public exploit or POC has been identified, and EPSS data is not provided in the source intelligence. The primary real-world risk is operational: unintentional data loss during storage-backend instability rather than targeted exploitation. Environments using highly reliable local filesystem storage with ample capacity have substantially lower exposure. The 'Information Disclosure' tag in the input metadata is a mislabel - the actual impact is irreversible integrity loss and database-to-disk inconsistency, not confidentiality breach.

An authenticated Snipe-IT user with asset-update permissions submits a new logo for a company record while AWS S3 is experiencing a transient connectivity disruption. Storage::put() returns false silently; the application proceeds to delete the prior company logo from S3 and updates the database row to reference the new filename, which was never written. The company logo is permanently gone and the database points to a non-existent file - no attacker action is required beyond the normal upload workflow coinciding with storage instability.