Description

Snipe-IT versions before 8.7.0 wipe the database before validating the uploaded backup archive in the restore endpoint. Superusers uploading corrupted or invalid zip files trigger permanent data loss with no recovery path or rollback mechanism.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-09-09T14:17:23.710Z",
  "pubdate": "2026-09-09T14:17:23.710Z",
  "executiveSummary": "A critical vulnerability exists in Snipe-IT versions prior to 8.7.0, categorized as a lack of input validation leading to destructive data operations. The vulnerability resides within the application's database restore endpoint, which executes a destructive wipe of the existing database schema before verifying the integrity of the uploaded backup archive.\nThis flaw allows an authenticated Superuser to inadvertently or maliciously trigger irreversible data loss. Because the application fails to perform a pre-restore integrity check or implement a rollback mechanism, an invalid or corrupted ZIP file causes the primary database to be permanently cleared without successfully importing new data.\nThe risk implication is catastrophic, resulting in total loss of asset management records and configuration data. The attack requirement is limited to an authenticated session with Superuser privileges. There are no recovery mechanisms for the erased data, rendering the application inoperable until a manual off-site restoration is performed. Organizations utilizing Snipe-IT must treat the restore function as a high-risk operation until the software is updated to version 8.7.0 or later, which includes proper pre-validation logic.",
  "technicalDetails": "The vulnerability is rooted in an insecure execution order within the database restoration workflow of Snipe-IT. The restore function fails to implement a 'validate-before-destroy' sequence, which is a critical design requirement for administrative operations involving persistent storage modification.\nThe attack flow begins when an authenticated user with Superuser privileges navigates to the restore endpoint. The user selects a backup archive (typically a ZIP file) and submits the request to the server. Upon receipt of the request, the backend immediately invokes a database purge procedure to clear the existing environment. This operation typically involves dropping tables, truncating data, or re-initializing the database schema to prevent collisions during the restoration process. The vulnerability manifests here, as the application assumes the uploaded archive is valid and processable before performing any checksum, format, or integrity validation on the provided file.\nIf the uploaded file is malformed, corrupted, or an unsupported archive type, the backend's decompression and import routine fails during the subsequent execution stage. Because the database has already been wiped, the application process terminates prematurely. Crucially, the system lacks a transactional rollback mechanism that would revert the database state to the pre-wipe snapshot upon failure. Consequently, the database remains in an empty or partially initialized state, leading to permanent data loss of all prior assets, user records, and logs stored within the system.\nThe vulnerable component is the restore controller logic in versions prior to 8.7.0. Exploitation requires authenticated access with Superuser privileges; however, the impact is not limited to intentional attacks. A human error, such as uploading a corrupted backup or an incorrect file, is sufficient to trigger the destruction of the entire database. This flaw represents a significant reliability and security risk, as the integrity of the administrative restore function cannot be guaranteed. Post-exploitation, the application is left in a state of total data loss with no automated recovery path, forcing administrators to rely on off-system backups, assuming such backups exist outside of the current application scope."
}