CVE-2024-56323: Critical Authorization Bypass in OpenFGA

CVE-2024-56323 is an authorization bypass (CVSS 9.8 in the record) in OpenFGA, the authorization engine. Releases 1.3.8 to 1.8.2 can give wrong answers under three specific conditions involving conditions, contextual tuples and the check query cache. Upgrade to v1.8.3, which the project says is backwards compatible.

What's affected

The OpenFGA advisory GHSA-32q6-rr98-cjqv lists these affected and patched versions:

• Go module github.com/openfga/openfga: 1.3.8 up to but not including 1.8.3. Patched in 1.8.3.
• Docker image openfga/openfga: the same range. Patched in 1.8.3.
• Helm chart: 0.1.38 up to but not including 0.2.19. Patched in 0.2.19.

You are affected only if all three of these are true. You call the Check API or ListObjects with a model that uses conditions. You call them with contextual tuples that include conditions. And OpenFGA is configured with the check query cache enabled, using the setting OPENFGA_CHECK_QUERY_CACHE_ENABLED.

One scoring note: the record carries a score of 9.8, while the project's own advisory rates it moderate, 5.8 under CVSS v4. The narrow set of conditions explains the gap. Read both and judge by your own configuration.

How to check if you're exposed

Find the running version. For containers, check the image tag, and for Go builds check the module version in go.mod:

grep openfga go.mod

Then test the three conditions against your setup:

• Does your authorization model use conditions? Search the model files for the condition keyword.
• Do your Check or ListObjects calls pass contextual tuples that carry conditions?
• Is the query cache switched on? Look in your environment variables, Helm values or config file for OPENFGA_CHECK_QUERY_CACHE_ENABLED.

If any one of the three is false, the advisory conditions are not met, and the upgrade becomes routine. If all three are true, treat it as urgent and plan to review decisions made while the flaw was present.

What to do now

1. Inventory OpenFGA deployments, including Helm releases, and note the version and the cache setting for each.
2. Upgrade to v1.8.3 or later. For Helm users, use chart 0.2.19 or later. The project describes the upgrade as backwards compatible.
3. The advisory lists no known workarounds, so do not rely on a configuration change in place of the upgrade.
4. If all three conditions were met, review access decisions from the period the vulnerable version ran, looking for grants that should not have happened.
5. Add a regression test that checks an expected denial through your real caching path.
6. Subscribe to the project's security advisories.

Why it matters

The record maps this to CWE-285, improper authorization. The problem is in the interaction between features, not in one of them alone. Conditions let a relationship depend on context at request time. Contextual tuples let a caller supply extra facts for a single check. A cache stores the answer to avoid recomputing it. If the cache stores or reuses a result in a way that does not account for the conditions attached to the supplied tuples, a later request can receive an answer that was not meant for it.

That matters more than it sounds for an authorization engine, since every other service trusts the answer. A wrong allow becomes a data exposure somewhere else. It is also why the severity score is contested. The impact is high if you meet the conditions and near nothing if you do not. The KEV flag in the record is false.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• OpenFGA advisory GHSA-32q6-rr98-cjqv

Last reviewed: 19 October 2026.