CVE-2026-55516: 
NixOS 脆弱性の分析と軽減

CVE-2026-55516 is an authorization bypass vulnerability in Snipe-IT, an open-source IT asset and license management system. The flaw affects all versions prior to 8.6.2 and allows an authenticated user with maintenance management permissions to reassign a maintenance record to an asset outside their authorized company scope by supplying an arbitrary asset_id in an API update request. It was disclosed on June 24, 2026 via a GitHub Security Advisory and published to NVD on July 10, 2026. The vulnerability carries a CVSS v3.1 base score of 7.7 (High) (GitHub Advisory, Feedly).

The root cause is an Authorization Bypass Through User-Controlled Key (CWE-639) in app/Http/Controllers/Api/MaintenancesController.php. The update() method correctly checks whether the requesting user has access to the existing maintenance record's asset, but then calls $maintenance->fill($request->all()) — which includes the attacker-supplied asset_id field — without re-validating the new asset against the user's company scope before saving. Because asset_id is a fillable attribute on the Maintenance model, an attacker can supply any valid asset ID belonging to a different company and the record will be persisted without further authorization checks. The affected endpoints are PATCH /api/v1/maintenances/{maintenance_id} and PUT /api/v1/maintenances/{maintenance_id} (GitHub Advisory, Patch Commit).

Successful exploitation breaks tenant isolation in Full Multiple Company Support (FMCS) / multi-company Snipe-IT deployments. An attacker from Company A can attach or move maintenance records onto assets belonging to Company B, corrupting that company's asset maintenance history, cost tracking, audit trails, and warranty records. There is no confidentiality or availability impact; the impact is entirely on data integrity across company boundaries (GitHub Advisory).

1. Obtain credentials: Acquire a valid Snipe-IT API token for an account that has permission to edit asset maintenance records within at least one company (Company A).
2. Identify a target maintenance record: Query GET /api/v1/maintenances to enumerate maintenance records accessible to the attacker's account and note a maintenance_id attached to an asset in Company A.
3. Identify a target asset in another company: Enumerate or guess an asset_id belonging to Company B (e.g., via GET /api/v1/hardware if the token has broader read access, or by brute-forcing sequential IDs).
4. Send a malicious PATCH request: Issue a PATCH /api/v1/maintenances/{maintenance_id} request with the asset_id field set to the target asset in Company B:

   PATCH /api/v1/maintenances/42
   Authorization: Bearer <api_token>
   Content-Type: application/json
   
   {"asset_id": 999, "name": "Injected Maintenance"}

5. Verify re-parenting: Confirm the maintenance record now appears on Company B's asset by querying GET /api/v1/maintenances/42, observing the updated asset_id in the response — demonstrating successful cross-company boundary violation (GitHub Advisory, Patch Commit).

• Network/API Logs: PATCH or PUT requests to /api/v1/maintenances/{id} where the asset_id in the request body differs from the asset currently associated with that maintenance record, especially if the new asset_id belongs to a different company.
• Application Logs: Snipe-IT audit log entries showing a maintenance record's asset_id changed to an asset in a different company scope than the authenticated user's company.
• Database: Maintenance records in the maintenances table where the asset_id foreign key references an asset whose company_id does not match the company of the user who last modified the record (updated_by field).
• Behavioral: Repeated API calls from a single token iterating over sequential asset_id values in maintenance update requests, suggesting enumeration of cross-company assets (GitHub Advisory).

Upgrade Snipe-IT to version 8.6.2 or later, which introduces a re-authorization check on the newly supplied asset_id before saving, using Company::isCurrentUserHasAccess($newAsset) (Patch Commit, Release Notes). For deployments that cannot upgrade immediately, restrict API access to the maintenance update endpoints (PATCH/PUT /api/v1/maintenances/*) to only trusted administrators via network-level controls or API gateway policies, and implement monitoring on requests that modify the asset_id field. Note that this vulnerability only has meaningful impact in multi-company (FMCS) deployments; single-company deployments face no cross-tenant risk.

The vulnerability was reported by security researcher 5h1kh4r and credited in the GitHub Security Advisory (GitHub Advisory). The Snipe-IT maintainer (snipe) addressed the issue promptly in the v8.6.2 release, noting general security improvements as a reason to upgrade even for users unaffected by other changes (Release Notes). Social media activity was limited to automated CVE notification accounts on Bluesky and Mastodon shortly after disclosure.