EUVD-2026-62681
GHSA-x667-r589-43m7
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Requires authenticated low-privilege user (PR:L); no special conditions (AC:L); arbitrary file deletion across all assets produces high integrity impact (I:H) with no confidentiality or availability effect.
Primary rating from Vendor (https://github.com/grokability/snipe-it).
CVSS VectorVendor: https://github.com/grokability/snipe-it
Lifecycle Timeline
3DescriptionCVE.org
Impact
A vulnerability was identified in Snipe-IT v8.4.0 (build 21280-g91a95dbc6) that allows any authenticated user with generic asset edit permissions to delete files attached to any asset in the system, regardless of ownership or company assignment. This constitutes an Insecure Direct Object Reference (IDOR) vulnerability caused by a class-level authorization check in the file deletion endpoint, where an instance-level check is required.
The vulnerability exists in both the web and API controllers, affecting all Snipe-IT installations running version 8.4.0 and potentially earlier versions.
Patches
Patched in https://github.com/grokability/snipe-it/commit/8bc7d50e35d93eee5a0d48b4923e497937cf93fd
AnalysisAI
Improper authorization in Snipe-IT v8.4.0 permits any authenticated user holding generic asset edit permissions to delete files attached to any asset across the entire system, bypassing both ownership and company assignment boundaries. The flaw exists in both the web and API file deletion controllers, where a class-level policy check is applied instead of the required instance-level check, constituting a classic IDOR (CWE-285). No public exploit or active exploitation has been identified at time of analysis; a vendor-released patch exists in version 8.4.1.
Technical ContextAI
Snipe-IT is a PHP/Laravel-based open-source IT asset management platform (composer package snipe/snipe-it). Laravel's built-in policy authorization uses $this->authorize('update', $target), where passing a class string (e.g., self::$map_object_type[$object_type]) checks whether the user can update assets of that type globally, while passing the specific model instance ($object) checks whether the user can update that particular asset. The bug in both app/Http/Controllers/Api/UploadedFilesController.php and app/Http/Controllers/UploadedFilesController.php used the class-level check, meaning any user authorized to edit any asset of a given type could invoke the file deletion endpoint against any asset instance of that type, regardless of who owns it or which company it belongs to. CWE-285 (Improper Authorization) is the root cause - the authorization policy exists but is evaluated at the wrong granularity.
RemediationAI
Upgrade Snipe-IT to version 8.4.1, which resolves the issue via commit 8bc7d50e35d93eee5a0d48b4923e497937cf93fd (https://github.com/grokability/snipe-it/commit/8bc7d50e35d93eee5a0d48b4923e497937cf93fd). The fix changes both UploadedFilesController.php and Api/UploadedFilesController.php to pass the specific model instance to the authorize() call rather than the class string, enforcing instance-level ownership checks. If immediate upgrade is not possible, the most targeted compensating control is to audit and restrict the set of users holding generic asset edit permissions, minimizing the population capable of invoking the file deletion endpoint. In multi-company Snipe-IT deployments, ensure company-scoped user roles are reviewed, as the bypass specifically circumvents company assignment boundaries. There is no known safe configuration option that disables the file attachment feature entirely without also disabling asset management workflows.
Same weakness CWE-285 – Improper Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today