{"id":"CVE-2026-86750","aliases":["EUVD-2026-74927","GHSA-c929-qxg6-r3mc","GHSA-v9j9-5xx8-fcxj"],"status":"published","title":"snipe-it before 8.7.0 Authorization Bypass via API User Create/Update","description":"Snipe-IT versions \u003c= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested company_id / company_ids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where null_company_is_floater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a \"floater\" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries.","severity":{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00325,"percentile":0.25885,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-863"],"published":"2026-09-09T13:32:13Z","modified":"2026-10-28T02:30:36Z","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-c929-qxg6-r3mc","tags":["vendor-advisory","Exploit","Vendor Advisory","Mitigation","advisory"]},{"url":"https://www.vulncheck.com/advisories/snipe-it-before-8.7.0-authorization-bypass-via-api-user-create-update","tags":["third-party-advisory","Third Party Advisory","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-86750","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-v9j9-5xx8-fcxj"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/86xxx/CVE-2026-86750.json","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-86750","title":"snipe-it before 8.7.0 Authorization Bypass via API User Create/Update","description":"Snipe-IT versions \u003c= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested company_id / company_ids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where null_company_is_floater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a \"floater\" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries.","status":"published","published":"2026-09-09T13:32:13.49Z","modified":"2026-09-14T13:22:35.512Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N","level":"high","assessor":"cna"},{"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-863"],"updated_at":"2026-11-02T13:49:53.818886Z"}],"euvd":[{"id":"EUVD-2026-74927","description":"Snipe-IT versions \u003c= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested company_id / company_ids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where null_company_is_floater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a \"floater\" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries.","status":"published","published":"2026-09-09T13:32:13Z","modified":"2026-09-14T13:22:35Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N","level":"high"}],"updated_at":"2026-11-02T17:28:20.757989Z"}],"ghsa":[{"id":"GHSA-v9j9-5xx8-fcxj","title":"Snipe-IT versions \u003c= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization...","description":"Snipe-IT versions \u003c= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested company_id / company_ids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where null_company_is_floater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a \"floater\" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries.","status":"published","published":"2026-09-09T15:35:13Z","modified":"2026-09-09T15:35:22Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high"},{"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-863"],"updated_at":"2026-11-02T15:11:38.712835Z"}],"nvd":[{"id":"CVE-2026-86750","description":"Snipe-IT versions \u003c= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested company_id / company_ids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where null_company_is_floater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a \"floater\" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries.","status":"published","published":"2026-09-09T14:17:24.03Z","modified":"2026-09-14T20:30:57.46Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"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-863"],"updated_at":"2026-11-02T14:12:45.93749Z"}],"osv":[{"id":"CVE-2026-86750","title":"snipe-it before 8.7.0 Authorization Bypass via API User Create/Update","description":"Snipe-IT versions \u003c= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested company_id / company_ids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where null_company_is_floater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a \"floater\" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries.","status":"published","published":"2026-09-09T13:32:13.49Z","modified":"2026-10-28T02:30:36.611076346Z","cvss":[{"version":"4.0","score":8.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N","level":"high"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:45:19.210277Z"}]}}