CVE-2025-25196: Critical Authorization Bypass in OpenFGA

CVE-2025-25196 is an authorization bypass in OpenFGA, rated critical by NVD (CVSS 9.8) and moderate by the project. Certain Check and ListObjects calls can return an allow they should not. The fix is OpenFGA v1.8.5, which is backwards compatible, and the advisory lists no workaround.

What's affected

• Product: OpenFGA, the authorization engine inspired by Google Zanzibar. Go module github.com/openfga/openfga, the Docker image openfga/openfga and the Helm chart.
• Affected: versions before 1.8.5 for the Go module and Docker image, and Helm chart versions before 0.2.22.
• Fixed: v1.8.5, and Helm chart 0.2.22. The advisory says the upgrade is backwards compatible.
• Conditions: the project lists four conditions that must all hold. The model has a relation that can be assigned both to public access and to a userset of the same type. A type bound public access tuple exists on an object. No userset tuple exists on that same object. The Check request's user is a userset of the same type as the public tuple's user type.
• Workarounds: none known, per the advisory.
• Severity note: NVD scores it 9.8, while the GitHub advisory rates it moderate (5.8 on CVSS v4). Read both before you decide urgency.

How to check if you're exposed

Start with the version your service reports.

# Docker or Compose
docker ps --format '{{.Names}} {{.Image}}' | grep -i openfga

# Go module in a repository
grep -n "openfga/openfga" go.mod

# Helm releases
helm list -A | grep -i openfga

Any version below 1.8.5, or chart below 0.2.22, is in range. Then work out whether your authorization model matches the pattern. Export your model and look for a relation whose allowed types include both a public wildcard for some type and a userset of that same type. If your model has no such relation, the stated conditions are not met, but upgrading is still the right move.

Last, check how your application calls OpenFGA. The risk comes from Check or ListObjects requests whose user field is a userset, so search your code for those calls.

What to do now

1. Upgrade OpenFGA to v1.8.5 or later, or Helm chart 0.2.22 or later, in every environment.
2. If your code embeds the Go module, update go.mod to the fixed version, rebuild and redeploy.
3. Review your authorization model for relations that allow both a public wildcard and a userset of the same type.
4. Run a small set of known deny cases against the upgraded service to confirm the right answers come back.
5. Look back through access decisions that matched the pattern and ask whether any allowed result was wrong.
6. Add the version check to your deployment pipeline so an old image tag fails review.

Why it matters

The weakness is improper authorization. The engine that decides allow or deny can return the wrong answer when a specific mix of tuples and model shape lines up. That is a hard class to find with a scanner because nothing looks broken. The service responds normally. It just says yes when the answer should be no.

• CWE-285 is improper authorization. A check exists, but it does not reliably decide whether the caller is allowed to do what they asked.

Authorization engines are an unusual place for a bug like this, because every application that relies on them inherits the mistake. The service is the policy decision point, and downstream code trusts it. The narrow conditions limit how many deployments are affected, which is part of why the project rates it lower than NVD does. Still, a wrong allow in an access check is a data exposure risk, so upgrade and re-test your negative cases rather than only your happy paths.

Try it yourself

When a clean fix exists, the work is mostly about finding every place it needs to land. This demo walks through that.

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

Quick check

Sources

• OpenFGA GitHub advisory GHSA-g4v5-6f5p-m38j

Last reviewed: 19 October 2026.