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

CVE-2026-55515 Overview

CVE-2026-55515 is a broken access control vulnerability in Snipe-IT, an open-source IT asset and license management system maintained by Grokability. The flaw affects the unaccepted-assets report delete endpoint, which authorizes callers based only on the reports.view permission and looks up CheckoutAcceptance::pending()->find($acceptanceId) by a global identifier. The endpoint does not verify that the related checkoutable asset belongs to the caller's company, allowing a reports user in one company to delete pending checkout acceptance records belonging to another company. The issue is fixed in Snipe-IT version 8.6.2.

Critical Impact
An authenticated reports user in one tenant company can delete pending checkout acceptance records belonging to any other company, breaking multi-company data isolation and integrity.

Affected Products

Snipe-IT versions prior to 8.6.2
Snipe-IT deployments using the multi-company feature
Any tenant instance exposing the unaccepted-assets report delete endpoint to non-admin reports.view users

Discovery Timeline

2026-07-10 - CVE-2026-55515 published to NVD
2026-07-14 - Last updated in NVD database

Technical Details for CVE-2026-55515

Vulnerability Analysis

The vulnerability is an Insecure Direct Object Reference [CWE-639] in the Snipe-IT reports controller. The delete route for unaccepted-asset acceptance records checks only that the caller holds the reports.view permission. It does not scope the query by company or verify ownership of the associated checkoutable asset.

The controller resolves the acceptance record using CheckoutAcceptance::pending()->find($acceptanceId). Because find() operates on the global primary key without a company-scoped constraint, any authenticated user with report access can supply an arbitrary acceptance ID. Snipe-IT's multi-company scoping normally isolates asset data between tenants, but this endpoint bypasses that boundary.

Exploitation impacts integrity rather than confidentiality. The attacker cannot read cross-company data, but they can destroy pending checkout acceptance records tied to assets owned by other companies. This disrupts asset checkout workflows and audit trails across tenant boundaries.

Root Cause

The root cause is missing authorization on the target object. The controller enforces a permission check on the report itself but omits an ownership or company-scope check on the CheckoutAcceptance model before deletion. Snipe-IT's pending() scope filters by acceptance status, not by company or checkoutable owner.

Attack Vector

An authenticated user with the reports.view privilege in Company A sends a delete request to the unaccepted-assets report endpoint with an acceptanceId belonging to Company B. The application resolves the ID globally, does not validate the caller's access to the related asset, and deletes the record.

The vulnerability manifests in app/Http/Controllers/ReportsController.php. The fix in commit 802067f adds authorization on the related checkoutable before the record is removed. See the GitHub Security Advisory GHSA-35cr-9hqq-p2mg for the vendor's technical description.

Detection Methods for CVE-2026-55515

Indicators of Compromise

Unexpected deletion of checkout_acceptances rows where the related checkoutable belongs to a company different from the acting user's company
HTTP DELETE or POST requests to the unaccepted-assets report endpoint referencing acceptanceId values not associated with the requester's company
Audit log entries showing report users triggering acceptance deletions outside their normal tenant scope

Detection Strategies

Correlate Snipe-IT application logs against the users.company_id field to flag acceptance deletions where the acceptance's asset belongs to a different company
Enable database-level auditing on the checkout_acceptances table and alert on DELETE operations initiated by non-admin roles
Baseline normal report user behavior and alert on spikes in acceptance-deletion actions from a single account

Monitoring Recommendations

Forward Snipe-IT web server access logs and Laravel application logs to a centralized logging platform for retention and query
Monitor for repeated requests iterating sequential acceptanceId values, which suggests enumeration
Review role assignments and identify users granted reports.view who do not require it

How to Mitigate CVE-2026-55515

Immediate Actions Required

Upgrade Snipe-IT to version 8.6.2 or later without delay
Audit checkout_acceptances records for unexpected deletions since the endpoint was exposed
Review users holding the reports.view permission and remove access where not required
Restore any deleted pending acceptance records from backups if cross-company deletion is confirmed

Patch Information

The fix is delivered in Snipe-IT v8.6.2. The remediation is implemented in commit 802067f3987a4b65bfc2efe60e22e07c24e01e6a in app/Http/Controllers/ReportsController.php, which adds an authorization check on the related checkoutable asset before deleting the acceptance record. Release notes are available at the GitHub Release v8.6.2 page.

Workarounds

Restrict the reports.view permission to trusted administrators until the upgrade is applied
Place the Snipe-IT instance behind a web application firewall rule that blocks the unaccepted-assets report delete endpoint for non-admin sessions
Take a database backup of checkout_acceptances prior to upgrade to allow recovery of any records deleted through exploitation

bash

# Upgrade Snipe-IT to the patched release
cd /var/www/snipe-it
git fetch --tags
git checkout v8.6.2
composer install --no-dev --prefer-source
php artisan migrate --force
php artisan config:clear && php artisan cache:clear