CVE Alert: CVE-2026-86750 – grokability – snipe

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.

**Risk verdict:** High risk for multi-tenant deployments: the network-reachable authorisation flaw enables a low-privilege authenticated user to alter tenant ownership, although active exploitation cannot be confirmed because KEV, SSVC, EPSS and PoC indicators are not provided.

**Why this matters:** Successful abuse can create or relocate accounts across company boundaries, undermining tenant isolation and the integrity of user administration. Likely attacker goals include gaining cross-organisation access, establishing persistence through rogue accounts, or manipulating asset-management records to support fraud or further intrusion.

**Most likely attack path:** An attacker needs valid credentials with user-creation or user-editing privileges, but AV:N, AC:L, PR:L and UI:N mean exploitation can be performed remotely through the API without user interaction. Scope is changed: a compromised account in one company may affect identities and access relationships belonging to other companies, particularly where multi-company support and “floater” behaviour are enabled.

**Who is most exposed:** Internet-accessible or broadly reachable instances supporting multiple companies, delegated administrators, service-desk teams, or federated customer environments are the highest-priority targets. Deployments permitting null-company users warrant particular scrutiny.

Review API audit logs for user create/update requests containing unexpected company identifiers.

Identify accounts created or modified by non-superusers across tenant boundaries.

Hunt for newly created “floater” accounts and mixed permitted/foreign company assignments.

Compare user records, company pivots and administrative activity before and after suspicious requests.

Mitigation and prioritisation:

Upgrade promptly to the vendor-fixed release; treat as a high-priority application patch.

Temporarily restrict API access and user-management permissions to trusted administrators.

Disable multi-company or floater functionality where operationally feasible.

Review and reconcile affected accounts, tokens and sessions; apply changes through controlled change management.

Obtain KEV, SSVC, EPSS and PoC status to refine urgency and exploitation assessment.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.