Description

Snipe-IT versions <= 8.6.3 (fixed in 8.7.0) do not check the return value of storage write operations in ImageUploadRequest::handleImages(). Because Laravel's default disk mode does not throw on failure, a silently failed Storage::disk('public')->put(...) call still caused the application to delete the previous image via deleteExistingImage() and to reassign and persist the model's image reference to the new filename, destroying the existing image and leaving the database row pointing at a file that was never written. A mirror problem existed in deleteExistingImage(), where a failed Storage::delete() still nulled the model's image field, orphaning the file on disk. The condition is not directly attacker-controlled: it is triggered when any legitimate authenticated user submits an image upload while the storage backend transiently fails (for example an S3 network error, a local filesystem permission problem, or quota exhaustion). The result is unrecoverable loss of the prior image and a durable inconsistency between the database and disk that requires manual reconciliation. All models whose controllers route through ImageUploadRequest::handleImages (assets, asset models, users, companies, manufacturers, locations, categories, suppliers, departments, and other image-carrying models) are affected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-09-09T14:17:23.880Z",
  "pubdate": "2026-09-09T14:17:23.880Z",
  "executiveSummary": "This vulnerability involves an improper handling of storage write operations within Snipe-IT versions <= 8.6.3, resulting in data loss and persistent state inconsistency. The root cause lies in the application's failure to validate the return value of storage operations executed via Laravel's Storage facade.\nWhen a storage backend operation fails—due to transient factors like disk quotas, permission errors, or network connectivity issues—the application incorrectly proceeds to update the database state regardless. This results in the premature deletion of existing images and the corruption of database references, which point to non-existent files.\nThe vulnerability affects a broad range of models that utilize ImageUploadRequest::handleImages(), including assets, users, and companies. While not directly exploitable by an external attacker, the condition is triggered during legitimate user interactions, leading to permanent data loss and an invalid database-to-disk mapping. This requires manual administrative intervention to reconcile the data. The flaw represents a critical reliability and integrity issue for storage-dependent workflows within the application.",
  "technicalDetails": "The vulnerability originates in ImageUploadRequest::handleImages() and deleteExistingImage() within Snipe-IT, where the return value of Laravel's Storage::disk('public')->put() and Storage::delete() methods is ignored. Because the default Laravel disk implementation does not throw exceptions upon write or deletion failures, the application logic assumes the operation succeeded even when the underlying storage backend reports failure.\nThe attack flow—or functional failure flow—occurs when an authenticated user initiates an image upload. The application proceeds with the following sequence: 1) The deleteExistingImage() function is invoked to clear the previous image entry; 2) The new image is processed via Storage::disk('public')->put(); 3) Upon a failure of the put operation, the application proceeds to finalize the record update. Because the check for the boolean return value of the put operation is absent, the system permanently removes the reference to the old image and updates the database record to point to a new filename that was never physically persisted to the storage layer.\nA secondary, mirror failure occurs within deleteExistingImage(). If the storage layer fails to delete the target file, the system still proceeds to nullify the corresponding field in the database. This leaves orphaned, redundant files on the storage backend while the database records reflect an empty state, breaking the synchronization between the persistence layer and the relational database.\nThe affected versions include Snipe-IT <= 8.6.3, with a fix introduced in 8.7.0. The vulnerability is present across all models leveraging ImageUploadRequest::handleImages, spanning assets, asset models, users, companies, manufacturers, locations, categories, suppliers, and departments.\nExploitation does not require a malicious actor; rather, the condition is triggered by environmental factors such as S3 network timeouts, local filesystem permission misconfigurations, or storage quota exhaustion during otherwise legitimate user-authenticated sessions. The impact is significant, leading to the durable destruction of previous asset images and a state of database corruption that cannot be self-remediated by the application. The system loses the previous image data entirely, and administrators are left with a collection of orphaned files and database pointers that resolve to null paths, requiring manual cleanup and restoration from backups."
}