CVE-2026-86760: snipe-it 8.2.0 before 8.7.0 Authentication Bypass via activated flag
Snipe-IT versions 8.2.0 through 8.6.x (fixed in 8.7.0) contain an incorrect authorization flaw in app/Http/Controllers/Users/UsersController::update(). The single-user edit route assigned the activated field from the request payload before evaluating the canEditAuthFields authorization gate, so an authenticated non-admin user holding the users.edit permission in the target's company scope can submit a full valid PUT request to /users/{id} and toggle the activated flag on any user, including admin and superuser accounts. Deactivating an admin locks that account out of the application until another admin or superuser re-enables it. Only the activated field is affected; username, email, password and permissions remain protected by the gate, no data is disclosed, and the API (Api\UsersController::update) and bulk-edit paths are not affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
snipe-itto a version that resolves this vulnerability.Fixed in 8.7.0 - Compensating control
Restrict access to the single-user edit endpoint PUT /users/{id} (UsersController::update) so only trusted admin/superuser accounts can update the 'activated' field.
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated non-admin user must have the users.edit permission within the target user's company scope. The attacker can target any user in that scope, including administrator and superuser accounts.
What is required to trigger the unauthorized account state change?
The attacker must send a full valid PUT request to the single-user /users/{id} edit route with an activated value. The API update endpoint and bulk-edit paths are not affected.
Are default low-privilege users affected?
Exploitation depends on whether a non-admin account has been granted the users.edit permission in the relevant company scope. The provided information does not indicate that ordinary users without this permission can exploit the flaw.
What is the impact if an administrator is targeted?
An attacker can deactivate an administrator or superuser account, preventing that account from accessing the application until another administrator or superuser re-enables it. The flaw does not permit changes to usernames, email addresses, passwords, or permissions, and it does not disclose data.
What can be done before upgrading?
Limit users.edit permission to trusted administrative users, particularly in company scopes containing privileged accounts. Review active accounts with this permission and monitor or restrict full PUT requests to the single-user edit route where possible.