CVE-2026-86749

Snipe-IT versions through 8.6.3 do not check the return values of storage operations in ImageUploadRequest::handleImages() and deleteExistingImage(), so a silently failed Storage::disk('public')->put() call still deletes the previous image and repoints the database record at a file that was never written, while a failed Storage::delete() nulls the image field and orphans the file on disk. The condition is not directly attacker-controlled: it fires whenever any authenticated user submits an image upload while the storage backend transiently fails, such as an S3 network error, a local filesystem permission problem, or quota exhaustion. There is no confidentiality impact and nothing gained by an attacker; the outcome is unrecoverable loss of the prior image plus a durable database-versus-disk inconsistency that requires manual reconciliation. All image-carrying models routed through the handler are affected, including assets, asset models, users, companies, manufacturers, locations, categories, suppliers, and departments, on any Snipe-IT deployment running 8.6.3 or earlier. No public proof-of-concept or in-the-wild exploitation is known, the issue is not in CISA's KEV, and a fix ships in Snipe-IT 8.7.0 (CVSS 4.0 severity 7.0, High).

What to do: Upgrade to Snipe-IT 8.7.0 or later. As an interim measure, back up the public storage disk and database before image changes and, where supported, configure the Laravel storage disk to throw on failed writes instead of silently returning false. Audit image-carrying records for image fields pointing to missing files or orphaned files on disk and reconcile them manually.