Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.8",
  "pubDate": "2026-09-09T14:17:22.537Z",
  "pubdate": "2026-09-09T14:17:22.537Z",
  "executiveSummary": "This vulnerability involves an improper check of return values within Snipe-IT file management operations. Specifically, the application fails to validate the success status of the Storage::delete() method within the UploadedFilesController and Api\\UploadedFilesController classes.\nWhen an administrator initiates an attachment deletion request, the application erroneously returns a success response to the user interface, even if the underlying filesystem operation fails to remove the file.\nConsequently, the application removes the database entry, effectively hiding the file from the Snipe-IT UI, while the physical binary persists on the server's storage.\nThis creates a discrepancy between the application state and the actual disk content, potentially leading to unauthorized data retention.\nThe risk implication is significant for environments with strict data privacy compliance requirements, as files believed to be destroyed remain accessible to entities with direct filesystem or backup access.\nExploitation does not require external network access if the adversary already possesses filesystem-level permissions or unauthorized access to system backups.",
  "technicalDetails": "The vulnerability resides in the UploadedFilesController::destroy() and Api\\UploadedFilesController::destroy() methods of Snipe-IT prior to version 8.7.0. The root cause is a failure to evaluate the boolean return value of the Laravel Storage::delete() facade method.\nIn the Laravel framework, Storage::delete() returns true if the file was deleted successfully and false otherwise. The affected controller implementation proceeds as if the operation was successful regardless of the actual filesystem outcome.\nAttack flow: An authenticated user with sufficient privileges to manage assets or accessories initiates a deletion request for a specific file. The controller invokes the delete method on the storage disk. Even if the filesystem operation fails—due to permission restrictions, file locking, or storage driver errors—the controller logic fails to implement conditional branching to catch the failure.\nThe application subsequently deletes the record from the database. Because the database record is the primary index for the UI, the file effectively disappears from the user's view, creating the illusion of deletion.\nFrom a security perspective, this creates a 'ghost file' scenario. The binary data remains in the underlying storage path (e.g., local storage or cloud-based bucket).\nPost-exploitation impact is characterized by the persistence of sensitive data that is presumed to be sanitized. An attacker or an unauthorized user with access to the underlying storage—via compromised server credentials, misconfigured backup shares, or local filesystem access—can recover these 'orphaned' files.\nThis issue is particularly relevant in regulated environments where data lifecycle management (e.g., GDPR or HIPAA) mandates that files marked for deletion must be purged from all storage media.\nNo specific exploit payload is required to trigger this vulnerability, as it is a logic flaw inherent in the controller's handling of standard service responses. The flaw persists across both web-based and API-based interactions involving file management, extending the attack surface to any authenticated user capable of performing a delete request."
}