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

CVE-2026-48493 Overview

CVE-2026-48493 is a broken access control vulnerability in Snipe-IT, an open-source IT asset and license management system. In versions prior to 8.6.0, a user holding only the users.edit permission can send a PATCH request to /api/v1/users/{their_own_id} and grant themselves additional permissions such as assets.view, assets.create, reports.view, and import privileges. The flaw allows horizontal-to-vertical privilege escalation across the application, excluding only the admin and superuser roles. The issue is tracked under [CWE-863: Incorrect Authorization] and patched in Snipe-IT 8.6.0.

Critical Impact
An authenticated low-privilege user with users.edit can self-elevate to nearly any non-administrative permission, gaining unauthorized access to assets, reports, and import functionality.

Affected Products

Snipe-IT versions prior to 8.6.0
Snipe-IT IT asset/license management system
Self-hosted Snipe-IT deployments exposing the /api/v1/users endpoint

Discovery Timeline

2026-06-23 - CVE-2026-48493 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-48493

Vulnerability Analysis

The vulnerability resides in the Snipe-IT user management API. The endpoint /api/v1/users/{id} accepts PATCH requests to modify user attributes, including the permissions field. The server-side authorization logic verifies that the requester holds the users.edit permission, but it does not validate that the requester is authorized to assign each individual permission being granted.

When the target user ID equals the requester's own ID, the request still passes authorization. This permits a user with users.edit to write arbitrary permission flags onto their own account. The only excluded permissions are admin and superuser, leaving the remaining permission set fully assignable.

The vulnerability is classified under [CWE-863] because the authorization decision evaluates only coarse-grained access to the edit operation. It does not evaluate the sensitivity of the fields being modified or the relationship between requester and target.

Root Cause

The root cause is missing field-level authorization on the user update API. Snipe-IT treats the users.edit permission as a single capability gate. The application does not separate the right to edit user profile data from the right to assign permissions, and it does not block self-targeted permission assignment.

Attack Vector

An attacker must first obtain an account with the users.edit permission, which is commonly delegated to help-desk or operations staff. The attacker then issues an authenticated PATCH request to /api/v1/users/{their_own_id} with a JSON body containing elevated permission flags. The server applies the changes, and the session immediately reflects the new permissions.

No user interaction is required from administrators. The attacker can then access asset inventories, generate reports, perform bulk imports, or pivot to other authorized actions across the platform.

A detailed description of the flaw and fix is available in the Snipe-IT GitHub Security Advisory GHSA-52fw-7fw2-fmv5 and the corresponding pull request #19024.

Detection Methods for CVE-2026-48493

Indicators of Compromise

PATCH requests to /api/v1/users/{id} where the path id matches the authenticated user's own ID
Audit log entries showing self-modification of the permissions field
Sudden expansion of a non-admin account's permission set without administrator action
API requests from accounts holding users.edit that include assets.*, reports.*, or import permission keys in the request body

Detection Strategies

Parse Snipe-IT application logs and webserver access logs for PATCH requests to /api/v1/users/{id} and correlate the path ID with the authenticated session user ID.
Alert on any user permission change where the actor and the target are the same non-admin account.
Baseline normal permission-change activity and flag deviations, particularly granting of assets.create, reports.view, or import permissions to previously limited accounts.

Monitoring Recommendations

Forward Snipe-IT activity logs and reverse-proxy access logs to a centralized log platform for retention and search.
Track API token usage and tie API calls back to individual accounts and source IP addresses.
Review the Snipe-IT activity log on a recurring schedule for update actions targeting the User model with permission deltas.

How to Mitigate CVE-2026-48493

Immediate Actions Required

Upgrade Snipe-IT to version 8.6.0 or later, which contains the official fix.
Audit all user accounts for unauthorized permission additions granted before the patch was applied.
Revoke the users.edit permission from any account that does not require it, and restrict it to trusted administrators only.
Rotate API tokens for accounts that previously held users.edit and verify their current permission set.

Patch Information

The fix is included in Snipe-IT 8.6.0. The change enforces authorization on permission assignment and prevents self-elevation through the users API. Review the upstream pull request #19024 for implementation details and the GitHub Security Advisory GHSA-52fw-7fw2-fmv5 for advisory metadata.

Workarounds

If upgrading is not immediately possible, remove the users.edit permission from all non-administrator accounts.
Restrict network access to /api/v1/users endpoints using an upstream reverse proxy or web application firewall, allowing only known administrator source addresses.
Increase audit log review frequency until the patch is deployed and validate that no unauthorized permissions were assigned during the exposure window.

bash

# Configuration example: upgrade Snipe-IT to the patched release
cd /var/www/snipe-it
sudo -u www-data git fetch --tags
sudo -u www-data git checkout v8.6.0
sudo -u www-data composer install --no-dev --prefer-source
sudo -u www-data php artisan migrate --force
sudo -u www-data php artisan config:clear
sudo -u www-data php artisan cache:clear
sudo systemctl restart php-fpm nginx