CVE-2026-55519: Snipe-IT Auth Bypass Vulnerability

CVE-2026-55519 Overview

CVE-2026-55519 is an insecure direct object reference (IDOR) vulnerability in Snipe-IT, an open source IT asset and license management system. Authenticated users with generic asset edit permission can delete files attached to assets they do not own or that fall outside their company assignment. The flaw resides in the destroy() methods of app/Http/Controllers/Api/UploadedFilesController.php and app/Http/Controllers/UploadedFilesController.php. These controllers authorize the update action against the object class rather than the resolved object instance, bypassing per-object access checks. The issue is fixed in Snipe-IT version 8.4.1 and is tracked under CWE-285: Improper Authorization.

Critical Impact
Authenticated Snipe-IT users can delete file attachments belonging to assets outside their authorization scope, enabling cross-tenant data destruction.

Affected Products

Snipe-IT versions prior to 8.4.1
app/Http/Controllers/Api/UploadedFilesController.php
app/Http/Controllers/UploadedFilesController.php

Discovery Timeline

2026-08-19 - CVE-2026-55519 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-55519

Vulnerability Analysis

Snipe-IT uses Laravel's authorization gates to validate whether a user can perform an action on a target resource. In the vulnerable destroy() methods, the controller resolves the target object by ID and object type, then calls $this->authorize('update', self::$map_object_type[$object_type]). Passing the class name instead of the resolved instance causes Laravel to evaluate the policy against the model class rather than the specific record. As a result, any authenticated user who holds a generic edit permission on the object type passes the check, regardless of ownership or company scope.

The consequence is a cross-scope file deletion primitive. Attackers can enumerate file identifiers and trigger deletion on attachments associated with assets they should not access, causing loss of records, evidence, or license documentation. According to the description, confidentiality is not directly impacted, but integrity and availability of uploaded files are.

Root Cause

The root cause is improper authorization at the object level. Laravel policies can enforce fine-grained rules such as ownership or tenant isolation, but they require an instance argument. By supplying the class, the developer effectively demoted the check to a coarse role-based gate. This pattern matches the definition of an insecure direct object reference combined with CWE-285.

Attack Vector

Exploitation requires an authenticated session with generic asset edit permission. The attacker issues a delete request to the uploaded files endpoint, supplying an object_type and id that correspond to a file outside the attacker's assigned scope. Because authorization is evaluated against the class, the request succeeds and the file is removed.

php

// Security patch in app/Http/Controllers/Api/UploadedFilesController.php
// Source: https://github.com/grokability/snipe-it/commit/8bc7d50e35d93eee5a0d48b4923e497937cf93fd

         // Check the permissions to make sure the user can view the object
         $object = self::$map_object_type[$object_type]::withTrashed()->find($id);
-        $this->authorize('update', self::$map_object_type[$object_type]);
+        $this->authorize('update', $object);

         if (!$object) {
             return response()->json(Helper::formatStandardApiResponse('error', null, trans('general.file_upload_status.invalid_object')));

The fix passes the resolved $object instance to authorize(), forcing Laravel to invoke the policy against the specific record and honor ownership and company assignment rules. The equivalent web controller receives the same one-line correction.

Detection Methods for CVE-2026-55519

Indicators of Compromise

Unexpected DELETE requests to /api/v1/upload/{object_type}/{id} or /uploads/{object_type}/{id} originating from non-privileged accounts.
Snipe-IT audit log entries showing file deletions on assets outside the acting user's assigned company or ownership.
Sudden gaps in asset attachments across multiple asset records tied to a single authenticated user session.

Detection Strategies

Correlate Snipe-IT application logs with user role and company assignments to flag deletions that cross tenant boundaries.
Monitor HTTP request patterns for a single session enumerating sequential id values against the uploaded files endpoints.
Alert on file deletion volume anomalies per user account over short time windows.

Monitoring Recommendations

Enable Laravel request logging and forward Snipe-IT logs to a centralized SIEM for retention and correlation.
Track failed authorization attempts after upgrading to 8.4.1 to identify accounts that were previously abusing the flaw.
Baseline normal file attachment deletion rates per role, then alert on statistical deviations.

How to Mitigate CVE-2026-55519

Immediate Actions Required

Upgrade Snipe-IT to version 8.4.1 or later. See the GitHub Release v8.4.1 notes.
Review recent audit logs for unauthorized file deletions across asset records prior to patching.
Restrict the generic asset edit permission to trusted administrators until the upgrade is completed.

Patch Information

The fix is implemented in commit 8bc7d50 and released in Snipe-IT 8.4.1. Both Api/UploadedFilesController.php and UploadedFilesController.php now call $this->authorize('update', $object) against the resolved instance. Full advisory details are available in GHSA-x667-r589-43m7.

Workarounds

Temporarily revoke the generic asset edit permission from non-administrative roles until patching is complete.
Place a web application firewall rule in front of Snipe-IT that limits DELETE requests to the uploaded files endpoints to administrator IP ranges.
Take frequent backups of the Snipe-IT database and uploaded file directory so any unauthorized deletions can be restored.

bash

# Upgrade Snipe-IT to the patched release
git fetch --tags
git checkout v8.4.1
php artisan down
composer install --no-dev --prefer-source
php artisan migrate --force
php artisan config:clear
php artisan cache:clear
php artisan up