CVE-2026-55843: Privilege Demotion and Access Control Bypass via Parameter Omission in Snipe-IT

Snipe-IT is an open-source IT asset and license management platform written in PHP on the Laravel framework. It manages sensitive corporate infrastructure details, hardware assignments, and software licensing. Given the nature of the application, fine-grained access control is critical to ensuring that only authorized users can assign assets or modify configuration settings. The attack surface of the application includes administrative management interfaces, specifically the endpoints exposed to manage user profiles and permission states.

This vulnerability, tracked as CVE-2026-55843, involves improper privilege management (CWE-269) within the user update logic. Specifically, the endpoint handling profile modifications fails to distinguish between an explicit request to remove permissions and an implicit request that merely updates standard profile details like names or email addresses. An authorized actor with user-modification permissions can leverage this vulnerability to completely strip the granular or administrative permissions of other accounts, including high-level administrators.

The vulnerability is particularly critical within multi-tenant or multi-administrator deployments of Snipe-IT. While it does not allow direct unauthenticated privilege escalation, it allows authorized users with intermediate privileges to degrade the system’s integrity and availability. This behavior can lead to a denial-of-service condition for administrators who suddenly find themselves locked out of administrative consoles and unable to perform their duties.

The root cause of CVE-2026-55843 lies in the state handling of partial updates inside the update() method of UsersController, located in app/Http/Controllers/Users/UsersController.php.

When processing an HTTP PUT or PATCH request to update a user's details, the controller accepts input fields from the request payload. In a secure architecture, optional fields that are not present in the payload should be ignored to prevent unintended modification of existing database states.

In the vulnerable implementation, the controller processes the permission input parameter unconditionally, regardless of whether it was actually sent by the client. The application retrieves the parameter via $request->input('permission'). When the client submits an update request that omits this field entirely, the Laravel framework returns null for this input. This null value is then directly forwarded to NormalizePermissionsPayloadAction::run() to prepare the data for database entry.

NormalizePermissionsPayloadAction::run() processes the input and, upon receiving a null value, normalizes it to an empty array ([]). This empty array is then passed to PreserveUnauthorizedPrivilegedPermissionsAction::run(). This action is designed as a safety filter to prevent non-superusers from elevating their own privileges or removing privileges they do not possess. However, if the active editor has identical or higher permissions than the target user (for example, an administrator editing another administrator), the filter allows the update to proceed. Because the input was normalized to an empty array, the action returns this empty or sparse array, which is then serialized using json_encode and stored in the database, erasing all existing permissions of the target user.

To understand the mechanical flow, we can analyze the data transformation from the initial HTTP request to the final database transaction. The following diagram illustrates how the missing parameter traverses the system logic to overwrite the database state:

The implementation within app/Http/Controllers/Users/UsersController.php prior to version 8.6.0 demonstrates this unconditional execution. The vulnerable block shows that permissions were updated on every profile save:

// Vulnerable Code Path
$user->permissions = json_encode(PreserveUnauthorizedPrivilegedPermissionsAction::run(
    requestedPermissions: NormalizePermissionsPayloadAction::run($request->input('permission')),
    authenticatedUser: $authenticatedUser,
    originalPermissions: $orig_permissions_array,
    targetUser: $user,
));

In version 8.6.0, the developers introduced a validation guard using $request->has('permission'). This condition ensures that the permission field is only updated if the key is explicitly supplied in the incoming request payload:

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

This simple presence check successfully remediates the vulnerability. When a request is made to update a user's name or email address without sending the permission dictionary, the application leaves the existing database values intact.

Exploitation of CVE-2026-55843 is straightforward and can be executed via any API client or proxy tool. An attacker must possess an active session with either administrative privileges or granular users.edit permissions. The objective is to demote or lock out a target user by stripping their privileges.

An attacker sends an HTTP PUT request targeting the user resource at /api/v1/users/{id} or the web-based update endpoint. The payload contains only the non-sensitive fields the attacker wishes to modify (such as updating the first name to its current value), while completely omitting the permission parameter. The server processes the request, matches the user privileges, detects no explicit security violation from PreserveUnauthorizedPrivilegedPermissionsAction because no new privileges are being requested, and commits the empty permission set to the database.

The official integration and feature tests written to verify the fix confirm this behavior. The test asserts that an admin updating another admin without the permission field should preserve the target's permissions, which failed in the vulnerable versions:

public function test_admin_updating_another_admin_without_permission_field_preserves_target_permissions()
{
    $editor = User::factory()->admin()->create();
    $target = User::factory()->admin()->create();
 
    $originalPermissions = $target->decodePermissions();
    $this->assertArrayHasKey('admin', $originalPermissions, 'Target should have admin permission set');
 
    $this->actingAs($editor)
        ->put(route('users.update', $target), [
            'first_name' => $target->first_name,
            'username' => $target->username,
            // 'permission' parameter is omitted
        ])
        ->assertRedirect();
 
    $this->assertEquals(
        $originalPermissions,
        $target->fresh()->decodePermissions(),
        'Target admin permissions should be unchanged when permission field is absent'
    );
}

The security implications of CVE-2026-55843 are significant in environments relying on multi-tier access controls. The primary impact is the unauthorized modification of system integrity and the potential for severe operational disruption. By allowing an intermediate administrative account or an editor to strip permissions, a rogue actor can neutralize all other administrative accounts on the system, consolidating control or causing a complete denial of administrative capability.

The CVSS v4.0 score of 7.0 (High) reflects high integrity and availability impact on the target system. Because the vulnerability requires an active account with high privileges (PR:H), the exploitability metrics are lower compared to unauthenticated remote code execution flaws. However, inside large organizations where asset management is delegated to helpdesk staff with limited users.edit permissions, the risk of insider threat or lateral movement is amplified.

From an incident response perspective, the resulting state—where an administrator's permissions are suddenly set to [] or null—can mimic system errors or database corruption. This adds to the operational cost of the incident, as IT personnel must manually restore permissions through direct database manipulation or by restoring backups, resulting in downtime and lost productivity.

The definitive remediation for CVE-2026-55843 is to upgrade Snipe-IT to version 8.6.0 or newer. This release implements the necessary request-parameter check to ensure that user privileges are only modified when explicitly instructed by the administrator.

If an immediate upgrade is not feasible, organizations should implement strict operational controls. Administrators must avoid using the web interface or API to modify user profiles if there is any chance that the request payload will omit the permission field. API integrations that automate user synchronization (such as custom Active Directory or LDAP sync scripts) should be reviewed to verify that they do not perform partial updates that could trigger this bug.

Furthermore, security teams should implement detection and audit measures. This includes regularly auditing user modification logs within Snipe-IT and monitoring the database for users whose permissions column is set to an empty array ([]) or null. A SQL query can be run periodically to detect administrative accounts that have had their privileges cleared unexpectedly:

SELECT id, username, permissions FROM users WHERE permissions = '[]' OR permissions IS NULL;