OpenFGA is an authorization/permission engine built for developers. Prior to 1.18.0, OpenFGA's OIDC authenticator skipped JWT audience validation when authn.method was set to oidc, authn.oidc.issuer was configured, and authn.oidc.audience was not set, allowing a token minted for an unrelated service by the same identity provider to authenticate to OpenFGA. This issue is fixed in 1.18.0.

OpenFGA is an authorization/permission engine built for developers. Prior to 1.18.0, when MySQL is being used as the datastore and authorization decisions rely on case-sensitive user strings, the tuple, changelog, and authorization_model identifier columns can compare case-distinct values such as user:Alice and user:alice as equivalent, causing two distinct check requests to return the same response. This issue is fixed in 1.18.0.

OpenFGA is an authorization/permission engine built for developers. Prior to version 1.16.0, when iterator caching is enabled, two distinct check requests can produce the same cache key, leading to OpenFGA reusing an earlier cached result for a subsequent request. This issue has been patched in version 1.16.0.

OpenFGA is an authorization/permission engine built for developers. Prior to version 1.14.1, in specific scenarios, models using conditions with caching enabled can result in two different check requests producing the same cache key. This could result in OpenFGA reusing an earlier cached result for a subsequent request. The preconditions for vulnerability are the model having relations which rely on condition evaluation and the user having caching enabled. OpenFGA v1.14.1 contains a fix.

OpenFGA is an authorization/permission engine built for developers. In versions 0.1.4 through 1.13.1, when OpenFGA is configured to use preshared-key authentication with the built-in playground enabled, the local server includes the preshared API key in the HTML response of the /playground endpoint. The /playground endpoint is enabled by default and does not require authentication. It is intended for local development and debugging and is not designed to be exposed to production environments. Only those who run OpenFGA with `--authn-method` preshared, with the playground enabled, and with the playground endpoint accessible beyond localhost or trusted networks are vulnerable. To remediate the issue, users should upgrade to OpenFGA v1.14.0, or disable the playground by running `./openfga run --playground-enabled=false.`

OpenFGA is a high-performance and flexible authorization/permission engine built for developers and inspired by Google Zanzibar. From 1.8.0 to 1.13.1, under specific conditions, BatchCheck calls with multiple checks sent for the same object, relation, and user combination can result in improper policy enforcement. This vulnerability is fixed in 1.14.0.

OpenFGA is a high-performance and flexible authorization/permission engine built for developers and inspired by Google Zanzibar. In versions prior to 1.13.1, under specific conditions, models using conditions with caching enabled can result in two different check requests producing the same cache key. This can result in OpenFGA reusing an earlier cached result for a different request. Users are affected if the model has relations which rely on condition evaluation andncaching is enabled. OpenFGA v1.13.1 contains a patch.

OpenFGA is a high-performance and flexible authorization/permission engine built for developers and inspired by Google Zanzibar. OpenFGA v1.8.5 to v1.11.2 ( openfga-0.2.22<= Helm chart <= openfga-0.2.51, v.1.8.5 <= docker <= v.1.11.2) are vulnerable to improper policy enforcement when certain Check calls are executed. The vulnerability requires a model that has a a relation directly assignable by a type bound public access and assignable by type bound non-public access, a tuple assigned for the relation that is a type bound public access, a tuple assigned for the same object with the same relation that is not type bound public access, and a tuple assigned for a different object that has an object ID lexicographically larger with the same user and relation which is not type bound public access. This vulnerability is fixed in v1.11.3.