Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-54329

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

CVE-2026-54329 is an authentication bypass flaw in Snipeitapp Snipe-IT that allows low-privileged users to create accessory records across companies. This post covers technical details, affected versions, and patches.

Published:

CVE-2026-54329 Overview

CVE-2026-54329 is a broken access control vulnerability in Snipe-IT, an open-source IT asset and license management system maintained by Grokability. Prior to version 8.6.2, the Accessories API create endpoint mass-assigns request parameters directly to the Accessory model. Because company_id is mass assignable, a low-privileged authenticated user in one company can create accessory records under a different company when Full Multiple Companies Support (FMCS) is enabled. The issue is classified under CWE-862: Missing Authorization and is fixed in Snipe-IT 8.6.2.

Critical Impact

Authenticated tenants can write accessory records into other companies' scopes, breaking the FMCS multi-tenant isolation boundary.

Affected Products

  • Snipe-IT (snipeitapp/snipe-it) versions prior to 8.6.2
  • Deployments with Full Multiple Companies Support (FMCS) enabled
  • Self-hosted Snipe-IT instances exposing the Accessories API to authenticated users

Discovery Timeline

  • 2026-07-10 - CVE-2026-54329 published to the National Vulnerability Database
  • 2026-07-10 - Last updated in NVD database

Technical Details for CVE-2026-54329

Vulnerability Analysis

Snipe-IT supports a multi-tenancy mode called Full Multiple Companies Support (FMCS), which scopes records so users only interact with data belonging to their own company. The Accessories API create controller violates this boundary by passing the entire request payload to the Accessory model constructor. Because the company_id attribute is part of the model's mass-assignable fillable list, an attacker can supply an arbitrary company_id value during accessory creation. The server accepts the input without verifying that the requesting user has authority over the target company.

The result is a horizontal privilege escalation across tenant boundaries. A regular authenticated user in Company A can create accessory inventory records that appear under Company B, polluting another tenant's asset catalog, corrupting inventory reporting, and potentially seeding records that downstream workflows treat as trusted.

Root Cause

The root cause is missing server-side authorization on the company_id field during mass assignment. FMCS scope enforcement was applied inconsistently across API controllers, and the Accessories API did not resolve the effective company_id through the same guardrail used elsewhere (Company::getIdForCurrentUser()). Trusting client-provided tenant identifiers without validation is the underlying defect.

Attack Vector

Exploitation requires only a valid low-privileged API token for the Snipe-IT instance and network access to the /api/v1/accessories endpoint. The attacker issues a POST request with a JSON body containing a company_id value pointing to a company they do not belong to. The application persists the record scoped to that foreign company. No user interaction or elevated permissions are needed.

php
// Security patch in app/Http/Controllers/Api/AccessoriesController.php
// Introduces stricter FMCS enforcement in the API layer
use App\Http\Transformers\SelectlistTransformer;
use App\Models\Accessory;
use App\Models\AccessoryCheckout;
use App\Models\Company;
use App\Models\User;
use Carbon\Carbon;
use Illuminate\Http\JsonResponse;

Source: grokability/snipe-it commit dc8cbf4

php
// Security patch in app/Http/Controllers/Api/LocationsController.php
// Uses Company::getIdForCurrentUser() to override attacker-supplied company_id
if (Setting::getSettings()->scope_locations_fmcs) {
    $location->company_id = Company::getIdForCurrentUser($request->input('company_id'));
    // check if parent is set and has a different company
    if ($location->parent_id && ($parent = Location::find($location->parent_id)) && $parent->company_id != $location->company_id) {
        return response()->json(Helper::formatStandardApiResponse('error', null, trans('general.error_location_parent_company', [
            'parent' => $parent->name,
            'parent_company' => $parent->company?->name ?? trans('general.unassigned'),
            'location_company' => $location->company?->name ?? trans('general.unassigned'),
        ])));
    }
}

Source: grokability/snipe-it commit 6a0ec69

Detection Methods for CVE-2026-54329

Indicators of Compromise

  • Accessory records in the accessories table where the user_id of the creator belongs to a company different from the record's company_id.
  • POST /api/v1/accessories requests containing an explicit company_id parameter originating from non-admin API tokens.
  • Unexpected accessory entries appearing in a tenant's inventory without corresponding audit trail from that tenant's staff.

Detection Strategies

  • Query the Snipe-IT database to join accessories.company_id against users.company_id for the creating user and flag mismatches on records created before upgrading to 8.6.2.
  • Inspect web server access logs for POST requests to the Accessories API and correlate authenticated user identity against the company_id field submitted in the JSON body.
  • Review the action_logs table for accessory creation events and cross-check the acting user's tenant assignment.

Monitoring Recommendations

  • Enable verbose API request logging for all /api/v1/accessories and related asset-creation endpoints.
  • Alert on any API write operations that specify a company_id value differing from the caller's assigned company.
  • Monitor Snipe-IT release announcements and the GHSA-pwpj-p52h-q484 advisory for follow-up guidance.

How to Mitigate CVE-2026-54329

Immediate Actions Required

  • Upgrade Snipe-IT to version 8.6.2 or later, which contains the fix for the mass-assignment flaw.
  • Audit existing accessory records for cross-company entries created by non-admin users and remediate polluted inventory data.
  • Rotate API tokens for low-privileged users if abuse is suspected, and review recent API activity for anomalous company_id values.

Patch Information

The fix is included in the Snipe-IT v8.6.2 release. The relevant upstream commits are 6a0ec69, dc8cbf4, and e2bea57. These changes enforce FMCS scope by resolving the effective company_id server-side through Company::getIdForCurrentUser() and add validation that rejects cross-company references.

Workarounds

  • If upgrading immediately is not possible, disable Full Multiple Companies Support (FMCS) until the patch is applied, since the vulnerability only manifests when FMCS scoping is enabled.
  • Restrict Accessories API access to admin-level users via reverse proxy rules or web application firewall policy while patching is scheduled.
  • Revoke API tokens for users who do not require accessory creation privileges.
bash
# Upgrade Snipe-IT to the fixed 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

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.