{"id":"CVE-2026-55516","aliases":["EUVD-2026-42984","GHSA-575r-357h-fhch"],"status":"published","title":"Snipe-IT: Cross-company asset maintenance re-parenting via API update","description":"Snipe-IT is an IT asset/license management system. Prior to 8.6.2, PATCH or PUT /api/v1/maintenances/{maintenance_id} checks access to the current maintenance record and asset but then fills attacker-controlled fields including asset_id without re-authorizing the newly supplied asset, allowing an authorized user to move a maintenance record onto an asset outside their company scope. This issue is fixed in version 8.6.2.","severity":{"version":"3.1","score":7.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00376,"percentile":0.31836,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-639"],"published":"2026-07-10T18:31:57Z","modified":"2026-10-28T02:30:42Z","fixes":[{"ecosystem":"Packagist","package":"snipe/snipe-it","fixed_in":["8.6.2"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Packagist","package":"snipe/snipe-it","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"8.6.1"},{"fixed":"8.6.2"}]}]},{"source":"osv","ecosystem":"Packagist","package":"snipe/snipe-it","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"8.6.2"}]}],"versions":["3.2.0","v0.1.0","v0.1.1","v0.1.2","v0.2.0","v0.3.0-alpha","v0.3.10-alpha","v0.3.11-alpha","v0.3.7-alpha","v0.3.8-alpha","v0.3.9-alpha","v1.0","v1.1","v1.2.0","v1.2.1","v1.2.10","v1.2.11","v1.2.2","v1.2.3","v1.2.3-beta","v1.2.4","v1.2.4-beta","v1.2.5","v1.2.6","v1.2.6-beta","v1.2.6.1","v1.2.7","v1.2.7-beta","v1.2.8","v1.2.9","v2.0","v2.0-RC-1","v2.0-beta","v2.0.1","v2.0.2","v2.0.3","v2.0.4","v2.0.5","v2.0.6","v2.1.0","v2.1.1","v2.1.2","v3.0","v3.0-alpha","v3.0-alpha2","v3.0-beta.1","v3.0-beta.2","v3.0-beta.3","v3.0.0-beta","v3.1.0","v3.3.0","v3.3.0-beta","v3.4","v3.4.0-alpha","v3.4.0-beta","v3.5.0","v3.5.0-beta","v3.5.0-beta2","v3.5.1","v3.5.2","v3.6.0","v3.6.1","v3.6.2","v3.6.3","v3.6.4","v3.6.5","v3.6.6","v4-beta3","v4-beta4","v4.0","v4.0-alpha","v4.0-alpha-2","v4.0-beta","v4.0-beta2","v4.0-beta5","v4.0-beta6","v4.0.1","v4.0.10","v4.0.11","v4.0.12","v4.0.13","v4.0.14","v4.0.15","v4.0.2","v4.0.3","v4.0.4","v4.0.5","v4.0.6","v4.0.7","v4.0.8","v4.0.9","v4.1.0","v4.1.0-beta","v4.1.0-beta2","v4.1.1","v4.1.10","v4.1.11","v4.1.12","v4.1.13","v4.1.14","v4.1.2","v4.1.3","v4.1.4","v4.1.5","v4.1.6","v4.1.7","v4.1.8","v4.1.9","v4.2.0","v4.3.0","v4.4.0","v4.4.1","v4.5.0","v4.6.0","v4.6.1","v4.6.10","v4.6.11","v4.6.12","v4.6.13","v4.6.14","v4.6.15","v4.6.16","v4.6.17","v4.6.18","v4.6.2","v4.6.3","v4.6.4","v4.6.5","v4.6.6","v4.6.7","v4.6.8","v4.6.9","v4.7.0","v4.7.1","v4.7.2","v4.7.3","v4.7.4","v4.7.5","v4.7.6","v4.7.7","v4.7.8","v4.8.0","v4.9.0","v4.9.1","v4.9.2","v4.9.3","v4.9.4","v4.9.5","v5.0.0","v5.0.0-beta-1.0","v5.0.0-beta-1.1","v5.0.0-beta-2","v5.0.0-beta-3.0","v5.0.0-beta-4","v5.0.0-beta-5","v5.0.1","v5.0.10","v5.0.11","v5.0.12","v5.0.2","v5.0.3","v5.0.4","v5.0.5","v5.0.6","v5.0.7","v5.0.8","v5.0.9","v5.1.0","v5.1.1","v5.1.2","v5.1.3","v5.1.4","v5.1.5","v5.1.6","v5.1.7","v5.1.8","v5.2.0","v5.3.0","v5.3.1","v5.3.10","v5.3.2","v5.3.3","v5.3.4","v5.3.5","v5.3.6","v5.3.7","v5.3.8","v5.3.9","v5.4.0","v5.4.1","v5.4.2","v5.4.3","v5.4.4","v6.0.0","v6.0.0-RC-1","v6.0.0-RC-2","v6.0.0-RC-3","v6.0.0-RC-4","v6.0.0-RC-5","v6.0.0-RC-6","v6.0.0-RC-7","v6.0.0-RC-8","v6.0.1","v6.0.10","v6.0.11","v6.0.12","v6.0.13","v6.0.14","v6.0.2","v6.0.3","v6.0.4","v6.0.5","v6.0.6","v6.0.7","v6.0.8","v6.0.9","v6.1.0","v6.1.1","v6.1.2","v6.2.0","v6.2.1","v6.2.2","v6.2.3","v6.3.0","v6.3.1","v6.3.2","v6.3.3","v6.3.4","v6.4.0","v6.4.1","v6.4.2","v7.0.0","v7.0.1","v7.0.10","v7.0.11","v7.0.12","v7.0.13","v7.0.2","v7.0.3","v7.0.4","v7.0.5","v7.0.6","v7.0.7","v7.0.8","v7.0.9","v7.1.14","v7.1.15","v7.1.16","v7.1.17","v8.0.0","v8.0.1","v8.0.2","v8.0.3","v8.0.4","v8.1.0","v8.1.1","v8.1.15","v8.1.16","v8.1.17","v8.1.18","v8.1.2","v8.1.3","v8.1.4","v8.2.0","v8.2.1","v8.3.0","v8.3.1","v8.3.2","v8.3.3","v8.3.4","v8.3.5","v8.3.6","v8.3.7","v8.4.0","v8.4.1","v8.5.0","v8.6.0","v8.6.1"]}],"products":[{"vendor":"grokability","product":"snipe-it"},{"vendor":"grokability, inc.","product":"snipe-it"},{"vendor":"snipeitapp","product":"snipe-it"}],"references":[{"url":"https://github.com/grokability/snipe-it/security/advisories/GHSA-575r-357h-fhch","tags":["x_refsource_CONFIRM","Patch","Vendor Advisory","advisory","web"]},{"url":"https://github.com/grokability/snipe-it/commit/905d498ecdb0ee5591231c97bf48435e92044368","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/grokability/snipe-it/releases/tag/v8.6.2","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55516","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-575r-357h-fhch"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55516.json","tags":["advisory"]},{"url":"https://github.com/grokability/snipe-it","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-55516","title":"Snipe-IT: Cross-company asset maintenance re-parenting via API update","description":"Snipe-IT is an IT asset/license management system. Prior to 8.6.2, PATCH or PUT /api/v1/maintenances/{maintenance_id} checks access to the current maintenance record and asset but then fills attacker-controlled fields including asset_id without re-authorizing the newly supplied asset, allowing an authorized user to move a maintenance record onto an asset outside their company scope. This issue is fixed in version 8.6.2.","status":"published","published":"2026-07-10T18:31:57.507Z","modified":"2026-07-14T13:42:33.155Z","cvss":[{"version":"3.1","score":7.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"high","assessor":"cna"}],"cwes":["CWE-639"],"updated_at":"2026-11-02T14:20:11.925815Z"}],"euvd":[{"id":"EUVD-2026-42984","description":"Snipe-IT is an IT asset/license management system. Prior to 8.6.2, PATCH or PUT /api/v1/maintenances/{maintenance_id} checks access to the current maintenance record and asset but then fills attacker-controlled fields including asset_id without re-authorizing the newly supplied asset, allowing an authorized user to move a maintenance record onto an asset outside their company scope. This issue is fixed in version 8.6.2.","status":"published","published":"2026-07-10T18:31:57Z","modified":"2026-07-14T13:42:33Z","cvss":[{"version":"3.1","score":7.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T18:20:00.206712Z"}],"ghsa":[{"id":"GHSA-575r-357h-fhch","title":"Snipe-IT vulnerable to cross-company asset maintenance re-parenting via API update","description":"### Impact\nThe API endpoint for updating asset maintenance records allows an authorized user to change the asset_id of an existing maintenance record to an asset outside their company scope.\n\nIn a Full Multiple Company Support / multi-company deployment, this allows a user from Company A to attach or move a maintenance record onto an asset belonging to Company B. The endpoint appears to authorize access to the existing maintenance record’s asset, but does not re-authorize the newly supplied asset_id before saving the update.\n\n###  Affected endpoint\n`PATCH /api/v1/maintenances/{maintenance_id}`\n\nAlso likely affected:\n\n`PUT /api/v1/maintenances/{maintenance_id}`\n\n### Preconditions\nThe attacker needs:\n- A valid authenticated API token.\n- Permission to update asset maintenance records.\n- Access to a maintenance record currently attached to an asset in their own company.\n\nThe attacker does not need access to the target asset’s company.\n\n### Root cause\nIn the API maintenance update flow, the application checks access to the current maintenance record / current asset, then accepts attacker-controlled fields including `asset_id`.\n\nThe vulnerable behavior is that the new asset_id is not checked against the current user’s company scope before being saved.\n\n### Relevant code path:\n`app/Http/Controllers/Api/MaintenancesController.php`\n\nThe update method loads the maintenance, checks access to the existing $maintenance-\u003easset, then calls:\n```php\n$maintenance-\u003efill($request-\u003eall());\n$maintenance-\u003esave();\n```\n\nSince `asset_id` is fillable on the maintenance model, the attacker can re-parent the record to another company’s asset.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n### Security impact\nThis breaks tenant/company isolation in multi-company deployments. A scoped user can write maintenance records against assets outside their authorized company boundary.\n\nPotential impact includes:\n- Cross-company asset history pollution.\n- Unauthorized modification of another company’s asset maintenance timeline.\n- Incorrect maintenance, cost, audit, and warranty records on victim-company assets.\n- Loss of integrity in asset lifecycle records.\n\nThis is not intended functionality because the application’s company-scoping model should prevent users from writing records onto inaccessible assets.","status":"published","published":"2026-08-28T18:06:05Z","modified":"2026-08-28T18:06:06Z","cvss":[{"version":"3.1","score":7.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"high"}],"cwes":["CWE-639"],"updated_at":"2026-11-02T14:41:07.031507Z"}],"nvd":[{"id":"CVE-2026-55516","description":"Snipe-IT is an IT asset/license management system. Prior to 8.6.2, PATCH or PUT /api/v1/maintenances/{maintenance_id} checks access to the current maintenance record and asset but then fills attacker-controlled fields including asset_id without re-authorizing the newly supplied asset, allowing an authorized user to move a maintenance record onto an asset outside their company scope. This issue is fixed in version 8.6.2.","status":"published","published":"2026-07-10T19:17:25.71Z","modified":"2026-10-25T15:10:00.147Z","cvss":[{"version":"3.1","score":7.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"high","assessor":"secondary"}],"cwes":["CWE-639"],"updated_at":"2026-11-02T14:12:28.771746Z"}],"osv":[{"id":"CVE-2026-55516","title":"Snipe-IT: Cross-company asset maintenance re-parenting via API update","description":"Snipe-IT is an IT asset/license management system. Prior to 8.6.2, PATCH or PUT /api/v1/maintenances/{maintenance_id} checks access to the current maintenance record and asset but then fills attacker-controlled fields including asset_id without re-authorizing the newly supplied asset, allowing an authorized user to move a maintenance record onto an asset outside their company scope. This issue is fixed in version 8.6.2.","status":"published","published":"2026-07-10T18:31:57.507Z","modified":"2026-10-28T02:30:42.724365478Z","cvss":[{"version":"3.1","score":7.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"high"}],"cwes":["CWE-639"],"updated_at":"2026-11-02T15:45:11.22012Z"},{"id":"GHSA-575r-357h-fhch","title":"Snipe-IT vulnerable to cross-company asset maintenance re-parenting via API update","description":"### Impact\nThe API endpoint for updating asset maintenance records allows an authorized user to change the asset_id of an existing maintenance record to an asset outside their company scope.\n\nIn a Full Multiple Company Support / multi-company deployment, this allows a user from Company A to attach or move a maintenance record onto an asset belonging to Company B. The endpoint appears to authorize access to the existing maintenance record’s asset, but does not re-authorize the newly supplied asset_id before saving the update.\n\n###  Affected endpoint\n`PATCH /api/v1/maintenances/{maintenance_id}`\n\nAlso likely affected:\n\n`PUT /api/v1/maintenances/{maintenance_id}`\n\n### Preconditions\nThe attacker needs:\n- A valid authenticated API token.\n- Permission to update asset maintenance records.\n- Access to a maintenance record currently attached to an asset in their own company.\n\nThe attacker does not need access to the target asset’s company.\n\n### Root cause\nIn the API maintenance update flow, the application checks access to the current maintenance record / current asset, then accepts attacker-controlled fields including `asset_id`.\n\nThe vulnerable behavior is that the new asset_id is not checked against the current user’s company scope before being saved.\n\n### Relevant code path:\n`app/Http/Controllers/Api/MaintenancesController.php`\n\nThe update method loads the maintenance, checks access to the existing $maintenance-\u003easset, then calls:\n```php\n$maintenance-\u003efill($request-\u003eall());\n$maintenance-\u003esave();\n```\n\nSince `asset_id` is fillable on the maintenance model, the attacker can re-parent the record to another company’s asset.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n### Security impact\nThis breaks tenant/company isolation in multi-company deployments. A scoped user can write maintenance records against assets outside their authorized company boundary.\n\nPotential impact includes:\n- Cross-company asset history pollution.\n- Unauthorized modification of another company’s asset maintenance timeline.\n- Incorrect maintenance, cost, audit, and warranty records on victim-company assets.\n- Loss of integrity in asset lifecycle records.\n\nThis is not intended functionality because the application’s company-scoping model should prevent users from writing records onto inaccessible assets.","status":"published","published":"2026-08-28T18:06:05Z","modified":"2026-08-28T18:15:06.223118687Z","cvss":[{"version":"3.1","score":7.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"high"}],"cwes":["CWE-639"],"updated_at":"2026-11-02T15:46:37.864461Z"}]}}