CVE-2026-55843: 
NixOS 脆弱性の分析と軽減

CVE-2026-55843 is an Improper Privilege Management vulnerability in Snipe-IT, an open-source IT asset and license management system. The flaw exists in versions up to and including 8.4.1 (all versions prior to 8.6.0) and allows an authenticated administrator — or any user holding the users.edit permission — to silently strip administrative or granular permissions from other user accounts by sending a crafted update request that omits the permission field. It was disclosed on July 10, 2026, with a fix released in version 8.6.0. The vulnerability carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 7.0 (High) (GitHub Advisory).

The root cause is classified as CWE-269 (Improper Privilege Management). The UsersController::update() method unconditionally passes the permission request field to NormalizePermissionsPayloadAction, which returns an empty array when the field is absent from the request. This sparse result is then passed to PreserveUnauthorizedPrivilegedPermissionsAction, which only selectively restores the superuser key (if the editor is not a superuser) and the admin key (if the editor is neither admin nor superuser) — discarding all other permissions and overwriting $user->permissions with the incomplete result. The canEditAuthFields gate permits admins to update other non-superuser accounts, meaning a PUT /users/{id} request without the permission field permanently destroys the target's admin flag and all granular permissions with no error or notification. The fix, applied in commit 1cff2d6, wraps the permission-update logic in a $request->has('permission') guard so that permissions are only modified when the field is explicitly present in the request (GitHub Advisory, Patch Commit).

Successful exploitation allows an attacker with administrator-level access (or users.edit permission) to permanently remove another user's administrative privileges or granular permissions without any error, warning, or out-of-band notification to the victim. In the primary attack path, one admin can fully revoke another admin's access, effectively locking them out of the system and enabling privilege consolidation. A secondary path allows non-admin users with users.edit to wipe all granular permissions from regular accounts. There is no confidentiality impact, but integrity and availability of the affected user accounts are fully compromised (GitHub Advisory).

1. Obtain privileged access: Authenticate to the Snipe-IT instance as an administrator or as a user with the users.edit permission.
2. Identify a target account: Enumerate user accounts to identify a target administrator or user whose permissions should be stripped. Note the target's user ID from the admin panel or API.
3. Craft a malformed update request: Construct a PUT /users/{id} HTTP request that includes required fields (e.g., first_name, username) but deliberately omits the permission field entirely.
4. Send the request: Submit the crafted request to the Snipe-IT server. The missing permission field causes NormalizePermissionsPayloadAction to return an empty array, which PreserveUnauthorizedPrivilegedPermissionsAction processes into a sparse result that overwrites the target's permissions.
5. Verify impact: Confirm that the target user's admin flag and all granular permissions have been silently removed. The target loses administrative access with no error or notification generated by the system (GitHub Advisory, Patch Commit).

• Logs: Snipe-IT application logs showing PUT /users/{id} requests from an admin or users.edit user that do not include a permission field in the request body; repeated such requests targeting multiple user accounts in a short timeframe.
• Application State: User accounts that unexpectedly have empty or sparse permissions JSON fields in the database, particularly administrator accounts that have lost their admin flag without a corresponding legitimate change event.
• Audit Trail: Absence of permission-change audit log entries for accounts whose permissions were modified, since the operation produces no error or notification; review Snipe-IT activity logs for user update events lacking permission field changes.
• Behavioral: Administrators reporting sudden loss of access or privilege without explanation; accounts previously holding granular permissions (e.g., hardware.view, reports.view) that can no longer perform expected actions (GitHub Advisory).

Upgrade Snipe-IT to version 8.6.0 or later, which contains the fix applied in commit 1cff2d6 that guards permission updates behind a $request->has('permission') check (Snipe-IT Release, Patch Commit). As interim mitigations, restrict the users.edit permission to only fully trusted administrators, and implement regular audits of user permission changes to detect unauthorized removals. No vendor-provided workaround short of upgrading has been documented.

The vulnerability was reported by researcher mattimustang and credited in the GitHub Security Advisory. The Snipe-IT maintainer (snipe) noted in the v8.6.0 release notes that the release includes security improvements and encouraged all users to upgrade. No significant broader media coverage or notable researcher commentary beyond the advisory has been identified (GitHub Advisory, Snipe-IT Release).