Common Weakness Enumeration

CWE-288

Allowed

Authentication 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-8VQG-92MX-5P5H

Vulnerability from github – Published: 2025-07-02 09:30 – Updated: 2025-07-02 15:30
VLAI
Details

Nokia Single RAN AirScale baseband allows an authenticated administrative user access to all physical boards after performing a single login to the baseband system board. The baseband does not re-authenticate the user when they connect from the baseband system board to the baseband capacity boards using the internal bsoc SSH service, which is available only internally within the baseband and through the internal backplane between the boards. The bsoc SSH allows login from one board to another via the baseband internal backplane using an SSH private key present on the baseband system board.

This bsoc SSH capability was previously considered an administrative functionality but has now been restricted to be available only to baseband root-privileged administrators. This restriction mitigates the possibility of misuse with lower-level privileges (e.g., from baseband software images). This mitigation is included starting from release 23R4-SR 3.0 MP and later

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-24332"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-02T09:15:24Z",
    "severity": "HIGH"
  },
  "details": "Nokia Single RAN AirScale baseband allows an authenticated administrative user access to all physical boards after performing a single login to the baseband system board. The baseband does not re-authenticate the user when they connect from the baseband system board to the baseband capacity boards using the internal bsoc SSH service, which is available only internally within the baseband and through the internal backplane between the boards. The bsoc SSH allows login from one board to another via the baseband internal backplane using an SSH private key present on the baseband system board.\n\nThis bsoc SSH capability was previously considered an administrative functionality but has now been restricted to be available only to baseband root-privileged administrators. This restriction mitigates the possibility of misuse with lower-level privileges (e.g., from baseband software images). This mitigation is included starting from release 23R4-SR 3.0 MP and later",
  "id": "GHSA-8vqg-92mx-5p5h",
  "modified": "2025-07-02T15:30:36Z",
  "published": "2025-07-02T09:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24332"
    },
    {
      "type": "WEB",
      "url": "https://www.nokia.com/about-us/security-and-privacy/product-security-advisory/cve-2025-24332"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8VRH-3PM2-V4V6

Vulnerability from github – Published: 2026-02-25 16:00 – Updated: 2026-04-27 14:56
VLAI
Summary
FileBrowser Quantum: Password Protection Not Enforced on Shared File Links
Details

Summary

When users share password-protected files, the recipient can completely bypass the password and still download the file.

Details

This happens because the API returns a direct download link in the details of the share, which is accessible to anyone with JUST THE SHARE LINK, even without the password.

PoC

  1. As an authenticated user, create a share for a file, with a password specified in "Optional password" (make sure to allow anonymous access as the PoC doesn't explain how to do this on a share that requires login, but it is also possible to do on a share that requires login, with some small tweaks to the API request)
  2. Copy the first link (the clipboard WITHOUT an arrow) because the second one just completely skips the password without any effort required, which was mentioned in another vulnerability (https://github.com/filebrowser/filebrowser/security/advisories/GHSA-3v48-283x-f2w4)

Now, the link that was copied should look like: https://yourdomain/public/share/yoursharehash example: https://example.com/public/share/ngCZzArOyFHUQBmfbvP-pA

Now, make a API request with any api client to GET https://yourdomain/public/api/shareinfo?hash=(the share hash from the link) example: https://example.com/public/api/shareinfo?hash=ngCZzArOyFHUQBmfbvP-pA

If curl is preferred, a (command line based API client), here's the command: curl 'https://yourdomain/public/api/shareinfo?hash=yoursharehash' -H 'Accept: */*' example: curl 'https://example.com/public/api/shareinfo?hash=ngCZzArOyFHUQBmfbvP-pA' -H 'Accept: */*'

Example response:

{
    "shareTheme": "default",
    "title": "Shared files - IMG_20240814_213703451.jpg",
    "description": "A share has been sent to you to view or download.",
    "disableSidebar": false,
    "source": "/folder",
    "path": "/IMG_20240814_213703451.jpg/",
    "downloadURL": "https://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA\u0026token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D",
    "shareURL": "https://example.com/public/share/ngCZzArOyFHUQBmfbvP-pA",
    "enforceDarkLightMode": "default",
    "viewMode": "normal",
    "shareType": "normal",
    "sidebarLinks": [
        {
            "name": "Share QR Code and Info",
            "category": "shareInfo",
            "target": "#",
            "icon": "qr_code"
        },
        {
            "name": "Download",
            "category": "download",
            "target": "#",
            "icon": "download"
        }
    ],
    "hasPassword": true
}

Look at the downloadURL. It encodes the "&" symbol as "\u0026" so just replace "\u0026" with "&", example: https://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA\u0026token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D should be changed to: https://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA&token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D

Then just copy paste the new link (example: https://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA&token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D) into any browser, and the file will download. All without giving a password.

Impact

This affects anyone who shares password-protected files.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gtsteffaniak/filebrowser/backend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260221163904-dbcfba993b85"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27611"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-288",
      "CWE-602"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-25T16:00:49Z",
    "nvd_published_at": "2026-02-25T03:16:05Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nWhen users share password-protected files, the recipient can completely bypass the password and still download the file.\n\n### Details\nThis happens because the API returns a direct download link in the details of the share, which is accessible to anyone with JUST THE SHARE LINK, even without the password.\n\n### PoC\n1. As an authenticated user, create a share for a file, with a password specified in \"Optional password\" (make sure to allow anonymous access as the PoC doesn\u0027t explain how to do this on a share that requires login, but it is also possible to do on a share that requires login, with some small tweaks to the API request)\n2. Copy the first link (the clipboard WITHOUT an arrow) because the second one just completely skips the password without any effort required, which was mentioned in another vulnerability (https://github.com/filebrowser/filebrowser/security/advisories/GHSA-3v48-283x-f2w4)\n\nNow, the link that was copied should look like:\nhttps://yourdomain/public/share/yoursharehash\nexample:\nhttps://example.com/public/share/ngCZzArOyFHUQBmfbvP-pA\n\nNow, make a API request with any api client to GET \nhttps://yourdomain/public/api/shareinfo?hash=(the share hash from the link)\nexample:\nhttps://example.com/public/api/shareinfo?hash=ngCZzArOyFHUQBmfbvP-pA\n\nIf curl is preferred, a (command line based API client), here\u0027s the command:\n`curl \u0027https://yourdomain/public/api/shareinfo?hash=yoursharehash\u0027 -H \u0027Accept: */*\u0027`\nexample:\n`curl \u0027https://example.com/public/api/shareinfo?hash=ngCZzArOyFHUQBmfbvP-pA\u0027 -H \u0027Accept: */*\u0027`\n\nExample response:\n```\n{\n    \"shareTheme\": \"default\",\n    \"title\": \"Shared files - IMG_20240814_213703451.jpg\",\n    \"description\": \"A share has been sent to you to view or download.\",\n    \"disableSidebar\": false,\n    \"source\": \"/folder\",\n    \"path\": \"/IMG_20240814_213703451.jpg/\",\n    \"downloadURL\": \"https://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA\\u0026token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D\",\n    \"shareURL\": \"https://example.com/public/share/ngCZzArOyFHUQBmfbvP-pA\",\n    \"enforceDarkLightMode\": \"default\",\n    \"viewMode\": \"normal\",\n    \"shareType\": \"normal\",\n    \"sidebarLinks\": [\n        {\n            \"name\": \"Share QR Code and Info\",\n            \"category\": \"shareInfo\",\n            \"target\": \"#\",\n            \"icon\": \"qr_code\"\n        },\n        {\n            \"name\": \"Download\",\n            \"category\": \"download\",\n            \"target\": \"#\",\n            \"icon\": \"download\"\n        }\n    ],\n    \"hasPassword\": true\n}\n```\n\nLook at the downloadURL. It encodes the \"\u0026\" symbol as \"\\u0026\" so just replace \"\\u0026\" with \"\u0026\", example: \nhttps://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA\\u0026token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D\nshould be changed to:\nhttps://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA\u0026token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D\n\nThen just copy paste the new link (example: https://example.com/public/api/raw?hash=ngCZzArOyFHUQBmfbvP-pA\u0026token=uEr4nCNarX6FqlzwmBo8X1rRRASbOrMY.sWSARcKhrVKrEJlqiF-l6RjXK9fMEPYZsMc9DCJ96BQ%3D) into any browser, and the file will download. All without giving a password.\n\n### Impact\nThis affects anyone who shares password-protected files.",
  "id": "GHSA-8vrh-3pm2-v4v6",
  "modified": "2026-04-27T14:56:47Z",
  "published": "2026-02-25T16:00:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gtsteffaniak/filebrowser/security/advisories/GHSA-8vrh-3pm2-v4v6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27611"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gtsteffaniak/filebrowser/commit/a8c9b9419ec530568991a2f72cec4ed263f99e3c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gtsteffaniak/filebrowser/commit/c51b0ee9738fa4599b409f47c5bf820ef31b4fe1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gtsteffaniak/filebrowser"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4546"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FileBrowser Quantum: Password Protection Not Enforced on Shared File Links "
}

GHSA-8X4M-QW58-3PCX

Vulnerability from github – Published: 2026-03-29 15:15 – Updated: 2026-03-29 15:15
VLAI
Summary
mppx has multiple payment bypass and griefing vulnerabilities
Details

Impact

Multiple vulnerabilities were discovered in tempo/charge and tempo/session which allowed for undesirable behaviors, including: - Replaying tempo/charge transaction hashes across push/pull modes, across charge/session endpoints, and via concurrent requests - Performing free tempo/charge requests due to missing transfer log verification in pull-mode - Replaying tempo/charge credentials across routes via cross-route scope confusion (memo/splits not included in scope binding) - Manipulating the fee payer of a tempo/charge handler into paying for requests (missing sender signature before co-signing) - Bypassing tempo/session voucher signature verification - Piggybacking off existing tempo/session channels via settle voucher reuse and weak channel ID binding - Performing free tempo/session requests by exploiting channel reopen without on-chain settled state - Accepting deductions on finalized tempo/session channels - Bypassing payment on free routes via method-mismatch fallback - Griefing tempo/session channels via force-close detection bypass (closeRequestedAt not persisted)

Patches

Fixed in 0.4.8.

Workarounds

There are no workarounds available for these vulnerabilities.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "mppx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-288",
      "CWE-294",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-29T15:15:36Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nMultiple vulnerabilities were discovered in `tempo/charge` and `tempo/session` which allowed for undesirable behaviors, including:\n- Replaying `tempo/charge` transaction hashes across push/pull modes, across charge/session endpoints, and via concurrent requests\n- Performing free `tempo/charge` requests due to missing transfer log verification in pull-mode\n- Replaying `tempo/charge` credentials across routes via cross-route scope confusion (`memo`/`splits` not included in scope binding)\n- Manipulating the fee payer of a `tempo/charge` handler into paying for requests (missing sender signature before co-signing)\n- Bypassing `tempo/session` voucher signature verification\n- Piggybacking off existing `tempo/session` channels via settle voucher reuse and weak channel ID binding\n- Performing free `tempo/session` requests by exploiting channel reopen without on-chain settled state\n- Accepting deductions on finalized `tempo/session` channels\n- Bypassing payment on free routes via method-mismatch fallback\n- Griefing `tempo/session` channels via force-close detection bypass (`closeRequestedAt` not persisted)\n\n### Patches\n\nFixed in 0.4.8.\n\n### Workarounds\n\nThere are no workarounds available for these vulnerabilities.",
  "id": "GHSA-8x4m-qw58-3pcx",
  "modified": "2026-03-29T15:15:36Z",
  "published": "2026-03-29T15:15:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wevm/mppx/security/advisories/GHSA-8x4m-qw58-3pcx"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wevm/mppx"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "mppx has multiple payment bypass and griefing vulnerabilities"
}

GHSA-92CR-JXW4-5WJG

Vulnerability from github – Published: 2026-09-22 14:46 – Updated: 2026-09-22 14:46
VLAI
Summary
Sync-in Server has a complete 2FA Bypass via `POST /api/auth/token`
Details

Affected component: Sync-in Server v2.3.0, POST /api/auth/token (auth.controller.ts:50-55).

Required attacker capability: Valid username and password for a 2FA-enabled account.

Summary

POST /api/auth/token authenticates with username and password only, then calls getTokens(), which returns unrestricted Bearer access and refresh JWTs without checking whether the account has TOTP 2FA enabled. An attacker who already knows valid credentials for a 2FA-enabled account can bypass 2FA in a single request.

The parallel login endpoint (POST /api/auth/login) correctly enforces 2FA by calling setCookies(user, res, true), which gates on user.twoFaEnabled when server-side TOTP is enabled.

Details

The token endpoint at auth.controller.ts:50-55 uses AuthLocalGuard (password-only) and calls getTokens() directly:

// auth.controller.ts:50-55
@Post(AUTH_ROUTE.TOKEN)
@AuthTokenSkip()
@UseGuards(AuthLocalGuard)
token(@GetUser() user: UserModel): Promise<TokenResponseDto> {
  return this.authManager.getTokens(user)
}

getTokens() at auth.service.ts:25-39 signs and returns access and refresh JWTs. It never reads user.twoFaEnabled:

// auth.service.ts:25-39
async getTokens(user: UserModel, refresh = false): Promise<TokenResponseDto> {
  const currentTime = currentTimeStamp()
  // ...expiration logic...
  return {
    [TOKEN_TYPE.ACCESS]: await this.jwtSign(user, TOKEN_TYPE.ACCESS, accessExpiration),
    [TOKEN_TYPE.REFRESH]: await this.jwtSign(user, TOKEN_TYPE.REFRESH, refreshExpiration),
    // ...
  }
}

Compare with the login endpoint at auth.controller.ts:30-35, which calls setCookies(user, res, true). Inside setCookies() at auth.service.ts:45, the 2FA gate fires:

// auth.service.ts:45
const verify2Fa = init2FaVerify && configuration.auth.mfa.totp.enabled && user.twoFaEnabled

When verify2Fa is true, setCookies() issues only a restricted ACCESS_2FA token and requires the user to complete POST /api/auth/2fa/login/verify before receiving full session cookies. The token endpoint has no equivalent gate.

PoC

Prerequisites

  • A Sync-in instance with TOTP 2FA enabled server-wide.
  • A user account with 2FA enrolled (the target).
  • The target's valid login and password, but not the TOTP secret or current TOTP code.

Steps

  1. Enable 2FA on the target account. Log in as the target user, navigate to Settings, and enable TOTP two-factor authentication.

  2. Confirm normal login requires 2FA. Log out. Log back in with the target's credentials. The UI presents a TOTP code prompt before granting access, and the API response contains only token.access_2fa_expiration (a restricted partial token):

POST /api/auth/login
{"login":"test","password":"..."}

Response: {"user":{"twoFaEnabled":true},"server":{"twoFaEnabled":true},"token":{"access_2fa_expiration":1781234379}}
  1. Bypass 2FA via the token endpoint. Send the same credentials to /api/auth/token:
POST /api/auth/token
{"login":"test","password":"..."}

Response:
{
  "access": "eyJhbGciOiJIUzI1NiIs...",
  "refresh": "eyJhbGciOiJIUzI1NiIs...",
  "access_expiration": 1781235890,
  "refresh_expiration": 1781248490
}

Unrestricted Bearer access and refresh JWTs are returned. No TOTP code was required.

  1. Confirm API access. Use the token on a protected endpoint:
GET /api/users/me
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Response: {"user":{"id":16,"login":"test","email":"test@lab.local","twoFaEnabled":true,...}}

The server returns the user profile. Protected API endpoints that accept Bearer authentication are accessible as the target user. No TOTP code was required at any step.

Measured observations

  • The login endpoint (/api/auth/login) correctly returns a restricted 2FA-pending response.
  • The token endpoint (/api/auth/token) returns unrestricted Bearer JWTs with the same credentials and no TOTP.
  • The returned Bearer token grants access to protected API endpoints as a fully authenticated user, though cookie-specific flows may differ.

Impact

An attacker who already knows valid credentials for a 2FA-enabled account can obtain unrestricted Bearer access and refresh JWTs in a single HTTP request, without knowing the TOTP secret or possessing the authenticator device. 2FA security is bypassed for Bearer-token API authentication.

Remediation

Gate the token endpoint behind the same 2FA policy used by the login route. After AuthLocalGuard validates the username and password, require a valid TOTP code when server-side TOTP is enabled and user.twoFaEnabled is true, before calling getTokens().

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.3.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@sync-in/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58269"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T14:46:30Z",
    "nvd_published_at": "2026-09-21T20:17:26Z",
    "severity": "HIGH"
  },
  "details": "**Affected component:** Sync-in Server v2.3.0, `POST /api/auth/token` (`auth.controller.ts:50-55`).\n\n**Required attacker capability:** Valid username and password for a 2FA-enabled account.\n\n## Summary\n\n`POST /api/auth/token` authenticates with username and password only, then calls `getTokens()`, which returns unrestricted Bearer access and refresh JWTs without checking whether the account has TOTP 2FA enabled. An attacker who already knows valid credentials for a 2FA-enabled account can bypass 2FA in a single request.\n\nThe parallel login endpoint (`POST /api/auth/login`) correctly enforces 2FA by calling `setCookies(user, res, true)`, which gates on `user.twoFaEnabled` when server-side TOTP is enabled.\n\n## Details\n\nThe token endpoint at `auth.controller.ts:50-55` uses `AuthLocalGuard` (password-only) and calls `getTokens()` directly:\n```typescript\n// auth.controller.ts:50-55\n@Post(AUTH_ROUTE.TOKEN)\n@AuthTokenSkip()\n@UseGuards(AuthLocalGuard)\ntoken(@GetUser() user: UserModel): Promise\u003cTokenResponseDto\u003e {\n  return this.authManager.getTokens(user)\n}\n```\n`getTokens()` at `auth.service.ts:25-39` signs and returns access and refresh JWTs. It never reads `user.twoFaEnabled`:\n```typescript\n// auth.service.ts:25-39\nasync getTokens(user: UserModel, refresh = false): Promise\u003cTokenResponseDto\u003e {\n  const currentTime = currentTimeStamp()\n  // ...expiration logic...\n  return {\n    [TOKEN_TYPE.ACCESS]: await this.jwtSign(user, TOKEN_TYPE.ACCESS, accessExpiration),\n    [TOKEN_TYPE.REFRESH]: await this.jwtSign(user, TOKEN_TYPE.REFRESH, refreshExpiration),\n    // ...\n  }\n}\n```\nCompare with the login endpoint at `auth.controller.ts:30-35`, which calls `setCookies(user, res, true)`. Inside `setCookies()` at `auth.service.ts:45`, the 2FA gate fires:\n```typescript\n// auth.service.ts:45\nconst verify2Fa = init2FaVerify \u0026\u0026 configuration.auth.mfa.totp.enabled \u0026\u0026 user.twoFaEnabled\n```\nWhen `verify2Fa` is true, `setCookies()` issues only a restricted `ACCESS_2FA` token and requires the user to complete `POST /api/auth/2fa/login/verify` before receiving full session cookies. The token endpoint has no equivalent gate.\n\n## PoC\n\n### Prerequisites\n\n- A Sync-in instance with TOTP 2FA enabled server-wide.\n- A user account with 2FA enrolled (the target).\n- The target\u0027s valid login and password, but not the TOTP secret or current TOTP code.\n\n### Steps\n\n1. **Enable 2FA on the target account.** Log in as the target user, navigate to Settings, and enable TOTP two-factor authentication.\n\n2. **Confirm normal login requires 2FA.** Log out. Log back in with the target\u0027s credentials. The UI presents a TOTP code prompt before granting access, and the API response contains only `token.access_2fa_expiration` (a restricted partial token):\n```\nPOST /api/auth/login\n{\"login\":\"test\",\"password\":\"...\"}\n\nResponse: {\"user\":{\"twoFaEnabled\":true},\"server\":{\"twoFaEnabled\":true},\"token\":{\"access_2fa_expiration\":1781234379}}\n```\n3. **Bypass 2FA via the token endpoint.** Send the same credentials to `/api/auth/token`:\n```\nPOST /api/auth/token\n{\"login\":\"test\",\"password\":\"...\"}\n\nResponse:\n{\n  \"access\": \"eyJhbGciOiJIUzI1NiIs...\",\n  \"refresh\": \"eyJhbGciOiJIUzI1NiIs...\",\n  \"access_expiration\": 1781235890,\n  \"refresh_expiration\": 1781248490\n}\n```\nUnrestricted Bearer access and refresh JWTs are returned. No TOTP code was required.\n\n4. **Confirm API access.** Use the token on a protected endpoint:\n```\nGET /api/users/me\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIs...\n\nResponse: {\"user\":{\"id\":16,\"login\":\"test\",\"email\":\"test@lab.local\",\"twoFaEnabled\":true,...}}\n```\nThe server returns the user profile. Protected API endpoints that accept Bearer authentication are accessible as the target user. No TOTP code was required at any step.\n\n### Measured observations\n\n- The login endpoint (`/api/auth/login`) correctly returns a restricted 2FA-pending response.\n- The token endpoint (`/api/auth/token`) returns unrestricted Bearer JWTs with the same credentials and no TOTP.\n- The returned Bearer token grants access to protected API endpoints as a fully authenticated user, though cookie-specific flows may differ.\n\n## Impact\n\nAn attacker who already knows valid credentials for a 2FA-enabled account can obtain unrestricted Bearer access and refresh JWTs in a single HTTP request, without knowing the TOTP secret or possessing the authenticator device. 2FA security is bypassed for Bearer-token API authentication.\n\n## Remediation\n\nGate the token endpoint behind the same 2FA policy used by the login route. After `AuthLocalGuard` validates the username and password, require a valid TOTP code when server-side TOTP is enabled and `user.twoFaEnabled` is true, before calling `getTokens()`.",
  "id": "GHSA-92cr-jxw4-5wjg",
  "modified": "2026-09-22T14:46:31Z",
  "published": "2026-09-22T14:46:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Sync-in/server/security/advisories/GHSA-92cr-jxw4-5wjg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58269"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Sync-in/server/pull/228"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Sync-in/server/commit/3ec74e2ea1f538fe1a3ac9487bdf24a19e548361"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Sync-in/server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Sync-in/server/releases/tag/v2.4.0"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sync-in Server has a complete 2FA Bypass via `POST /api/auth/token`"
}

GHSA-92HX-3MH6-HC49

Vulnerability from github – Published: 2023-09-24 03:30 – Updated: 2024-05-03 20:24
VLAI
Summary
kube-apiserver authentication bypass vulnerability
Details

An authentication bypass vulnerability was discovered in kube-apiserver. This issue could allow a remote, authenticated attacker who has been given permissions "update, patch" the "pods/ephemeralcontainers" subresource beyond what the default is. They would then need to create a new pod or patch one that they already have access to. This might allow evasion of SCC admission restrictions, thereby gaining control of a privileged pod.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openshift/apiserver-library-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20230621"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-1260"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-25T18:32:19Z",
    "nvd_published_at": "2023-09-24T01:15:42Z",
    "severity": "HIGH"
  },
  "details": "An authentication bypass vulnerability was discovered in kube-apiserver. This issue could allow a remote, authenticated attacker who has been given permissions \"update, patch\" the \"pods/ephemeralcontainers\" subresource beyond what the default is. They would then need to create a new pod or patch one that they already have access to. This might allow evasion of SCC admission restrictions, thereby gaining control of a privileged pod.",
  "id": "GHSA-92hx-3mh6-hc49",
  "modified": "2024-05-03T20:24:51Z",
  "published": "2023-09-24T03:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1260"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openshift/apiserver-library-go/commit/a994128188486d2dce99a528fbcc017d276081e0"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:3976"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4093"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4312"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4898"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:5008"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-1260"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2176267"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-92hx-3mh6-hc49"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openshift/apiserver-library-go"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20231020-0010"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kube-apiserver authentication bypass vulnerability"
}

GHSA-92MP-2F65-64FR

Vulnerability from github – Published: 2025-06-27 12:31 – Updated: 2026-04-01 18:35
VLAI
Details

Authentication Bypass Using an Alternate Path or Channel vulnerability in ThemesGrove WP SmartPay allows Authentication Abuse. This issue affects WP SmartPay: from n/a through 2.7.13.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-25171"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-27T12:15:31Z",
    "severity": "HIGH"
  },
  "details": "Authentication Bypass Using an Alternate Path or Channel vulnerability in ThemesGrove WP SmartPay allows Authentication Abuse. This issue affects WP SmartPay: from n/a through 2.7.13.",
  "id": "GHSA-92mp-2f65-64fr",
  "modified": "2026-04-01T18:35:34Z",
  "published": "2025-06-27T12:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25171"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/smartpay/vulnerability/wordpress-wp-smartpay-plugin-2-7-13-account-takeover-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-95PV-G7FC-7PXJ

Vulnerability from github – Published: 2026-05-14 06:31 – Updated: 2026-05-14 06:31
VLAI
Details

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.9.1 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user to access confidential issue content in public projects without proper authorization due to improper authorization checks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-4524"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-14T06:16:23Z",
    "severity": "MODERATE"
  },
  "details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.9.1 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user to access confidential issue content in public projects without proper authorization due to improper authorization checks.",
  "id": "GHSA-95pv-g7fc-7pxj",
  "modified": "2026-05-14T06:31:33Z",
  "published": "2026-05-14T06:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4524"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3597717"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2026/05/13/patch-release-gitlab-18-11-3-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/594295"
    }
  ],
  "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-96H5-Q657-FQCV

Vulnerability from github – Published: 2025-06-24 21:30 – Updated: 2025-06-24 21:30
VLAI
Details

Insufficient policy enforcement in Loader in Google Chrome prior to 138.0.7204.49 allowed a remote attacker to bypass content security policy via a crafted HTML page. (Chromium security severity: Low)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-6556"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-24T20:15:27Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient policy enforcement in Loader in Google Chrome prior to 138.0.7204.49 allowed a remote attacker to bypass content security policy via a crafted HTML page. (Chromium security severity: Low)",
  "id": "GHSA-96h5-q657-fqcv",
  "modified": "2025-06-24T21:30:30Z",
  "published": "2025-06-24T21:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6556"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2025/06/stable-channel-update-for-desktop_24.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/40062462"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-96P2-WV27-6PFJ

Vulnerability from github – Published: 2026-08-11 15:32 – Updated: 2026-08-11 15:32
VLAI
Details

The Velociraptor gRPC API has a VFSGetBuffer endpoint which allows reading files from the datastore. To prevent users from reading sensitive files or accessing other orgs, the requested path is prefix checked against a list of denied prefixes. This prefix check can be bypassed allowing a user to access usually denied files. If the user has read permission in the ROOT org, this allows access to other orgs, in which the user may not have permission.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-18636"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T15:17:28Z",
    "severity": "MODERATE"
  },
  "details": "The Velociraptor gRPC API has a VFSGetBuffer endpoint which allows reading files from the datastore. To prevent users from reading sensitive files or accessing other orgs, the requested path is prefix checked against a list of denied prefixes. This prefix check can be bypassed allowing a user to access usually denied files. If the user has read permission in the ROOT org, this allows access to other orgs, in which the user may not have permission.",
  "id": "GHSA-96p2-wv27-6pfj",
  "modified": "2026-08-11T15:32:45Z",
  "published": "2026-08-11T15:32:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18636"
    },
    {
      "type": "WEB",
      "url": "http://docs.velociraptor.app/announcements/advisories/cve-2026-18636"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-96PC-32H7-WJ35

Vulnerability from github – Published: 2025-03-19 12:30 – Updated: 2025-03-19 12:30
VLAI
Details

The Service Finder Bookings plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 5.0. This is due to the plugin not properly validating a user's identity prior to (1) performing a post-booking auto-login or (2) updating their profile details (e.g. password). This makes it possible for unauthenticated attackers to (1) login as an arbitrary user if their email address is known or (2) change an arbitrary user's password, including administrators, and leverage that to gain access to their account.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-13442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-19T12:15:13Z",
    "severity": "CRITICAL"
  },
  "details": "The Service Finder Bookings plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 5.0. This is due to the plugin not properly validating a user\u0027s identity prior to (1) performing a post-booking auto-login or (2) updating their profile details (e.g. password). This makes it possible for unauthenticated attackers to (1) login as an arbitrary user if their email address is known or (2) change an arbitrary user\u0027s password, including administrators, and leverage that to gain access to their account.",
  "id": "GHSA-96pc-32h7-wj35",
  "modified": "2025-03-19T12:30:33Z",
  "published": "2025-03-19T12:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13442"
    },
    {
      "type": "WEB",
      "url": "https://themeforest.net/item/service-finder-service-and-business-listing-wordpress-theme/15208793"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/827b5482-cb42-4aaa-80b5-3d0143fcead8?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"
    }
  ]
}

Mitigation
Architecture and Design

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.