EUVD-2026-42982
GHSA-pwpj-p52h-q484
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N
Network API reachable with low-privilege auth and no interaction (AV:N/AC:L/PR:L/UI:N); crossing the tenant boundary justifies S:C with high integrity and no confidentiality/availability impact.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
6DescriptionNVD
Impact
A cross-tenant data injection vulnerability was identified in the Snipe-IT Accessories API when Full Multiple Companies Support (FMCS) is enabled. A low-privileged authenticated user belonging to one company can create an accessory record under another company by supplying a foreign company_id value in the API request body.
The issue occurs because the API create path mass-assigns request parameters directly to the Accessory model, and the Accessory model allows company_id to be mass assigned. Unlike the web controller, which uses Company::getIdForCurrentUser() to enforce the authenticated user’s company context, the API controller does not apply equivalent tenant enforcement during accessory creation.
As a result, a Company A user can inject persistent accessory records into Company B. The injected records are then visible to Company B users as legitimate Company B inventory records. This breaks the integrity of company-scoped inventory data and represents a tenant isolation failure in the accessory creation flow.
Patches
Patched in https://github.com/grokability/snipe-it/commit/dc8cbf4786bb38b260b4ae1723ec9e7f81d82fe5
AnalysisAI
Cross-tenant data injection in the Snipe-IT Accessories API (versions <= 8.6.1) lets a low-privileged authenticated user in one company write persistent accessory records into another company's inventory by supplying a foreign company_id in the API request body. The flaw only manifests when Full Multiple Companies Support (FMCS) is enabled, and it breaks tenant isolation because the API store/update path mass-assigns company_id without the enforcement the web UI applies. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the fix and a regression test are publicly visible in the vendor commit, making the mechanism easy to reproduce.
Technical ContextAI
Snipe-IT is a PHP/Laravel-based open-source IT asset management platform; the affected component is the REST API AccessoriesController (app/Http/Controllers/Api/AccessoriesController.php). Its multi-tenancy feature, FMCS, is meant to scope every record to the authenticated user's company. The root cause is CWE-74 (improper neutralization / injection) expressed as a Laravel mass-assignment problem: the API store() method binds request parameters directly onto the Accessory Eloquent model, and the model whitelists company_id as fillable. The parallel web controller sanitizes this by calling Company::getIdForCurrentUser(), but the API controller omitted that call, so an attacker-supplied company_id survives to persistence. The vendor patch (commit dc8cbf47) adds $accessory->company_id = Company::getIdForCurrentUser($request->input('company_id')) to both store() and update(), and the same fix was applied to Components, Consumables, Departments, and Licenses controllers, indicating the mass-assignment gap spanned multiple API resources.
RemediationAI
Vendor-released patch: upgrade to Snipe-IT 8.6.2 or later (https://github.com/grokability/snipe-it/releases/tag/v8.6.2), which enforces Company::getIdForCurrentUser() on API create and update for accessories, components, consumables, departments, and licenses (fix commit https://github.com/grokability/snipe-it/commit/dc8cbf4786bb38b260b4ae1723ec9e7f81d82fe5); see advisory https://github.com/grokability/snipe-it/security/advisories/GHSA-pwpj-p52h-q484. If you cannot upgrade immediately, the most direct compensating control is to disable Full Multiple Companies Support, which fully removes the attack surface but collapses tenant separation and is disruptive for genuinely multi-company deployments. Otherwise, restrict or revoke API token issuance and accessory-create permissions for untrusted low-privilege users, and monitor accessory/component/consumable/department/license records for entries whose company_id does not match the creating user's company. Because this is server-side authorization logic, a WAF cannot reliably distinguish a malicious company_id from a legitimate one, so upgrading remains the only complete fix.
Same technique Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today