CVE-2026-55689
Description
OpenFGA is an authorization/permission engine built for developers. Prior to 1.18.0, when OpenFGA is configured to use OIDC authentication (authn.method=oidc, authn.oidc.issuer set) but authn.oidc.audience is left unset, the JWT audience claim on incoming bearer tokens is not validated. As a result, a validly-signed OIDC access token issued by the same identity provider for a completely different, unrelated application can be accepted by OpenFGA as a valid credential, allowing an attacker holding such a token to authenticate to OpenFGA and perform unauthorized authorization queries or writes. This issue is fixed in OpenFGA 1.18.0.
Statement
OpenFGA, when run with OIDC authentication enabled (--authn-oidc-issuer) but with --authn-oidc-audience left unset, does not validate the JWT audience claim on incoming bearer tokens. This means a validly-signed OIDC access token issued by the same identity provider for a completely different application/audience will be accepted by OpenFGA as a valid credential. An attacker who can obtain such a token, for example one issued to a lower-privileged or unrelated application at the same IdP, could use it to authenticate to OpenFGA and perform authorization queries or writes they should not be permitted to make.
This flaw only affects deployments that explicitly enable OpenFGA's OIDC authentication method and leave --authn-oidc-audience unset. Deployments using OpenFGA's default (pre-shared key) authentication, or that embed OpenFGA purely as an internal library without exposing its standalone OIDC-authenticated API such as Grafana's Zanzana engine, are less likely to be exposed to this specific issue, though this has not been independently confirmed for every embedding product.
Mitigation
Administrators running OpenFGA with OIDC authentication enabled should set --authn-oidc-audience to the expected audience value for their deployment, restricting accepted tokens to those issued for OpenFGA itself. Upgrading to OpenFGA 1.18.0 or later, which restores audience validation by default, is the preferred long-term remediation.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 6.8 | 8.1 | 6.8 |
| Attack Vector | Network | Network | Network |
| Attack Complexity | High | Low | High |
| Privileges Required | Low | Low | Low |
| User Interaction | None | None | None |
| Scope | Unchanged | Unchanged | Unchanged |
| Confidentiality | High | High | High |
| Integrity Impact | High | High | High |
| Availability Impact | None | None | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
NVD: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
cve.org: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
Understanding the Weakness (CWE)
Integrity,Confidentiality,Availability,Access Control
Technical Impact: Read Application Data; Gain Privileges or Assume Identity; Execute Unauthorized Code or Commands
This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
