Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-09T14:17:25.800Z",
  "pubdate": "2026-09-09T14:17:25.800Z",
  "executiveSummary": "An incorrect authorization vulnerability exists in Snipe-IT versions 8.2.0 through 8.6.x within the user update workflow. The vulnerability allows an authenticated non-administrator possessing the users.edit permission to manipulate the activation status of any user account, including administrative and superuser accounts.\nThe flaw resides in the app/Http/Controllers/Users/UsersController::update() function, where input validation logic incorrectly prioritizes the assignment of the 'activated' flag before performing mandatory authorization checks.\nThis vulnerability poses a significant risk to organizational account availability. By targeting administrative accounts, a malicious actor can effectively perform a denial-of-service attack, locking administrators out of the application and potentially creating administrative gaps within the system.\nExploitation requires authenticated access to the application with specific, limited user-management permissions. The scope of the vulnerability is restricted to the web-based update route; the API and bulk-edit functionalities remain unaffected.",
  "technicalDetails": "The root cause of this vulnerability is a flawed sequence of operations within the app/Http/Controllers/Users/UsersController::update() method. In the affected versions, the controller processes the request payload and assigns the 'activated' field to the user object before the application invokes the canEditAuthFields authorization gate.\nThis logic bypass allows a user with the 'users.edit' permission to send a crafted PUT request to the '/users/{id}' endpoint. Because the assignment logic precedes the authorization check, the 'activated' boolean is persisted in the database regardless of the user's actual permission to modify security-sensitive fields of the target account.\nThe attack flow proceeds as follows: First, the attacker identifies a target user ID, such as an administrator account. Second, the attacker crafts a PUT request targeting '/users/{id}' containing the 'activated' parameter set to '0'. Third, the application receives the request and, due to the incorrect controller logic, updates the 'activated' status in the database before the authorization check is performed. Finally, the target administrator is deactivated and effectively locked out of their session and future login attempts.\nThis vulnerability is classified as an improper authorization flaw. While other sensitive fields like username, email, password, and permission sets are properly guarded by the canEditAuthFields gate, the 'activated' field is treated as standard profile data during the initial assignment phase. This exposure allows for the unauthorized state transition of high-privilege accounts.\nThe vulnerability is limited to the single-user edit interface. Both the 'Api\\UsersController::update' endpoint and the bulk-edit features correctly enforce authorization logic, meaning the vulnerability cannot be weaponized through automated API scripting or batch processing. The impact is strictly confined to the forced deactivation of users, causing service disruption rather than data exfiltration or privilege escalation. An account deactivated in this manner must be restored by an administrator or superuser with explicit access to toggle the 'activated' flag."
}