CVE-2026-86740: Snipe-IT before 8.7.0 Attachment Deletion Reports Success While File Remains
Snipe-IT before 8.7.0 fails to check the return value of Storage::delete() in UploadedFilesController::destroy() and Api\\UploadedFilesController::destroy(), allowing deletion requests to report success while files remain on disk. Administrators performing attachment deletions receive success responses and see files hidden from listings, but the physical files persist on disk and remain accessible to anyone with filesystem or backup access.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to the residual files?
The retained files are accessible to anyone who has filesystem access or access to backups containing the Snipe-IT storage. The issue does not indicate that the files remain visible through normal Snipe-IT attachment listings after deletion.
What access is needed to trigger the misleading deletion result?
An administrator performs an attachment deletion request. The application can report that the deletion succeeded and hide the attachment from listings even when the underlying storage deletion fails.
How can administrators determine whether they are affected?
After deleting an attachment, verify that its physical file has actually been removed from the Snipe-IT storage location and from relevant backups. A successful response or the attachment disappearing from application listings is not sufficient evidence of deletion.
What can be done if upgrading is not immediately possible?
Independently verify and remove files for deleted attachments from the underlying storage, and account for copies in backups. Restrict filesystem and backup access to reduce exposure of files that the application reports as deleted.