OpenFGA is an authorization and permission engine built for developers. Prior to 1.18.1, the ListUsers API could return a user that should have been excluded when an authorization relation used an intersection containing a base but not excluded operand, the base was granted through a type-bound public wildcard, and the excluded user also had a concrete tuple through another intersection operand. In pkg/server/commands/listusers/listusersrpc.go, expandIntersection counted the concrete tuple and wildcard without first rejecting entries in excludedUsersMap. Applications that used ListUsers to enumerate or enforce access could therefore treat an excluded user as authorized. This issue is fixed in version 1.18.1.

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.

Description

In OpenFGA, under specific conditions, BatchCheck calls with multiple checks sent for the same object, relation, and user combination can result in improper policy enforcement.

Am I affected?

You are affected if you meet the following preconditions: 1. You execute BatchCheck operations which rely on context. 2. Multiple checks are sent within a single BatchCheck operation for the same user/object/relation combination, each containing context. 3. The contexts between those checks differ in a specific way

Fix Upgrade to OpenFGA v1.14.0

Acknowledgement OpenFGA would like to thank @bugbunny-research for the discovery and detailed report.

Description

OpenFGA's OIDC authenticator skipped JWT audience (aud) validation when no audience was configured. In deployments where one identity provider issues tokens for multiple services, a token minted for an unrelated service could authenticate to OpenFGA.

Preconditions

This applies if the following preconditions are met:

1. You run OpenFGA with authn.method set to oidc. 2. You configured authn.oidc.issuer but did not set authn.oidc.audience (--authn-oidc-audience / OPENFGAAUTHNOIDCAUDIENCE).

Fix

Upgrade to OpenFGA 1.18.0 or greater. OpenFGA now refuses to start in oidc mode unless both authn.oidc.issuer and authn.oidc.audience are set, and the aud claim is always validated.

Acknowledgements

OpenFGA would like to thank https://github.com/0xVijay for the report.

Description

In OpenFGA, when MySQL is being used as the datastore, two distinct check requests can return the same response.

Preconditions

This applies if the following preconditions are met:

1. You run OpenFGA with MySQL as the datastore 2. Your authorization decisions rely on case-sensitive user strings.

Fix Upgrade to OpenFGA 1.18.0 or greater.

Acknowledgements OpenFGA would like to thank @sahajamoth for the detailed report.

Description In OpenFGA, 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.

Preconditions This applies if the following preconditions are present:

- FGA runs with SharedIteratorCache enabled, - FGA runs with ListObjectsIteratorCache enabled.

Fix Upgrade to version 1.16.0 or greater.

Acknowledgements OpenFGA would like to thank @j4xT for the discovery and the detailed report.

OpenFGA is a high-performance and flexible authorization/permission engine built for developers and inspired by Google Zanzibar. OpenFGA < v1.8.4 (Helm chart < openfga-0.2.22, docker < v.1.8.4) are vulnerable to authorization bypass when certain Check and ListObject calls are executed. Users on OpenFGA v1.8.4 or previous, specifically under the following conditions are affected by this authorization bypass vulnerability: 1. Calling Check API or ListObjects with a model that has a relation directly assignable to both public access AND userset with the same type. 2. A type bound public access tuple is assigned to an object. 3. userset tuple is not assigned to the same object. and 4. Check request's user field is a userset that has the same type as the type bound public access tuple's user type. Users are advised to upgrade to v1.8.5 which is backwards compatible. There are no known workarounds for this vulnerability.

Overview OpenFGA is vulnerable to a DoS attack. In some scenarios that depend on the model and tuples used, a call to ListObjects may not release memory properly. So when a sufficiently high number of those calls are executed, the OpenFGA server can create an "out of memory" error and terminate.

Fix Upgrade to v1.4.3. This upgrade is backwards compatible.

OPenFGA is an open source authorization/permission engine built for developers. OpenFGA versions v1.1.0 and prior are vulnerable to a DoS attack when Check and ListObjects calls are executed against authorization models that contain circular relationship definitions. Users are affected by this vulnerability if they are using OpenFGA v1.1.0 or earlier, and if you are executing Check or ListObjects calls against a vulnerable authorization model. Users are advised to upgrade to version 1.1.1. There are no known workarounds for this vulnerability. Users that do not have circular relationships in their models are not affected.

Description In OpenFGA, 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.

Am I Affected? Users are affected if their applications meet the following preconditions:

The model has relations which rely on condition evaluation. Caching is enabled.

Fix Upgrade to OpenFGA v1.14.1.

Acknowledgement OpenFGA would like to thank @bugbunny-research for the detailed report.

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.

Description In OpenFGA, 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.

Am I Affected? Users are affected if the following preconditions are met: 1. The model has relations which rely on condition evaluation. 1. Caching is enabled.

Fix Upgrade to OpenFGA v1.13.1.

Acknowledgement OpenFGA would like to thank @Amemoyoi for the discovery and responsible disclosure.

Impact 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.

Affected Users Users are affected by this vulnerability if all of the following preconditions are met: - OpenFGA v1.8.5 to v1.11.2 is being used - The model has a relation directly assignable by a type bound public access and assignable by type bound non-public access - A tuple is assigned for the relation that is a type bound public access - A tuple is assigned for the same object with the same relation that is not type bound public access - A tuple is 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

Fix Upgrade to v1.11.3. This upgrade is backwards compatible.

Workaround None

Overview OpenFGA v1.8.0 to v1.8.12 ( openfga-0.2.16 <= Helm chart <= openfga-0.2.31, v1.8.0 <= docker <= v.1.8.12) are vulnerable to authorization bypass when certain Check and ListObject calls are executed.

Am I Affected? If you are using OpenFGA v1.8.0 to v1.8.12, specifically under the following conditions, you are affected by this authorization bypass vulnerability: - Calling Check API or ListObjects with an authorization model that has a relationship directly assignable by both type bound public access and userset, and - There are check or list object queries with contextual tuples for the relationship that can be directly assignable by both type bound public access and userset, and - Those contextual tuples’s user field is an userset, and - Type bound public access tuples are not assigned to the relationship

Fix Upgrade to v1.8.13. This upgrade is backwards compatible.

Acknowledgments Okta would like to thank @udyvish for discovering this vulnerability.

Overview OpenFGA v1.9.3 to v1.9.4 ( openfga-0.2.40 <= Helm chart <= openfga-0.2.41, v1.9.3 <= docker <= v.1.9.4) are vulnerable to improper policy enforcement when certain Check and ListObject calls are executed.

Am I Affected? You are affected by this vulnerability if you are using OpenFGA v1.9.3 to v1.9.4, specifically under the following preconditions: - Calling Check API or ListObjects with an authorization model that has a relationship directly assignable by more than 1 userset with same type, and - There are check or list object queries that rely on the above relationship, and - You have userset tuples that are assigned to the above relationship

Fix Upgrade to v1.9.5. This upgrade is backwards compatible.

Workaround Downgrade to v1.9.2 with enable-check-optimizations removed from OPENFGAEXPERIMENTALS

Acknowledgments OpenFGA would like Dominic Harries and rrozza-apolitical to thank for discovering this vulnerability.

Overview Some end users of OpenFGA v1.5.0 or later are vulnerable to authorization bypass when calling Check or ListObjects APIs.

Am I Affected? You are very likely affected if your model involves exclusion (e.g. a but not b) or intersection (e.g. a and b) and you have any cyclical relationships. If you are using these, please update as soon as possible.

Fix Update to v1.5.3

Backward Compatibility This update is backward compatible.

OpenFGA is a high-performance and flexible authorization/permission engine built for developers and inspired by Google Zanzibar. OpenFGA v1.8.10 to v1.3.6 (Helm chart <= openfga-0.2.28, docker <= v.1.8.10) are vulnerable to authorization bypass when certain Check and ListObject calls are executed. This issue has been patched in version 1.8.11.

Overview OpenFGA v1.3.8 to v1.8.2 (Helm chart openfga-0.1.38 to openfga-0.2.19, docker v1.3.8 to v.1.8.2) are vulnerable to authorization bypass when certain Check and ListObject calls are executed.

Am I Affected? You are affected by this authorization bypass vulnerability if you are using OpenFGA v1.3.8 to v1.8.2, specifically under the following conditions: 1. Calling Check API or ListObjects with a model that uses conditions, and 2. OpenFGA is configured with caching enabled (OPENFGACHECKQUERYCACHEENABLED), and 3. Check API call or ListObjects API calls contain contextual tuples that include conditions.

Fix Upgrade to v1.8.3. This upgrade is backwards compatible.

Overview OpenFGA v1.4.0 to v1.11.0 (openfga-0.1.34 <= Helm chart <= openfga-0.2.48, v.1.4.0 <= docker <= v.1.11.0) are vulnerable to improper policy enforcement when certain Check and ListObject calls are executed.

Am I Affected? You are affected by this vulnerability if you meet the following preconditions: - You are using OpenFGA v1.4.0 to v1.11.0 - The model has a a relation directly assignable by a type bound pubic access with condition - The same relation is not assignable by a type bound public access without condition - You have a type assigned for the same relation that is a type bound public access without condition

Fix Upgrade to v1.11.1. This upgrade is backwards compatible.

Workaround None