CVE-2026-63493: Snipeitapp Snipe-IT Auth Bypass Vulnerability

CVE-2026-63493 Overview

CVE-2026-63493 is an authentication bypass vulnerability in Snipe-IT, an open-source IT asset and license management system. Versions prior to 8.7.0 enforce the CheckForTwoFactor middleware only on the web middleware group and omit it from the API middleware group. A password-authenticated account with self.api permission can reach the personal-access-token (PAT) API flow before completing its second-factor challenge. The resulting token grants broad API access while the browser session remains blocked at the 2FA page. For administrator accounts, the token can call users/two_factor_reset and allow the attacker to re-enroll a controlled second factor.

Critical Impact
An attacker holding only a valid password can mint a persistent API token that bypasses two-factor authentication and, against an administrator, enables full account takeover.

Affected Products

Snipe-IT versions prior to 8.7.0
snipeitapp/snipe-it self-hosted deployments
Any Snipe-IT instance where accounts have the self.api permission

Discovery Timeline

2026-09-24 - CVE-2026-63493 published to NVD
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-63493

Vulnerability Analysis

The flaw is an authentication bypass [CWE-288] in the Laravel middleware stack of Snipe-IT. The CheckForTwoFactor middleware is registered in the web middleware group, which gates browser routes until the user completes second-factor authentication. The api middleware group does not include an equivalent check, so a password-authenticated session can traverse API routes without satisfying the 2FA requirement.

An attacker who has obtained a victim's password logs in, lands on the 2FA interstitial, and from the same session reaches the personal-access-token issuance route. The issued PAT is persistent and operates independently of the web session's 2FA state. The token inherits the victim's permissions and can read and modify resources accordingly.

For administrators, the impact extends further. The token can call the users/two_factor_reset endpoint and clear the administrator's enrolled factor. The attacker then enrolls their own device, completes the web login, and locks out the legitimate administrator.

Root Cause

The root cause is an inconsistent application of security middleware across route groups. In app/Http/Kernel.php, the API group lacks a 2FA enforcement middleware equivalent to the one applied to the web group. The business logic implicitly assumed the web-layer gate was sufficient, but PAT issuance and PAT-authenticated API calls are reachable via the API pipeline.

Attack Vector

Exploitation requires network access to the Snipe-IT instance, valid credentials for an account with self.api permission, and no second-factor code. The attacker authenticates with the password, is routed to the 2FA page, and in parallel issues a request to the personal-access-token API. The returned token is used for subsequent API calls that would otherwise require 2FA completion.

php

// Patch: register the new middleware in the API group
 use App\Http\Middleware\CheckPermissions;
 use App\Http\Middleware\CheckUserIsActivated;
 use App\Http\Middleware\EncryptCookies;
+use App\Http\Middleware\EnforceApiTwoFactorEnrollment;
 use App\Http\Middleware\EnforceApiUserAgent;
 use App\Http\Middleware\IssueFreshApiTokenIfTwoFactorComplete;
 use App\Http\Middleware\LogAuthedUserHeader;

// New middleware: EnforceApiTwoFactorEnrollment
<?php

namespace App\Http\Middleware;

use App\Helpers\Helper;
use App\Models\Setting;
use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

class EnforceApiTwoFactorEnrollment
{
    public function handle(Request $request, Closure $next)
    {
        // If auth:api didn't populate a user (bad token, no token), let it
        // produce the standard 401 rather than emitting a 403 here.
        $user = $request->user();
        if ($user === null) {
            return $next($request);
        }

        $settings = Setting::getSettings();
        if ($settings === null) {
            return $next($request);
        }

        // Normalize the same way CheckForTwoFactor does: only '1' (optional)
        // and '2' (required for all) count as on.
        $mode = (string) $settings->two_factor_enabled;

Source: GitHub commit 87c3629

Detection Methods for CVE-2026-63493

Indicators of Compromise

Personal-access-token creation events for accounts whose web session has not completed 2FA for the same login.
API requests to users/two_factor_reset from a token issued shortly after a failed or incomplete 2FA prompt.
Administrator accounts whose enrolled second factor was reset without a corresponding administrative audit entry.
New PATs created from unusual IP addresses or user agents, especially shortly after a password-only login.

Detection Strategies

Correlate web authentication events with API token issuance in application logs to flag tokens minted while a session is pending 2FA.
Alert on any call to users/two_factor_reset that originates from an API token rather than an interactive admin session.
Review Snipe-IT audit logs for 2FA reset actions and compare against help-desk ticketing records.

Monitoring Recommendations

Enable verbose logging on API endpoints under /api/v1/ and forward to a central SIEM for correlation.
Baseline normal PAT creation volume per user and alert on deviations.
Monitor outbound reverse-proxy logs for API calls preceding or during 2FA interstitial display.

How to Mitigate CVE-2026-63493

Immediate Actions Required

Upgrade Snipe-IT to version 8.7.0 or later immediately.
Revoke all existing personal-access-tokens and require users to re-issue them after upgrade.
Audit administrator accounts for unauthorized 2FA resets and re-enroll factors on any affected account.
Rotate passwords for accounts suspected of credential compromise.

Patch Information

The vulnerability is fixed in Snipe-IT 8.7.0. The patch introduces a new EnforceApiTwoFactorEnrollment middleware and registers it in the API middleware group in app/Http/Kernel.php. See GitHub Pull Request #19294, commit 87c3629, commit c4ea7db, the GitHub Security Advisory GHSA-hxcx-9h4f-42xx, and the v8.7.0 Release Notes.

Workarounds

Restrict the self.api permission to only accounts that strictly require programmatic access until the upgrade is applied.
Disable personal-access-token functionality at the reverse-proxy layer for unauthenticated or 2FA-incomplete sessions.
Place the Snipe-IT API behind an authenticated gateway or VPN to limit exposure to internal networks.

bash

# Example: block PAT creation at a reverse proxy until upgrade is complete
# nginx snippet
location ~ ^/api/v1/users/[0-9]+/personal_access_tokens$ {
    deny all;
    return 403;
}

location ~ ^/api/v1/users/two_factor_reset$ {
    deny all;
    return 403;
}