snipe-it before 8.7.0 Authorization Bypass via API User Create/Update
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| grokability | snipe-it | unaffected |
|
No data.
| Vendor | Product | Versions | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Snipeitapp | Snipe-it |
|
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.325% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Snipe-IT versions <= 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. | |
| Title | snipe-it before 8.7.0 Authorization Bypass via API User Create/Update | |
| First Time appeared |
Snipeitapp
Snipeitapp snipe-it |
|
| Weaknesses | CWE-863 | |
| CPEs | cpe:2.3:a:snipeitapp:snipe-it:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Snipeitapp
Snipeitapp snipe-it |
|
| References |
| |
| Metrics |
cvssV3_1
|