GHSA-FHVP-9HCJ-6M33

Vulnerability from github – Published: 2026-04-14 23:14 – Updated: 2026-04-14 23:14
VLAI?
Summary
Oxia has an OIDC token audience validation bypass via SkipClientIDCheck
Details

Summary

The OIDC authentication provider unconditionally sets SkipClientIDCheck: true in the go-oidc verifier configuration, disabling the standard audience (aud) claim validation at the library level. This allows tokens issued for unrelated services by the same OIDC issuer to be accepted by Oxia.

Impact

In deployments using OIDC authentication, an attacker possessing a valid JWT token issued by the same identity provider but intended for a different service (different client_id/aud) can authenticate to Oxia. This bypasses the intended audience isolation of OAuth2/OIDC.

All versions using OIDC authentication are affected.

Details

In oxiad/common/rpc/auth/oidc.go, both createStaticKeyVerifier() and createRemoteVerifier() set SkipClientIDCheck: true. While a custom audience check exists in Authenticate(), the library-level check — which validates the aud claim against the expected client_id — is completely bypassed.

Patches

Fixed by removing SkipClientIDCheck: true and setting the ClientID field from the configured AllowedAudiences.

Workarounds

Ensure network-level isolation so that only trusted services can reach the Oxia gRPC endpoints.

Severity ?
9.3 (Critical)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.16.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oxia-db/oxia"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.16.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T23:14:49Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\nThe OIDC authentication provider unconditionally sets `SkipClientIDCheck: true` in the `go-oidc` verifier configuration, disabling the standard audience (`aud`) claim validation at the library level. This allows tokens issued for unrelated services by the same OIDC issuer to be accepted by Oxia.\n\n### Impact\nIn deployments using OIDC authentication, an attacker possessing a valid JWT token issued by the same identity provider but intended for a different service (different `client_id`/`aud`) can authenticate to Oxia. This bypasses the intended audience isolation of OAuth2/OIDC.\n\nAll versions using OIDC authentication are affected.\n\n### Details\nIn `oxiad/common/rpc/auth/oidc.go`, both `createStaticKeyVerifier()` and `createRemoteVerifier()` set `SkipClientIDCheck: true`. While a custom audience check exists in `Authenticate()`, the library-level check \u2014 which validates the `aud` claim against the expected `client_id` \u2014 is completely bypassed.\n\n### Patches\nFixed by removing `SkipClientIDCheck: true` and setting the `ClientID` field from the configured `AllowedAudiences`.\n\n### Workarounds\nEnsure network-level isolation so that only trusted services can reach the Oxia gRPC endpoints.",
  "id": "GHSA-fhvp-9hcj-6m33",
  "modified": "2026-04-14T23:14:49Z",
  "published": "2026-04-14T23:14:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oxia-db/oxia/security/advisories/GHSA-fhvp-9hcj-6m33"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oxia-db/oxia"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Oxia has an OIDC token audience validation bypass via SkipClientIDCheck"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

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.