CVE-2026-86740

Snipe-IT versions before 8.7.0 fail to check the return value of Storage::delete() in the web controller UploadedFilesController::destroy() and its API counterpart Api\UploadedFilesController::destroy(). When an administrator deletes an uploaded attachment and the underlying filesystem deletion fails, the application still returns a success response and hides the file from listings, while the physical file remains on disk. Anyone with access to the server filesystem or to backups can therefore retrieve attachments that were believed to be deleted, which is a data-retention/privacy problem rather than a remote code-execution risk — sensitive files stored in the asset management system (e.g., license documents, photos, invoices) may persist indefinitely. The flaw affects all Snipe-IT deployments running versions before 8.7.0 and requires high (administrator) privileges to trigger plus filesystem or backup access to exploit, consistent with its medium CVSS 4.0 score of 5.1. No exploitation is known; EPSS is 0.2% and the only public reference is the upstream advisory GHSA-4c4h-cpgf-h4qr published by the maintainers.

What to do: Upgrade to Snipe-IT 8.7.0 or later, which verifies the Storage::delete() return value and surfaces deletion failures. Audit upload/attachment storage directories (e.g., private uploads paths) for files whose attachment records were already deleted, remove them from disk, and account for the fact that backups retain copies of supposedly deleted attachments. Also check for root causes of silent deletion failures — filesystem permissions, read-only or full disks — and confirm deletion behaves correctly after upgrading.