Listen to this Post
How CVE-2026-54329 Works
Snipe-IT is a popular open‑source IT asset and license management system. It supports a “Full Multiple Companies Support” (FMCS) feature that isolates inventory data by company – users from Company A should only see and manage assets belonging to Company A. CVE‑2026‑54329 breaks this isolation in the Accessories API.
The vulnerability resides in the API endpoint that creates new accessory records. Prior to version 8.6.2, this endpoint uses a mass‑assignment pattern: it takes all parameters from the incoming JSON request and directly assigns them to the Accessory model without explicit filtering or validation. Among these parameters is company_id, which determines which company the accessory belongs to. Because `company_id` is marked as “mass assignable” in the Eloquent model, the API blindly accepts whatever value is provided.
In the normal web interface (the non‑API controller), the application enforces tenant context by calling `Company::getIdForCurrentUser()` – it reads the company of the currently authenticated user and uses that value internally, ignoring any user‑supplied company_id. The API controller, however, does not perform this check. It takes the `company_id` straight from the request body and saves it to the database. This means that an authenticated attacker with only low privileges (e.g., a standard user in Company A) can send a crafted POST request to the accessory creation endpoint, setting `company_id` to the numeric identifier of any other company (e.g., Company B).
The API does not verify that the supplied `company_id` matches the company of the authenticated user. As a result, the accessory record is created in the database with company_id = B, and from that moment on it appears as a legitimate inventory item to all users of Company B. The attacker can inject arbitrary accessory data – names, serial numbers, quantities, etc. – into a tenant they do not belong to. This is a classic cross‑tenant data injection flaw, also categorised under CWE‑862 (Missing Authorization).
The impact is strictly on integrity (no confidentiality breach, and only limited availability impact), but the ability to pollute another company’s asset inventory with fake or misleading records can have serious operational consequences. The vulnerability is exploitable over the network, requires no user interaction, and needs only low‑privileged credentials, making it a High severity issue (CVSS 8.5). The fix in version 8.6.2 removes `company_id` from the mass‑assignable attributes or adds proper tenant validation in the API controller, ensuring that the company context is always derived from the authenticated session.
DailyCVE Form:
| Field | Value |
|-|-|
| Platform | Snipe‑IT |
| Version | < 8.6.2 |
| Vulnerability | Cross‑Tenant Accessory Injection |
| Severity | High (CVSS 8.5) |
| Date | 2026‑07‑10 |
| Prediction | Already patched (8.6.2) |
What Undercode Say
Analytics & Telemetry
- Affected endpoints: `POST /api/v1/accessories`
– Attack vector: Network (AV:N) - Privileges required: Low (PR:L)
- User interaction: None (UI:N)
- Scope: Changed (S:C) – the vulnerability affects resources beyond the attacker’s tenant
- Integrity impact: High (I:H)
- Availability impact: Low (A:L)
Bash / cURL Proof‑of‑Concept
Replace TOKEN with a valid API token of a low‑privileged user from Company A
Replace COMPANY_B_ID with the numeric ID of the target company
curl -X POST https://snipe-it.example.com/api/v1/accessories \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Injected Accessory",
"company_id": 2,
"category_id": 1,
"qty": 10,
"notes": "Cross‑tenant injection"
}'
Code Snippet (Vulnerable Mass‑Assignment)
// Vulnerable controller logic (simplified)
public function store(Request $request) {
$accessory = new Accessory();
$accessory->fill($request->all()); // mass‑assigns company_id
$accessory->save();
}
Patched Code (Tenant Enforcement)
// Fixed controller logic
public function store(Request $request) {
$accessory = new Accessory();
$accessory->fill($request->except('company_id'));
$accessory->company_id = Company::getIdForCurrentUser(); // enforce tenant
$accessory->save();
}
Exploit
An attacker with a valid account in any company (e.g., Company A) can:
1. Obtain an API token (or use session‑based authentication) for the Snipe‑IT instance.
2. Craft a POST request to `/api/v1/accessories` with a JSON payload that includes a `company_id` value belonging to another company (Company B).
3. Send the request – the API accepts it without validating that the user has permission to create records for Company B.
4. The accessory is created in the database with company_id = B. Users of Company B now see this item in their inventory, believing it to be legitimate.
5. The attacker can repeat this to inject multiple fake records, potentially causing confusion, misreporting, or even denial of service if inventory limits are exceeded.
No special privileges are required – the attacker only needs to be an authenticated user. The vulnerability does not leak any data, but it corrupts the integrity of the target company’s asset database.
Protection
- Immediate: Upgrade to Snipe‑IT version 8.6.2 or later. This release removes the mass‑assignment vulnerability and enforces proper tenant context in the API controller.
- Workaround (if upgrade is not possible): Disable the Full Multiple Companies Support (FMCS) feature if your deployment does not strictly require multi‑tenant isolation. However, this is not a complete fix; upgrading is strongly recommended.
- Network‑level: Restrict API access to trusted IP ranges or use a Web Application Firewall (WAF) to block requests that contain a `company_id` parameter different from the authenticated user’s company (if the WAF can inspect JWT or session data).
- Code‑level: If you maintain a fork, ensure that all API endpoints that accept `company_id` validate it against the current user’s company context, and avoid mass‑assigning sensitive foreign keys.
Impact
- Integrity Breach: An attacker can inject arbitrary accessory records into any other company’s inventory, polluting asset data and undermining trust in the system.
- Operational Disruption: Affected companies may see incorrect stock levels, misclassified items, or phantom assets, leading to faulty decision‑making and wasted resources.
- Audit & Compliance: In regulated environments, unauthorised data injection can violate data integrity policies and complicate audits.
- Supply‑Chain Risk: If Snipe‑IT is used to track hardware or licenses across multiple business units, injected records could cause physical asset mismanagement.
- Lateral Movement: While this CVE does not directly grant administrative access, it could be combined with other vulnerabilities (e.g., CVE‑2026‑48507) to escalate privileges or lock out admins, compounding the overall risk.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
