CVE-2026-48493: Self-Privilege Escalation via Profile Modification in Snipe-IT

Snipe-IT is an open-source IT asset management system designed to track hardware, software licenses, and users. Within its authorization architecture, granular permissions dictate which actions users can take, such as creating assets, checking out licenses, or viewing reports. This vulnerability exists within the user-management boundary.\n\nUnder vulnerable configurations, any authenticated user possessing the 'users.edit' permission and API access can manipulate their own permissions. By issuing an authorized update request to their own user profile endpoint, they circumvent intended authorization controls.\n\nThe flaw is classified under CWE-863 (Incorrect Authorization). Although the system implements access control checks, it fails to enforce restrictions when the target of a profile-editing action matches the identity of the requester. This allows lateral and vertical privilege escalation up to almost all non-administrative privileges.

The core weakness resides within the logic implemented in PreserveUnauthorizedPrivilegedPermissionsAction::run(). This action class acts as a filter to ensure that users do not grant permissions they themselves do not possess or are not authorized to assign. In vulnerable versions, this function accepted $requestedPermissions, $authenticatedUser, and $originalPermissions as inputs.\n\nWhile the logic successfully prevented non-superusers from assigning the global admin or superuser roles, it did not differentiate between editing another user and editing oneself. If a user possessed the generic users.edit capability, they were permitted to make modifications to user profiles.\n\nBecause the endpoint allowed a user to direct edit actions to their own profile identifier (/api/v1/users/{id}), the application ran the validation sequence against the user's own profile. Due to the lack of target context inside PreserveUnauthorizedPrivilegedPermissionsAction, the application accepted the payload, effectively letting the user self-authorize higher-level application access.

To fix this vulnerability, the development team modified the signature and logic of PreserveUnauthorizedPrivilegedPermissionsAction::run(). The function now accepts a fourth nullable parameter: ?User $targetUser = null. This parameter provides the context of which specific database record is being modified.\n\nA conditional branch was introduced at the beginning of the run method. If a target user object is provided, the authenticated user is not a superuser, and the authenticated user's ID matches the target user's ID, the function immediately discards the request. It returns the pre-existing, unmodified permissions array, effectively preventing self-modification.\n\nBelow is the core logic fix demonstrating the target validation block:\n\nphp\n// Patched logic in app/Actions/Permissions/PreserveUnauthorizedPrivilegedPermissionsAction.php\npublic static function run(array $requestedPermissions, User $authenticatedUser, array $originalPermissions = [], ?User $targetUser = null): array\n{\n // Disallow non-admin/superuser users from modifying their own permissions\n if ($targetUser && !$authenticatedUser->isSuperUser() && $authenticatedUser->id === $targetUser->id) {\n return $originalPermissions;\n }\n // ... standard validation checks continue below\n}\n\n\nIn addition, the controller classes (app/Http/Controllers/Api/UsersController.php and app/Http/Controllers/Users/UsersController.php) were updated to forward the target user ($user) during the profile update flow. This ensures the action class has the required context to prevent self-escalation regardless of whether the request originates from the API or the web UI.

Exploitation of this vulnerability requires an established user session or a Personal Access Token with API and users.edit permissions. The attacker first resolves their own user identifier by calling the active user endpoint. Once the identifier is obtained, they construct a crafted payload targeting their own user record.\n\nThe attacker issues a standard HTTP PATCH request to the /api/v1/users/{id} endpoint. The payload contains a permissions object setting target privileges to "1" (enabled). For example, the attacker can enable permissions such as assets.create, licenses.edit, and reports.view.\n\nBelow is the data flow representing how the input is handled across the vulnerable boundaries:\n\nmermaid\ngraph LR\n Attacker["Attacker (users.edit)"] -->|PATCH /api/v1/users/self| API["Api/UsersController"]\n API -->|Validates session/token| Action["PreserveUnauthorizedPrivilegedPermissionsAction"]\n Action -->|Checks for admin/superuser only| DB["Database Save"]\n DB -->|Saves escalated permissions| Attacker\n\n\nBecause the vulnerability does not require complex heap shaping, timing, or external dependencies, exploitation is highly reliable. Any endpoint interaction that bypasses the frontend validation and directly calls the API controller will successfully store the escalated privileges in the database.

The impact of successful exploitation is a complete compromise of the authorization model within the affected Snipe-IT instance. An attacker can elevate their privileges to encompass almost all non-administrative operational roles. This includes full read, write, update, and delete access across assets, accessories, components, and licenses.\n\nWith elevated access, an attacker can exfiltrate sensitive corporate asset logs, modify system databases to mask physical theft, or alter user assignments. However, because the vulnerability explicitly blocks the assignment of the global admin and superuser roles, the attacker cannot access core administrative panel settings.\n\nThis restriction maintains the CVSS base score at 5.5, indicating a moderate impact. Nevertheless, in environments where Snipe-IT handles critical enterprise logistics or active asset inventories, this vulnerability poses a significant insider threat risk.

The primary and most effective remediation is upgrading Snipe-IT to version 8.6.0 or higher. This release contains the complete validation fix across both the API and UI routes. Administrators should verify their deployments and execute standard upgrade procedures immediately.\n\nIn environments where an immediate upgrade is not feasible, administrators must implement workarounds. The most effective tactical mitigation is to audit all active user permissions and temporarily revoke users.edit and API access from any account that does not strictly require administrative capabilities.\n\nAdditionally, monitoring web server access logs for suspicious activity is advised. Security teams should query for HTTP PATCH requests targeting /api/v1/users/ where the requesting user's identity matches the URL parameter, followed by database validation to confirm whether unauthorized permission states exist.