CVE-2026-63493: Multi-Factor Authentication Bypass via Stateless API Token Flow in Snipe-IT

Snipe-IT is an open-source IT asset and license management system built on the Laravel PHP framework. The platform supports a hybrid architecture consisting of a stateful, session-based web user interface and a stateless, token-based REST API designed for automation and integration. Security boundaries within the application are established using middleware groups configured in the HTTP kernel.\n\nTo protect user accounts against credential theft, Snipe-IT supports multi-factor authentication (MFA/2FA) utilizing Time-Based One-Time Password (TOTP) mechanisms. When configured, users are prompted to supply a dynamic security code immediately after entering their primary password credentials. Until this verification is completed, web sessions are restricted from accessing system resources.\n\nCVE-2026-63493 defines an authentication bypass vulnerability within this security boundary. Because the middleware enforcing multi-factor verification was bound strictly to the 'web' routing group, the parallel 'api' routing group remained entirely unguarded. An attacker possessing primary credentials can pivot to the API channel, bypass the pending 2FA challenge, and establish persistent administrative control over the target system.

The underlying flaw stems from an architectural mismatch between Laravel's stateful session management and stateless API routing. In Snipe-IT, user login is handled via stateful web endpoints. When a user authenticates with their primary credentials, Laravel initiates an authenticated session and returns a cookie-based identifier. If MFA is active, the web middleware CheckForTwoFactor intercepts subsequent web requests and redirects the user to the /two-factor prompt.\n\nTo allow the user to load the challenge interface and authenticate, the CheckForTwoFactor middleware ignores specific exclusion routes defined in IGNORE_ROUTES. Because the /two-factor path is excluded, requests to it are permitted to complete. Immediately following this middleware in the execution chain is CreateFreshApiToken, which automatically issues a Laravel Passport session cookie named snipeit_passport_token to the user's browser.\n\nCrucially, the API routing group defined in routes/api.php does not execute the CheckForTwoFactor middleware. The API group relies on the auth:api guard, which accepts the newly generated snipeit_passport_token cookie along with the session's XSRF token. Because the API lacks any mechanism to check whether the active session has successfully solved the pending web-based MFA challenge, it processes transactions as fully authorized, bypassing the 2FA enforcement layer.

Prior to version 8.7.0, the api middleware array in app/Http/Kernel.php did not include any verification logic for two-factor enrollment or completion. This configuration permitted any token-bearing request to execute controller actions unhindered, provided the token mapped to a valid user account. The following Mermaid diagram illustrates the dual-path vulnerability where the web route is gated but the API route remains entirely unguarded:\n\nmermaid\ngraph LR\n A["User Login (Password Only)"] --> B["Web Middleware Group"]\n B --> C["CheckForTwoFactor Middleware"]\n C -->|Redirect| D["MFA Challenge Prompt (/two-factor)"]\n D --> E["CreateFreshApiToken (Issues Passport Cookie)"]\n E --> F["API Middleware Group (No MFA Check)"]\n F --> G["POST /api/v1/account/personal-access-tokens"]\n G --> H["Generate Persistent Bearer Token"]\n\n\nThe remediation introduced in pull request #19294 registers a new middleware class, EnforceApiTwoFactorEnrollment, directly into the api middleware array. This class intercepts every inbound REST API transaction immediately after token resolution via the auth:api guard. The middleware inspects the application's global configuration settings to determine whether 2FA is active, and subsequently checks the target user account's enrollment state.\n\nIf the application requires 2FA and the authenticated user account has not enrolled a secondary authentication factor, the middleware terminates the pipeline and returns a 403 Forbidden response. This design maintains the stateless property of the REST API while preventing un-enrolled accounts from using API endpoints, closing the alternate authentication channel. Below is the essential implementation logic of the newly introduced middleware:\n\nphp\n// app/Http/Middleware/EnforceApiTwoFactorEnrollment.php\n$mode = (string) $settings->two_factor_enabled;\nif ($mode !== '1' && $mode !== '2') {\n return $next($request);\n}\n\nif ($mode === '1' && (string) $user->two_factor_optin !== '1') {\n return $next($request);\n}\n\nif ((string) $user->two_factor_enrolled !== '1') {\n return response()->json(\n Helper::formatStandardApiResponse('error', null, trans('auth/message.two_factor.please_enroll')),\n Response::HTTP_FORBIDDEN,\n );\n}\n

To exploit CVE-2026-63493, an attacker must first obtain the primary username and password of a valid Snipe-IT user account. The attacker sends a POST request containing these credentials to the stateful /login endpoint. Upon receipt of a successful response, the target web application establishes an authenticated session but restricts the browser within the /two-factor execution bubble, preventing standard administrative interactions through the web console.\n\nBecause the /two-factor route is exempted from the blocking middleware to permit TOTP submission, the CreateFreshApiToken middleware runs and places the snipeit_passport_token cookie into the browser's cookie jar. The attacker extracts this cookie alongside the matching CSRF token (XSRF-TOKEN). Armed with these cryptographic elements, the attacker shifts focus away from the stateful web client and addresses the stateless REST API.\n\nThe attacker issues a POST request to /api/v1/account/personal-access-tokens passing the passport cookie and the XSRF token as HTTP headers. Since the API routing group is processed by the auth:api guard and lacks the CheckForTwoFactor check, the application verifies the session validity and generates a persistent Personal Access Token. This token possesses a default longevity of forty years and acts as a long-lived credential, bypassing the web-based MFA requirement entirely.

The primary security consequence of this vulnerability is the complete compromise of multi-factor authentication guarantees for any account where the attacker has acquired primary password credentials. This changes the security model from multi-factor to single-factor authentication. If the target account possesses administrative privileges within Snipe-IT, the downstream impacts are significant.\n\nWith a minted Personal Access Token, the attacker gains full programmatic control over the Snipe-IT asset registry, user database, and security configurations. The attacker can manipulate, export, or destroy sensitive asset inventory, hardware data, and proprietary configuration data. This compromise undermines the integrity of internal hardware supply chain records and software license allocations.\n\nFurthermore, the attacker can leverage the administrative API to reset the target account's multi-factor configuration by submitting a POST request to the /api/v1/users/{id}/two_factor_reset endpoint. Once the 2FA state is reset, the attacker can log in through the web interface, register a new attacker-controlled MFA device, and permanently lock out the legitimate system administrator.

Remediation requires upgrading Snipe-IT instances to version 8.7.0 or higher. This update alters the configuration in app/Http/Kernel.php to register the EnforceApiTwoFactorEnrollment middleware into the API pipeline. This modification ensures that any API request backed by an unenrolled account is rejected with a 403 Forbidden status, neutralizing the capability of password-only sessions to generate tokens.\n\nTo identify potential exploitation, defenders should analyze web server access logs for anomalous transaction sequences. A suspect sequence is characterized by a successful POST to /login, followed by a GET to /two-factor, followed immediately by a POST to the /api/v1/account/personal-access-tokens endpoint. In legitimate usage, the login and MFA verification would occur on the web layer before any API interactions take place.\n\nSecurity teams should audit the database tables for newly created Laravel Passport personal access tokens. Inspect the oauth_access_tokens table for entries created near any suspicious login alerts. Any token generated by an account that had not previously completed MFA registration must be treated as untrusted and revoked immediately.