CVE-2026-33729: 
NixOS vulnerability analysis and mitigation

CVE-2026-33729 is an authorization bypass vulnerability in OpenFGA, a high-performance authorization/permission engine inspired by Google Zanzibar. Under specific conditions, models using conditions with caching enabled can produce two different check requests that generate the same cache key, causing OpenFGA to return a cached authorization result intended for a different request. All versions prior to 1.13.1 of the Go module github.com/openfga/openfga, Docker image openfga/openfga, and Helm chart openfga-0.2.58 and earlier are affected. The vulnerability was disclosed on March 25, 2026, and patched in v1.13.1. It carries a CVSS v4 score of 5.8 (Medium) and a CVSS v3.1 score of 9.8 (Critical) (GitHub Advisory, OpenFGA Advisory).

The root cause is improper cache key construction in OpenFGA's pkg/storage/cache.go when serializing condition context values for Check requests (CWE-20: Improper Input Validation; CWE-1289: Improper Validation of Unsafe Equivalence in Input). Specifically, the writeValue function did not strip Unicode control characters from string values, and the writeStruct function did not encode the number of keys in the serialized output. This allowed a crafted context payload — for example, a single-key struct with a value containing Unicode backspace characters () — to produce an identical cache key to a legitimately different multi-key struct. The fix in commit 049b50c strips control characters (replacing them with ?) and prepends the key count to the serialized struct, ensuring distinct inputs produce distinct cache keys. Exploitation requires that the target model has relations relying on condition evaluation and that caching is enabled (GitHub Advisory, Patch Commit).

Successful exploitation allows an attacker to bypass authorization checks by causing OpenFGA to return a cached "allowed" result from a prior legitimate request in response to a different, unauthorized request. This can lead to unauthorized access to protected resources (confidentiality breach), unauthorized modifications to data (integrity violation), and potential disruption of access control enforcement across downstream systems that rely on OpenFGA (availability impact). The impact is primarily on systems downstream of the vulnerable OpenFGA instance, as the vulnerable system itself does not directly expose confidentiality or integrity issues — rather, the authorization decisions it produces are corrupted (GitHub Advisory, OpenFGA Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability was responsibly disclosed by researcher @Amemoyoi. The EPSS score is approximately 0.012% (6th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to have at least low-level privileges (e.g., the ability to submit Check API requests) and knowledge of the target model's condition structure (GitHub Advisory).

1. Reconnaissance: Identify an OpenFGA instance running a version prior to 1.13.1 with caching enabled and an authorization model that uses conditional relations (e.g., attribute-based access control conditions).
2. Understand the target model: Obtain or infer the structure of the authorization model, specifically which relations use condition evaluation and what context parameters those conditions expect.
3. Craft a collision payload: Construct a Check API request whose condition context, when serialized by the vulnerable cache key function, produces the same cache key as a different, previously cached request. This can be achieved by embedding Unicode control characters (e.g., backspace \u0008) in string values to manipulate the serialized key — for example, a context {"a": "y", "b": "\u0008\u0008\u0008\u0008\u0008\u0008x"} could collide with {"a": "x"} in unpatched versions.
4. Prime the cache: Ensure a legitimate authorized Check request is processed and cached by the target OpenFGA instance, establishing the cached "allowed" result.
5. Submit the collision request: Send the crafted Check request with the colliding cache key. OpenFGA returns the cached "allowed" result from the prior legitimate request, granting unauthorized access.
6. Leverage unauthorized access: Use the bypassed authorization decision to access protected resources or perform actions that should have been denied (Patch Commit, GitHub Advisory).

• Network: Repeated Check API requests to the OpenFGA endpoint with condition context values containing Unicode control characters (e.g., \u0008 backspace sequences) in string fields.
• Logs: OpenFGA access logs showing Check requests with structurally unusual context payloads — particularly single-key contexts with long string values containing non-printable characters, or requests that receive "allowed" responses inconsistent with the expected authorization policy.
• Behavioral: Authorization decisions that appear inconsistent with the configured model — e.g., a user being granted access to a resource they should not have access to, especially when caching is active and condition-based relations are in use.

The primary remediation is to upgrade OpenFGA to version 1.13.1 or later (Go module, Docker image openfga/openfga:v1.13.1, or Helm chart openfga-0.2.59), which contains the fix for this vulnerability (OpenFGA Release, OpenFGA Advisory). For organizations unable to patch immediately, disabling caching on models that rely on condition evaluation eliminates the attack surface, as the vulnerability only manifests when both conditions and caching are active. After patching or applying the workaround, review authorization logs for any anomalous access patterns that may indicate prior exploitation.

The vulnerability was responsibly disclosed by researcher @Amemoyoi and acknowledged by the OpenFGA team, who credited @Amemoyoi in the advisory. The fix was developed by contributors justincoh and saad-h1 under the guidance of maintainer adriantam. No significant broader media coverage or notable community controversy has been identified beyond the standard advisory publication (GitHub Advisory).