8.5

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-54329

CVE-2026-54329: Snipe-IT: Cross-Tenant Accessory Injection in Snipe-IT API

Snipe-IT is an IT asset/license management system. Prior to 8.6.2, the Accessories API create path mass-assigns request parameters to the Accessory model while company_id is mass assignable, allowing a low-privileged authenticated user in one company to create accessory records under another company when Full Multiple Companies Support is enabled. This issue is fixed in version 8.6.2.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-54329

CVE-2026-54329:

8.5

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
snipe/snipe-it	composer	<= 8.6.1	8.6.2

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability allows a low-privileged authenticated user of one company to create or update assets (like accessories, components, consumables, etc.) and assign them to a different company when Full Multiple Companies Support (FMCS) is enabled. This is a tenant isolation failure.

The root cause is a mass assignment vulnerability in the store and update methods of several API controllers. The code was using $model->fill($request->all()); which blindly assigns all parameters from the incoming API request to the database model. An attacker could include a company_id field in the JSON body of a POST or PATCH request to associate the created/updated object with any company.

The patch addresses this by adding the line $model->company_id = Company::getIdForCurrentUser($request->input('company_id')); after the fill() call. The Company::getIdForCurrentUser() method ensures that the company_id is set to the company of the currently authenticated user, unless the user is a superuser who is allowed to specify a different company. This change enforces tenant separation at the controller level, preventing users from creating or moving assets into companies they do not belong to.

The vulnerability was present in the store and update methods of AccessoriesController, ComponentsController, ConsumablesController, DepartmentsController, and LicensesController. During exploitation, a call to any of these API endpoints would result in the corresponding store or update function appearing in a runtime profile or stack trace.

Vulnerable functions

App\Http\Controllers\Api\AccessoriesController::store

app/Http/Controllers/Api/AccessoriesController.php

The 'store' method was vulnerable to mass assignment. It used '$accessory->fill($request->all())' to populate the Accessory model from the user's request. This allowed a malicious user to set the 'company_id' to a company they do not belong to, thus creating an accessory under another tenant. The patch adds a line to correctly set the company ID based on the current user's context.

App\Http\Controllers\Api\AccessoriesController::update

app/Http/Controllers/Api/AccessoriesController.php

The 'update' method was vulnerable to mass assignment. It used '$accessory->fill($request->all())' to update the Accessory model from the user's request. This allowed a malicious user to change the 'company_id' of an existing accessory to a company they do not belong to, thus moving an accessory to another tenant. The patch adds a line to correctly set the company ID based on the current user's context.

App\Http\Controllers\Api\ComponentsController::store

app/Http/Controllers/Api/ComponentsController.php

The 'store' method in the ComponentsController was vulnerable to the same mass assignment issue as the AccessoriesController. It allowed creating a component under a different company by supplying a 'company_id' in the request. The patch enforces the current user's company.

App\Http\Controllers\Api\ComponentsController::update

app/Http/Controllers/Api/ComponentsController.php

The 'update' method in the ComponentsController was vulnerable to the same mass assignment issue as the AccessoriesController. It allowed moving a component to a different company by supplying a 'company_id' in the request. The patch enforces the current user's company.

App\Http\Controllers\Api\ConsumablesController::store

app/Http/Controllers/Api/ConsumablesController.php

The 'store' method in the ConsumablesController was vulnerable to the same mass assignment issue. It allowed creating a consumable under a different company by supplying a 'company_id' in the request. The patch enforces the current user's company.

App\Http\Controllers\Api\ConsumablesController::update

app/Http/Controllers/Api/ConsumablesController.php

The 'update' method in the ConsumablesController was vulnerable to the same mass assignment issue. It allowed moving a consumable to a different company by supplying a 'company_id' in the request. The patch enforces the current user's company.

App\Http\Controllers\Api\DepartmentsController::store

app/Http/Controllers/Api/DepartmentsController.php

The 'store' method in the DepartmentsController was vulnerable to the same mass assignment issue. It allowed creating a department under a different company by supplying a 'company_id' in the request. The patch enforces the current user's company.

App\Http\Controllers\Api\DepartmentsController::update

app/Http/Controllers/Api/DepartmentsController.php

The 'update' method in the DepartmentsController was vulnerable to the same mass assignment issue. It allowed moving a department to a different company by supplying a 'company_id' in the request. The patch enforces the current user's company.

App\Http\Controllers\Api\LicensesController::store

app/Http/Controllers/Api/LicensesController.php

The 'store' method in the LicensesController was vulnerable to the same mass assignment issue. It allowed creating a license under a different company by supplying a 'company_id' in the request. The patch enforces the current user's company.

App\Http\Controllers\Api\LicensesController::update

app/Http/Controllers/Api/LicensesController.php

The 'update' method in the LicensesController was vulnerable to the same mass assignment issue. It allowed moving a license to a different company by supplying a 'company_id' in the request. The patch enforces the current user's company.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.