CVE-2026-55479: Incorrect Authorization Check in Snipe-IT Legacy License Check-in Flow

Snipe-IT is a widely adopted open-source IT asset and license management system developed by Grokability. Within its license management subsystem, assets and licenses follow a strict lifecycle governed by role-based access control (RBAC). Legitimate administrative workflows separate the capability to assign (checkout) a license seat from the capability to reclaim (checkin) that same license seat. This separation of duty ensures that deployment staff can distribute software seats without having the authority to revoke or reassign active seats from users or assets.

The vulnerability is located within the legacy single-seat license check-in controller. This component manages legacy web interfaces designed to process individual license seat check-ins. Because these legacy routes remain active and accessible in versions prior to 8.6.2, they present a viable attack surface to authenticated users.

By exploiting an incorrect authorization check in this legacy flow, an authenticated attacker with low-level privileges can bypass the administrative division of duties. The flaw maps the authorization checkpoint of a destructive action (revoking a license) to a non-destructive permission check (assigning a license), leading to unauthorized modification of license assignments.

The root cause of CVE-2026-55479 is an incorrect authorization check (CWE-863) within the application's controller logic. In Laravel-based frameworks like Snipe-IT, controller actions typically delegate authorization checks to corresponding Policy classes using the $this->authorize() method. This method expects an action name (the ability to check) and the target model instance to evaluate against the active session's roles.

In app/Http/Controllers/Licenses/LicenseCheckinController.php, the legacy endpoints for rendering the check-in view and handling the check-in submission were incorrectly constructed. Instead of calling $this->authorize('checkin', $license);, both the create and store methods invoked $this->authorize('checkout', $license);.

This implementation flaw creates a logical mapping error. Because the application queries the policy for the 'checkout' capability, any user who has permission to deploy or assign licenses is automatically authorized to access the check-in interface. The system fails to evaluate the user's explicit 'checkin' permissions, thereby collapsing two distinct privilege boundaries into a single, weaker boundary.

The vulnerability was resolved in version 8.6.2 by changing the validated action string in LicenseCheckinController.php. Below is the code diff of the vulnerable versus patched implementation:

// File: app/Http/Controllers/Licenses/LicenseCheckinController.php
 
public function create(LicenseSeat $licenseSeat, $backTo = null)
{
    // Check if the asset exists
    $license = License::find($licenseSeat->license_id);
-   $this->authorize('checkout', $license);
+   $this->authorize('checkin', $license);
 
    return view('licenses/checkin', compact('licenseSeat'))->with('backto', $backTo);
}
 
public function store(Request $request, $seatId = null, $backTo = null)
{
    // ... [validation and setup logic] ...
 
-   $this->authorize('checkout', $license);
+   $this->authorize('checkin', $license);
 
    // ... [database transaction and update logic] ...
}

By replacing 'checkout' with 'checkin', the controller correctly directs Laravel's gates to query the user's checkin capability in the LicensePolicy class. This modification ensures that any attempt to render the check-in page or submit a check-in payload is restricted exclusively to authorized administrators. The fix is robust and completely eliminates the bypass vector on these legacy routes.

To exploit this vulnerability, an attacker must first obtain valid credentials to a Snipe-IT instance with a role that permits license checkout (assignment) but denies license check-in. The attacker then targets an active license seat identifier. Because the legacy check-in views do not rely on complex API structures, exploitation can be carried out using simple web requests.

First, the attacker requests the legacy check-in interface using a standard GET request: GET /licenses/checkin/<seatId>. Because the server incorrectly validates the 'checkout' permission, it returns the check-in form rather than a 403 Forbidden response. This form contains the required CSRF token for state-changing requests.

Next, the attacker constructs a POST request to submit the form: POST /licenses/checkin/<seatId>. The payload contains the CSRF token and the target seat parameters. The controller processes the state change and unassigns the license seat from the assigned user or asset, returning it to the available license pool.

The impact of CVE-2026-55479 is primarily restricted to unauthorized modification of application state and data integrity. While an attacker cannot read sensitive configuration files or execute arbitrary code, they can completely disrupt asset management records. By checking in active license seats, attackers can dissociate corporate software licenses from employees and systems, leading to operational confusion and administrative overhead.

The vulnerability does not allow access to other administrative zones, such as user creation or system settings, unless those areas are independently misconfigured. The CVSS v4.0 base score of 5.3 reflects a network-based attack vector requiring low privileges, with low integrity impact and no confidentiality or availability consequences. This classification reflects a standard privilege escalation scenario within a business application context.