Description

Snipe-IT before 8.7.0 gates the bulk asset restore endpoint on the assets.edit permission instead of assets.delete, allowing users without delete rights to restore soft-deleted assets. Attackers with edit permissions can post asset identifiers to the bulk restore endpoint to undo administrator deletions and bypass intended permission separation.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-01T16:17:35.607Z",
  "pubdate": "2026-09-01T16:17:35.607Z",
  "executiveSummary": "Snipe-IT versions prior to 8.7.0 contain an improper authorization vulnerability within the bulk asset restore functionality. The flaw originates from an incorrect mapping of access control lists (ACLs) to sensitive administrative operations.\nSpecifically, the application erroneously validates the 'assets.edit' permission for the bulk restore endpoint, rather than the more restrictive 'assets.delete' permission. This discrepancy creates a privilege escalation scenario where users granted edit-only access can manipulate the lifecycle state of soft-deleted assets.\nThe vulnerability allows authenticated attackers with standard 'assets.edit' privileges to unilaterally reverse administrative deletions, thereby undermining data management policies and asset lifecycle controls. There are no remote code execution implications; however, the ability to restore deleted assets bypasses intended administrative workflows and security boundaries. Exploitation requires valid authentication and existing edit-level permissions, limiting the attack surface to malicious insiders or compromised accounts with specific asset management roles.\nOrganizations using impacted versions are at risk of data integrity compromise concerning deleted records. Ensuring the principle of least privilege is maintained is critical, but systemic remediation is only achieved through the application of the vendor-supplied patch.",
  "technicalDetails": "The vulnerability is classified as an improper authorization flaw, specifically an access control bypass affecting the bulk asset recovery interface in Snipe-IT. The root cause is a misconfiguration of the authorization middleware protecting the bulk restore controller.\nIn standard asset management workflows, 'soft-delete' operations typically transition an asset record to a non-active state without purging the underlying database entry. Access to 'delete' or 'restore' functions should theoretically be gated by administrative privileges associated with the 'assets.delete' capability to ensure that only authorized personnel can influence the availability and visibility of archived assets.\nIn the affected versions (prior to 8.7.0), the backend logic governing the bulk restore endpoint incorrectly references the 'assets.edit' permission check. Consequently, any authenticated user possessing the 'assets.edit' capability—which is often assigned to standard asset managers or operational staff—is granted programmatic access to trigger the restore process for soft-deleted assets.\nThe attack flow proceeds as follows: An attacker with 'assets.edit' permissions first identifies the resource identifiers (or primary keys) of soft-deleted assets, which may be accessible via history logs or other administrative views. The attacker then constructs a POST request targeting the bulk restore endpoint, passing an array of these asset identifiers. The application middleware, performing a check against the 'assets.edit' permission, confirms the attacker is authorized to 'edit' assets and subsequently permits the restore operation to execute. The backend controller processes the request, updates the record status from 'deleted' to 'active', and effectively reverses the administrative deletion. This results in the re-introduction of assets into the active inventory, potentially exposing records that were intentionally removed from circulation for security, auditing, or inventory cleanup purposes.\nThe post-exploitation impact allows for the subversion of internal administrative workflows and the unauthorized restoration of inventory data. Because this endpoint bypasses the intended 'assets.delete' requirement, it creates a persistent violation of the principle of least privilege, allowing actors with operational edit capabilities to perform administrative actions they are not explicitly authorized to execute."
}