CVE-2026-55483 Overview
Snipe-IT is an open-source IT asset and license management system used by organizations to track hardware, software, and consumables. CVE-2026-55483 is a missing authorization vulnerability [CWE-862] affecting Snipe-IT versions prior to 8.6.0. An authenticated user holding the users.create permission can submit the admin permission flag during user creation. The store() method in app/Http/Controllers/Users/UsersController.php strips the superuser permission but fails to strip the admin permission. The resulting account gains administrative privileges within the application, enabling privilege escalation from a low-privileged operator to a full administrator.
Critical Impact
An authenticated user with permission to create accounts can escalate to administrator by planting the admin flag on a newly created user.
Affected Products
- Snipe-IT versions prior to 8.6.0
- Grokability Snipe-IT self-hosted deployments
- Snipe-IT container and Docker images built from vulnerable releases
Discovery Timeline
- 2026-08-19 - CVE-2026-55483 published to NVD
- 2026-08-19 - Last updated in NVD database
- v8.6.0 - Fixed release published by Grokability on GitHub
Technical Details for CVE-2026-55483
Vulnerability Analysis
The flaw resides in the user creation flow of Snipe-IT. The store() action in app/Http/Controllers/Users/UsersController.php processes a permissions payload submitted by the requester. The controller correctly removes the superuser permission before persisting the new user, preventing a non-superuser from creating another superuser. However, the same routine does not strip the admin permission from the submitted payload.
Any authenticated account granted the users.create permission can therefore issue a crafted request that sets admin on the new account. The created account inherits administrative capabilities across the application, including asset management, user management, and configuration changes. Because the check gap is server-side, the escalation cannot be prevented by hiding the admin toggle in the UI.
Root Cause
The root cause is missing authorization on a privileged attribute. The controller enforces a filter against superuser but has no equivalent enforcement for admin. Only accounts with explicit superuser status should be able to grant admin to another user. The related gate for editing authentication fields also compared against canEditAuthFields rather than a strict superuser check, which the vendor tightened in the fix.
Attack Vector
Exploitation requires an authenticated session with users.create permission and network access to the Snipe-IT web interface. The attacker submits the standard user creation form or API request and includes the admin permission flag in the permissions array. No user interaction from an administrator is required. After the account is created, the attacker authenticates as the new admin user to complete the escalation.
// Security patch in app/Http/Controllers/Users/UsersController.php
// Source: https://github.com/grokability/snipe-it/commit/aea3877718158cc2a10c2dde4597b1f439f5f6cb
- if (auth()->user()->can('canEditAuthFields', $user) && auth()->user()->can('editableOnDemo')) {
+ if (auth()->user()->isSuperUser() && auth()->user()->can('editableOnDemo')) {
$user->groups()->sync($request->input('groups'));
}
The patch replaces the canEditAuthFields gate with a strict isSuperUser() check before allowing group synchronization on user records, ensuring only superusers can assign privileged group memberships and permissions.
Detection Methods for CVE-2026-55483
Indicators of Compromise
- New user accounts created with the admin permission set by a non-superuser account.
- POST requests to the Snipe-IT /users endpoint containing permissions[admin]=1 from accounts that are not superusers.
- Sudden appearance of administrator-privileged users in the Snipe-IT audit log without corresponding superuser activity.
- Login events for newly created admin accounts followed by configuration or user management changes.
Detection Strategies
- Review the Snipe-IT activity log for created user events where the resulting user holds admin and the actor is not a superuser.
- Query the users and permissions tables in the Snipe-IT database for accounts created before the upgrade to 8.6.0 that carry the admin flag.
- Alert on HTTP POST bodies to /users where the permissions JSON contains the admin key with a truthy value.
Monitoring Recommendations
- Forward Snipe-IT web server access logs and application audit logs to a central logging or SIEM platform for correlation.
- Track the population of accounts with administrative permissions over time and alert on unexpected growth.
- Monitor authentication events for the first successful login of any newly provisioned admin account.
How to Mitigate CVE-2026-55483
Immediate Actions Required
- Upgrade Snipe-IT to version 8.6.0 or later, which contains the fix for CVE-2026-55483.
- Audit all existing user accounts and remove admin from users that should not hold administrative privileges.
- Restrict the users.create permission to trusted operators until the patch is applied.
- Rotate credentials and API tokens for any account suspected of unauthorized administrative access.
Patch Information
The vulnerability is fixed in Snipe-IT 8.6.0. The fix commit aea3877718158cc2a10c2dde4597b1f439f5f6cb strips the admin permission during user creation for non-superusers and tightens the gate on privileged group synchronization with an isSuperUser() check. Details are available in the GitHub Security Advisory GHSA-hf68-g98v-wp9g and the GitHub Release v8.6.0.
Workarounds
- Revoke the users.create permission from all non-superuser roles until the upgrade is deployed.
- Place the Snipe-IT admin interface behind a network access control list restricting it to a management network.
- Enforce mandatory review of new user creation events by a separate administrator until the patch is in place.
# Upgrade Snipe-IT to the patched release
cd /var/www/snipe-it
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
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

