CVE-2026-33729

What it actually does

OpenFGA versions before 1.13.1 can generate identical cache keys for different authorization check requests when an authorization model uses conditional relations and caching is enabled. Under those conditions, OpenFGA may return a previously cached authorization decision for a different request instead of evaluating the current request independently. The technical impact is an authorization decision integrity failure: access may be incorrectly allowed or incorrectly denied based on stale or mismatched condition evaluation. This is not remote code execution, but it can undermine every application decision that depends on OpenFGA for fine-grained authorization.

Why it matters to the business

Applications that rely on OpenFGA for permissions may grant users access they should not have, or deny legitimate access, when affected authorization models and caching are in use. In business terms, this can lead to unauthorized viewing or modification of protected resources, tenant or workspace access boundary failures, compliance exposure, customer trust impact, and operational incidents caused by incorrect permission enforcement. Although EPSS is currently low and there is no known KEV listing or mature public exploitation signal, the high severity means organizations using conditional authorization models with caching should treat remediation as urgent because the flaw affects a core access-control component.

How an attack unfolds

An attacker needs a way to trigger OpenFGA authorization checks through an application or API that uses a vulnerable OpenFGA deployment. The attacker identifies functionality where access decisions depend on conditional relationships, such as checks involving contextual attributes, time, resource state, request metadata, or other condition inputs. By issuing a sequence of requests that cause one authorization result to be cached and then submitting a different request whose condition inputs collide into the same cache key, the attacker may receive the cached decision for the earlier request. If the earlier cached result was an allow decision, the later request may be incorrectly allowed even though its own condition evaluation should have denied access. Exploitation is application-specific because the attacker must influence or sequence authorization checks in a model that uses conditions with caching enabled, but successful exploitation can bypass intended permission boundaries without compromising OpenFGA hosts directly.

How to fix it

Upgrade OpenFGA to version 1.13.1 or later. The upstream advisory states that OpenFGA v1.13.1 contains the patch for this cache-key collision issue. Prioritize deployments where authorization models use conditions and OpenFGA check-result caching is enabled. If immediate upgrade is not possible, reduce exposure by disabling affected authorization-result caching where feasible, reviewing or temporarily simplifying authorization models that rely on conditions, and adding compensating authorization checks in the application for especially sensitive operations. After upgrading, restart OpenFGA services and clear any existing authorization decision caches so vulnerable cached entries are not reused.

How to confirm the fix worked

Confirm the running OpenFGA version is 1.13.1 or later across all deployed instances, containers, images, packages, and managed runtime definitions. Review OpenFGA configuration and authorization models to determine whether conditional relations and caching were enabled before remediation. Validate that caches were flushed or recreated after upgrade. Perform regression testing with pairs of authorization check requests that differ only in condition inputs and confirm each request is evaluated independently and returns the expected decision. For production assurance, compare application-level authorization behavior before and after upgrade for sensitive actions, and verify no unexpected allow decisions occur when condition values change.

Typical attack path

1. Find an application or API protected by OpenFGA authorization checks.
2. Identify actions or resources where access is controlled by conditional relations and where authorization-result caching is enabled.
3. Trigger an authorization check that produces a favorable cached result, such as an allowed decision for a permitted object, context, or condition set.
4. Send a different authorization check crafted so that the vulnerable cache-key generation treats it as equivalent to the earlier request.
5. Receive the reused cached authorization result instead of a fresh condition evaluation.
6. Use the incorrect allow decision to access or modify resources outside the attacker’s intended permissions, or cause denial of legitimate access if the cached result is a denial.

How to detect it

There are no universal file, process, or network indicators for exploitation because this is an authorization logic flaw rather than a malware-style compromise. To assess possible prior exploitation, collect OpenFGA check/query logs, application access logs, API gateway logs, and audit logs for protected resource access. Focus on periods before upgrade where affected versions were running with conditional models and caching enabled. Look for sequences where the same principal, session, token, or source IP repeatedly attempted similar actions with different condition inputs or resource identifiers, followed by an unexpected successful access decision. Compare OpenFGA authorization check outcomes with application audit events: investigate cases where access was allowed despite the user lacking the expected relationship, condition, entitlement, time window, resource state, or contextual attribute. If debug or structured authorization logs include cache metadata, search for cache hits on check requests that differ in condition context. Also review customer support reports, access-denied/allowed anomalies, and administrative audit trails for unexplained permission changes or access to sensitive resources without corresponding grants. Threat-actor-specific indicators are not currently available, and the CVE is not known to be used in ransomware campaigns or listed in CISA KEV as of the provided data.

What your security team should do

• Inventory all OpenFGA deployments and identify versions older than 1.13.1.
• Prioritize upgrade of any deployment using conditional relations with caching enabled.
• Upgrade to OpenFGA 1.13.1 or later and clear authorization decision caches after deployment.
• If upgrade cannot be completed immediately, disable affected caching paths or reduce reliance on conditional authorization models for sensitive operations until patched.
• Review high-risk authorization models for conditions protecting cross-tenant, administrative, financial, privacy-sensitive, or destructive actions.
• Increase monitoring for unusual authorization check sequences, unexpected access grants, and access to resources shortly after similar permitted checks.
• Coordinate application regression testing to ensure permission decisions remain correct after the upgrade.
• Because EPSS is currently low and there is no KEV listing, prioritize based on actual use of OpenFGA conditions and caching rather than internet exposure alone.