CVE-2026-86765: Snipe-IT Authorization Bypass Vulnerability

CVE-2026-86765 Overview

CVE-2026-86765 is a missing authorization vulnerability [CWE-862] in Snipe-IT, an open-source IT asset management application. Versions before 8.7.0 fail to enforce checkout authorization when assignment fields are sent to the asset update endpoint. Authenticated users with edit permission but explicitly denied checkout permission can reassign assets, bypass check-in procedures, and modify custody records. The flaw is triggered by submitting assigned_user, assigned_asset, or assigned_location parameters to PATCH /api/v1/hardware/{id}.

Critical Impact
Authenticated users bypass explicit checkout permission denials to reassign assets and alter custody records through the hardware update API.

Affected Products

Snipe-IT versions prior to 8.7.0
Snipe-IT 8.6.3 (confirmed vulnerable per VulnCheck advisory)
Snipe-IT REST API endpoint PATCH /api/v1/hardware/{id}

Discovery Timeline

2026-09-09 - CVE-2026-86765 published to NVD
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-86765

Vulnerability Analysis

Snipe-IT enforces separate permissions for editing an asset and checking it out to a user, asset, or location. The asset update endpoint validates the edit permission but does not re-validate checkout authorization when assignment fields are present in the request payload. As a result, an authenticated user with edit rights but without checkout rights can change the custody of an asset by sending assignment fields through the update flow rather than the dedicated checkout flow. This bypasses the intended separation of duties and corrupts asset custody records without producing a proper checkout audit trail.

Root Cause

The root cause is a missing authorization check [CWE-862] on the assignment fields inside the hardware update handler. The controller trusts that any caller passing the edit permission gate may write any updatable attribute, including assigned_user, assigned_asset, and assigned_location. There is no secondary policy check confirming the caller also holds the checkout permission before these fields are persisted.

Attack Vector

An attacker with a valid API token or session and edit rights on hardware issues a PATCH request to /api/v1/hardware/{id} containing one of the assignment fields. The server writes the new assignee without invoking the checkout workflow, skipping check-in procedures and custody logging. Exploitation requires low privileges, no user interaction, and is executable over the network.

php

// Related security patch context - concurrency and checkout API hardening
// Source: https://github.com/grokability/snipe-it/commit/f71806b1e0efbd3bc2b6be61994ad2a5d5d6c206
 use Illuminate\Contracts\View\View;
 use Illuminate\Http\RedirectResponse;
 use Illuminate\Http\Request;
+use Illuminate\Support\Facades\DB;

 class AccessoryCheckoutController extends Controller
 {

The upstream commit also hardens checkout APIs against concurrency issues by wrapping assignment writes in a locked transaction:

php

// Source: https://github.com/grokability/snipe-it/commit/f71806b1e0efbd3bc2b6be61994ad2a5d5d6c206
DB::transaction(function () use ($accessory, $request, $target, &$payload, &$overAllocated): void {
    $locked = Accessory::whereKey($accessory->id)->lockForUpdate()->first();

    if (! $locked || $locked->numRemaining() < $accessory->checkout_qty) {
        $overAllocated = true;

        return;
    }

    for ($i = 0; $i < $accessory->checkout_qty; $i++) {
        $accessory_checkout = new AccessoryCheckout([
            // ...
        ]);
    }
});

Detection Methods for CVE-2026-86765

Indicators of Compromise

PATCH requests to /api/v1/hardware/{id} containing assigned_user, assigned_asset, or assigned_location fields originating from accounts without checkout permission.
Asset custody changes present in the database without corresponding entries in the checkout audit log.
API activity from user accounts whose role explicitly denies checkout but shows successful asset reassignments.

Detection Strategies

Review web server and application logs for PATCH /api/v1/hardware/ traffic and correlate the calling user's permission set against the payload fields.
Reconcile the assets.assigned_to column against the checkout history table to surface assignments with no matching checkout event.
Alert when API tokens tied to low-privilege roles issue hardware update calls that include assignment parameters.

Monitoring Recommendations

Forward Snipe-IT application and reverse-proxy logs to a centralized log platform for query and retention.
Monitor for spikes in hardware update calls following role or permission changes.
Track token issuance and usage for accounts flagged as read-only or edit-only.

How to Mitigate CVE-2026-86765

Immediate Actions Required

Upgrade Snipe-IT to version 8.7.0 or later on all production and staging instances.
Audit user roles and revoke edit permissions from accounts that should not modify assignments until the patch is applied.
Rotate API tokens belonging to users whose permission model may have been abused during the exposure window.
Reconcile asset custody records against checkout history and correct any unauthorized reassignments.

Patch Information

The issue is resolved in Snipe-IT 8.7.0. Details are published in the GitHub Security Advisory GHSA-6g2g-83pc-6365 and the VulnCheck Advisory for Snipe-IT. The upstream fix is available in the GitHub Commit Change.

Workarounds

Restrict network access to /api/v1/hardware/ endpoints to trusted administrative networks through a reverse proxy or WAF rule.
Deploy a WAF rule that blocks PATCH requests to /api/v1/hardware/{id} when they contain assigned_user, assigned_asset, or assigned_location fields from non-privileged sources.
Temporarily remove edit permission from any role that must not perform checkouts until upgrading to 8.7.0.

bash

# Example NGINX rule to block assignment fields on hardware PATCH for non-admin sources
location ~ ^/api/v1/hardware/[0-9]+$ {
    if ($request_method = PATCH) {
        set $block "0";
        if ($request_body ~* "assigned_(user|asset|location)") { set $block "1"; }
        if ($remote_addr !~ ^10\.0\.0\.) { set $block "${block}1"; }
        if ($block = "11") { return 403; }
    }
    proxy_pass http://snipeit_backend;
}