CVE-2026-55843: Snipe-IT Privilege Escalation Vulnerability

CVE-2026-55843 Overview

CVE-2026-55843 is a privilege management flaw [CWE-269] in Snipe-IT, an open-source IT asset and license management system. Versions prior to 8.6.0 mishandle a missing permission field in UsersController::update(). The controller passes the absent field through NormalizePermissionsPayloadAction and PreserveUnauthorizedPrivilegedPermissionsAction, producing a sparse permissions result that overwrites the target user's stored permissions. An administrator updating another administrator, or a user holding users.edit updating a regular account, can strip administrative or granular permissions from the target. The vendor fixed the issue in Snipe-IT 8.6.0.

Critical Impact
Authenticated users with edit rights can silently remove privileges from other accounts, including fellow administrators, enabling account takeover pathways and disruption of authorization boundaries.

Affected Products

Snipe-IT versions prior to 8.6.0
snipeitapp/snipe-it package (cpe:2.3:a:snipeitapp:snipe-it:*:*:*:*:*:*:*:*)
Self-hosted Snipe-IT deployments exposing the users administration endpoint

Discovery Timeline

2026-07-10 - CVE-2026-55843 published to the National Vulnerability Database
2026-07-13 - Last updated in NVD database

Technical Details for CVE-2026-55843

Vulnerability Analysis

The defect resides in app/Http/Controllers/Users/UsersController.php. When an authorized caller submits a user update request, the controller unconditionally reads $request->input('permission') and pipes the value through two normalization actions. If the caller omits the permission field entirely, the input evaluates to null. Downstream logic treats this as a sparse payload rather than an unchanged field, so the resulting JSON overwrites the target user's permissions column. The target loses granular rights and, in the case of administrators, may lose the administrative flag. This qualifies as improper privilege management because a legitimate write path produces an unintended authorization state change on another account.

Root Cause

The controller lacks a guard verifying that the request actually contains a permission key before recomputing and persisting the permissions blob. Absent that guard, PreserveUnauthorizedPrivilegedPermissionsAction::run() receives an empty requested set and returns a reduced permission structure, which is then JSON-encoded and saved to the target user record.

Attack Vector

Exploitation requires an authenticated session with elevated privileges. Requires users.edit for targeting regular users, or administrator rights for targeting other administrators. The attacker sends a PUT or PATCH request to the user update endpoint with any fields except permission. The server persists a sparse permission set to the target, effectively demoting the account.

php

// Security patch in app/Http/Controllers/Users/UsersController.php
// Source: https://github.com/grokability/snipe-it/commit/1cff2d67aabd00ee51d864c1d7fb717494c1d6ad

                $user->password = bcrypt($request->input('password'));
            }

-           $user->permissions = json_encode(PreserveUnauthorizedPrivilegedPermissionsAction::run(
-               requestedPermissions: NormalizePermissionsPayloadAction::run($request->input('permission')),
-               authenticatedUser: $authenticatedUser,
-               originalPermissions: $orig_permissions_array,
-               targetUser: $user,
-           ));
+           if ($request->has('permission')) {
+               $user->permissions = json_encode(PreserveUnauthorizedPrivilegedPermissionsAction::run(
+                   requestedPermissions: NormalizePermissionsPayloadAction::run($request->input('permission')),
+                   authenticatedUser: $authenticatedUser,
+                   originalPermissions: $orig_permissions_array,
+                   targetUser: $user,
+               ));
+           }

            // Only save groups if the user is a superuser
            if (auth()->user()->isSuperUser()) {

The fix wraps the permission recomputation in $request->has('permission'), so absent fields no longer trigger a permissions overwrite.

Detection Methods for CVE-2026-55843

Indicators of Compromise

Unexpected changes to the permissions column in the users table, especially permission sets shrinking rather than growing.
Administrator accounts losing the superuser or admin flag without a corresponding legitimate change ticket.
HTTP PUT or PATCH requests to /users/{id} that omit the permission form field yet still trigger a permissions audit entry.

Detection Strategies

Enable and review Snipe-IT's built-in activity log for update actions on user records, correlating actor, target, and resulting permission delta.
Add database-level auditing on the users.permissions column and alert on transitions from a populated JSON blob to a reduced or empty set.
Inspect web server access logs for authenticated requests to the user update endpoint that lack expected permission[] parameters.

Monitoring Recommendations

Alert on any user record where administrative privileges are removed outside a change window.
Track repeated user-edit API calls from a single session targeting multiple accounts within a short interval.
Forward Snipe-IT application logs and web access logs to a centralized log platform for retention and correlation with identity events.

How to Mitigate CVE-2026-55843

Immediate Actions Required

Upgrade Snipe-IT to version 8.6.0 or later, which introduces the $request->has('permission') guard.
Audit all administrator and privileged user accounts to confirm permission sets match the documented baseline.
Rotate credentials for any account whose permissions were unexpectedly modified before the upgrade.
Restrict users.edit assignment to a minimal set of trusted operators.

Patch Information

The fix ships in Snipe-IT 8.6.0. Review the GitHub Security Advisory GHSA-j5g3-42wp-gqm3, the remediation commit 1cff2d6, and the v8.6.0 release notes for full details.

Workarounds

If an immediate upgrade is not possible, reduce the number of users holding users.edit and administrator roles.
Place the Snipe-IT administration interface behind a network allowlist or VPN to limit exposure of the update endpoint.
Enable multi-factor authentication for all privileged Snipe-IT accounts to raise the cost of any compromise that would enable exploitation.

bash

# Upgrade Snipe-IT to the patched release
cd /var/www/snipe-it
php artisan down
git fetch --tags
git checkout v8.6.0
composer install --no-dev --prefer-source
php artisan migrate --force
php artisan config:clear && php artisan cache:clear
php artisan up

# Verify version
php artisan --version
grep "'app_version'" config/version.php