CVE-2026-54329: Snipe-IT Cross-Tenant Accessory Injection via Mass Assignment
A low-privileged user in one company can silently create accessory records under a different company by passing a foreign company_id to the Accessories API, breaking multi-tenant inventory isolation.
The problem
Snipe-IT's Accessories API endpoint (POST /api/v1/accessories) mass-assigns all request body parameters directly to the Accessory model. The Accessory model allows company_id to be mass-assigned, so an attacker from Company A can supply any company_id in the request body.
The web controller correctly calls Company::getIdForCurrentUser() before saving, which pins the record to the authenticated user's own company. The API controller skips this step entirely. With Full Multiple Companies Support (FMCS) enabled, any authenticated API user can inject persistent records into a tenant they do not belong to, and those records appear as legitimate inventory to the victim company.
Proof of concept
POST /api/v1/accessories HTTP/1.1
Host: snipe-it.example.com
Authorization: Bearer <company_a_api_token>
Content-Type: application/json
Accept: application/json
{
"name": "Injected Accessory",
"category_id": 1,
"qty": 10,
"company_id": 2
}The root cause is a missing tenant-enforcement step in the API controller's store() method. The web controller pins company_id with Company::getIdForCurrentUser() before the Accessory model is populated, so user input is ignored. The API controller never calls that function, meaning the ORM happily mass-assigns the attacker-supplied company_id straight into the database row.
The patch (commit dc8cbf4786bb38b260b4ae1723ec9e7f81d82fe5) adds the same Company::getIdForCurrentUser() call to the API controller's store() path, overwriting any company_id the caller supplied. This is CWE-74: injection through a downstream component, here the Eloquent ORM accepting an attacker-controlled field.
The fix
Upgrade to snipe/snipe-it 8.6.2 or later. The fix is in commit dc8cbf4786bb38b260b4ae1723ec9e7f81d82fe5. If an immediate upgrade is not possible, restrict API access for low-privileged users at the network or application layer until the patch is applied. After patching, audit existing accessories for cross-tenant anomalies: compare each accessory's company_id against the company_id of its creator in the users table.
Reported by tahirsercan.