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.
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.
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.
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.
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.
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.
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 …
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 …
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 …
Overview OpenFGA v1.8.10 or previous (Helm chart <= openfga-0.2.28, docker <= v.1.8.10) are vulnerable to authorization bypass when certain Check and ListObject calls are executed.
Overview OpenFGA v1.8.4 or previous (Helm chart < openfga-0.2.22, docker < v.1.8.5) are vulnerable to authorization bypass when certain Check and ListObject calls are executed. Am I Affected? If you are using OpenFGA v1.8.4 or previous, specifically under the following conditions, you are affected by this authorization bypass vulnerability: Calling Check API or ListObjects with a model that has a relation directly assignable to both public access AND userset with …
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: Calling Check API or ListObjects with a model that uses conditions, and OpenFGA is configured with caching enabled (OPENFGA_CHECK_QUERY_CACHE_ENABLED), …
Overview OpenFGA v1.5.7 and v1.5.8 are vulnerable to authorization bypass when calling Check API with a model that uses but not and from expressions and a userset. For example, with a model like the following model schema 1.1 type user type role relations define assignee: [user] type permission relations define assignee: assignee from role define role: [role] type job relations define can_read: [permission#assignee] define problem: [user] but not can_read and …
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 …
OpenFGA, an authorization/permission engine, is vulnerable to a denial of service attack in versions prior to 1.4.3. 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. Version 1.4.3 contains a patch for this issue.
OpenFGA is a flexible authorization/permission engine built for developers and inspired by Google Zanzibar. Affected versions of OpenFGA is vulnerable to a denial of service attack. When a number of ListObjects calls are executed, in some scenarios, those calls are not releasing resources even after a response has been sent, and given a sufficient call volume the service as a whole becomes unresponsive. This issue has been addressed in version …
OpenFGA is an authorization/permission engine built for developers and inspired by Google Zanzibar. OpenFGA is vulnerable to a denial of service attack when certain Check calls are executed against authorization models that contain circular relationship definitions. When the call is made, it's possible for the server to exhaust resources and die. Users are advised to upgrade to v1.3.2 and update any offending models. There are no known workarounds for this …
OpenFGA is an authorization/permission engine built for developers and inspired by Google Zanzibar. Some end users of OpenFGA v1.3.0 or earlier is vulnerable to authorization bypass when calling the ListObjects API. The vulnerability affects customers using ListObjects with specific models. The affected models contain expressions of type rel1 from type1. This issue has been patched in version 1.3.1.
OPenFGA is an open source authorization/permission engine built for developers. OpenFGA versions v1.1.0 and prior is 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 …
OpenFGA is an authorization/permission engine built for developers and inspired by Google Zanzibar. During an internal security assessment, it was discovered that OpenFGA version 0.3.0 is vulnerable to authorization bypass under certain conditions. This issue has been patched in version 0.3.1 and is backward compatible.
OpenFGA is a high-performance authorization/permission engine inspired by Google Zanzibar. Versions prior to 0.2.5 is vulnerable to authorization bypass under certain conditions. You are affected by this vulnerability if you added a tuple with a wildcard (*) assigned to a tupleset relation (the right hand side of a ‘from’ statement). This issue has been patched in version v0.2.5. This update is not backward compatible with any authorization model that uses …
OpenFGA is an authorization/permission engine. Versions prior to version 0.2.4 is vulnerable to authorization bypass under certain conditions. Users who have wildcard (*) defined on tupleset relations in their authorization model is vulnerable. Version 0.2.4 contains a patch for this issue.
OpenFGA is an authorization/permission engine. Prior to version 0.2.4, the streamed-list-objects endpoint was not validating the authorization header, resulting in disclosure of objects in the store. Users openfga/openfga versions 0.2.3 and prior who are exposing the OpenFGA service to the internet is vulnerable. Version 0.2.4 contains a patch for this issue.
OpenFGA is an authorization/permission engine. Versions prior to version 0.2.4 is vulnerable to authorization bypass under certain conditions. Users whose model has a relation defined as a tupleset (the right hand side of a ‘from’ statement) that involves anything other than a direct relationship (e.g. ‘as self’) is vulnerable. Version 0.2.4 contains a patch for this issue.