Description

Snipe-IT is an IT asset/license management system. Prior to 8.4.1, an authenticated user with generic asset edit permission can delete files attached to assets outside the user's ownership or company assignment. The destroy() methods in app/Http/Controllers/Api/UploadedFilesController.php and app/Http/Controllers/UploadedFilesController.php authorize update against the object class instead of the resolved object instance, creating an insecure direct object reference. This issue is fixed in version 8.4.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-08-19T19:17:20.263Z",
  "pubdate": "2026-08-19T19:17:20.263Z",
  "executiveSummary": "An Insecure Direct Object Reference (IDOR) vulnerability exists in Snipe-IT prior to version 8.4.1, affecting the file attachment management functionality. The flaw enables an authenticated user possessing generic asset edit permissions to arbitrarily delete files attached to assets regardless of ownership constraints or company assignment boundaries. This security deficiency stems from improper authorization checks implemented within the application controllers, where permission validation targets the overarching object class rather than the specific, resolved object instance. Consequently, low-privileged users or users restricted by multi-tenancy company constraints can manipulate object references to execute destructive operations against unauthorized resources. The risk implication centers on unauthorized data destruction, potential sabotage of IT asset records, and bypass of logical access controls within enterprise environments. Successful exploitation requires valid authentication within the system alongside baseline asset editing privileges, allowing attackers to target arbitrary file attachments across the application without escalating underlying account permissions.",
  "technicalDetails": "The vulnerability resides in the destroy() methods located within app/Http/Controllers/Api/UploadedFilesController.php and app/Http/Controllers/UploadedFilesController.php. The root cause of the flaw is an authorization logic failure: the controllers authorize update and deletion actions against the abstract object class rather than evaluating permissions against the concrete, resolved object instance associated with the targeted file attachment. Because authorization is checked broadly at the class level, the application fails to verify whether the authenticated user possesses explicit administrative rights or valid ownership over the specific asset and its associated file attachments.\nThe attack flow proceeds as follows. An authenticated attacker with standard generic asset edit permissions identifies a file attachment tied to an asset belonging to another user or an isolated company assignment. The attacker formulates an API request or web interface submission targeting the destroy() method of the UploadedFilesController, supplying the identifier of the targeted file attachment. Due to the absence of instance-level authorization checks, the controller bypasses company and ownership validation boundaries. The application processes the request against the object class, confirms the user has generic asset edit capabilities, and proceeds to execute the deletion routine. This behavior results in the unauthorized removal of files from the underlying storage mechanism.\nThe affected components are the UploadedFilesController implementations within both the web and API routing architectures of Snipe-IT prior to version 8.4.1. Exploitation requires network exposure to the Snipe-IT instance, valid user authentication, and low-privileged access encompassing generic asset edit permissions. The post-exploitation impact is limited to the deletion of attached files, which may disrupt asset management tracking, destroy critical audit trails, or remove sensitive documentation linked to enterprise IT hardware and software inventories."
}