CVE-2026-48096

What it actually does

OpenFGA versions prior to 1.16.0 can return an incorrect authorization decision when iterator caching is enabled. The flaw is caused by cache-key collision between distinct authorization check requests: a result produced for one check can be reused for a different check that should have been evaluated independently. Depending on the cached decision, this can cause unauthorized allow decisions, incorrect deny decisions, or inconsistent permission evaluation. The issue requires a network-accessible OpenFGA service, a caller able to submit check requests, and application conditions that make colliding request patterns feasible; the assigned CVSS score of 5.0 reflects moderate impact with high attack complexity and required privileges.

Why it matters to the business

Applications relying on affected OpenFGA deployments may make incorrect access-control decisions, potentially allowing users or services to access data or actions they should not be allowed to use, or denying legitimate access and disrupting operations. Because OpenFGA is commonly used as a central authorization layer, a single vulnerable deployment can affect many downstream applications or services that depend on its decisions. The issue is not currently listed in CISA KEV, has no known mature public exploitation, and has a very low EPSS score, but it should still be prioritized where iterator caching is enabled or OpenFGA protects sensitive business functions.

How an attack unfolds

An attacker first needs legitimate ability to cause authorization check requests to be sent to an affected OpenFGA instance, typically through an application or service account that relies on OpenFGA for permission checks. The attacker then identifies request patterns where two logically distinct checks can generate the same iterator-cache key. By causing an initial request to populate the cache with a favorable result and then issuing a second distinct request that collides with that cache key, the attacker may cause OpenFGA to reuse the earlier result instead of evaluating the second request correctly. If the reused result is an allow decision, the attacker can gain access to an object, relationship, or operation that should have been denied. If the reused result is a deny or erroneous result, the attacker may cause authorization failures or operational disruption. Exploitation is likely to require knowledge of the application authorization model, relationship tuples, request timing, and whether iterator caching is enabled.

How to fix it

Upgrade OpenFGA to version 1.16.0 or later. For deployments installed through OpenFGA Helm charts, update the chart/application image so the running OpenFGA server version is 1.16.0 or later and verify all pods or instances have rolled forward. If immediate upgrade is not possible, disable iterator caching until patched, reduce exposure of the OpenFGA API to only trusted application components, enforce strong authentication and authorization between applications and OpenFGA, and monitor for unusual check-request patterns. After upgrade, clear or restart affected OpenFGA processes so stale in-memory cache state cannot persist. Review application authorization models and critical access paths for areas where a mistaken allow decision would create high business impact.

How to confirm the fix worked

Confirm the running OpenFGA server reports version 1.16.0 or later across every node, container, and deployment. Validate that Helm releases, container images, manifests, and runtime configuration are consistent and do not leave older OpenFGA instances serving traffic. If temporarily mitigating instead of upgrading, verify iterator caching is disabled in the effective runtime configuration, not only in source-controlled configuration. Run regression tests that issue distinct authorization checks with similar object, relation, user, contextual tuple, and model characteristics and confirm results are evaluated independently and consistently. Review application-level authorization tests for both expected allow and expected deny decisions. Monitor OpenFGA metrics and logs after remediation for error spikes, unexpected cache behavior, or authorization decision anomalies.

Typical attack path

1. Identify an application or API backed by an affected OpenFGA version prior to 1.16.0.
2. Confirm or infer that iterator caching is enabled in the OpenFGA deployment.
3. Use valid credentials, tokens, or an application workflow to trigger authorization check requests.
4. Map object, relation, user, contextual tuple, or model patterns that influence check behavior.
5. Send or cause a first check request that produces a cacheable authorization result.
6. Send or cause a second distinct check request that collides with the first request's iterator-cache key.
7. Rely on the reused cached result to obtain an incorrect allow decision, incorrect deny decision, or inconsistent authorization behavior.
8. Access protected functionality or data, or create operational disruption through incorrect authorization responses.

How to detect it

Retrospective detection is difficult because successful exploitation may appear as normal authorization check traffic followed by normal application access. Focus on correlating OpenFGA check logs, application access logs, API gateway logs, identity-provider logs, and audit events for cases where a user or service accessed an object or action shortly after a similar authorization check was made for a different object, relation, or user. Look for repeated check requests with highly similar structures, unusual sequencing of allowed and denied decisions, sudden increases in cache hit rates, and access to sensitive resources inconsistent with the user's known role or relationship tuples. Review OpenFGA deployment history to determine when vulnerable versions with iterator caching were active. If detailed authorization decision logging is available, compare historical check decisions against a patched OpenFGA instance or offline policy evaluation for high-risk objects. Investigate application events where access was granted despite missing expected relationship tuples, unexpected cross-object access, or inconsistent results for repeated checks. No named threat actors, ransomware campaigns, or KEV exploitation are currently associated with this issue based on the supplied data.

What your security team should do

• Inventory all OpenFGA deployments, including Helm-based installations, sidecar-style deployments, development clusters, and internally managed authorization services.
• Prioritize upgrade to OpenFGA 1.16.0 or later for deployments where iterator caching is enabled or where OpenFGA protects sensitive data, administrative actions, payment workflows, customer records, or cross-tenant boundaries.
• Disable iterator caching as a temporary mitigation if the upgrade cannot be completed immediately.
• Restrict network access to OpenFGA APIs so only trusted application services can submit check requests.
• Review recent authorization anomalies, access-denied support tickets, unexpected successful access events, and changes in application behavior since iterator caching was enabled or since the vulnerable version was deployed.
• Add application-level monitoring for high-risk authorization checks, especially denied-to-allowed transitions for sensitive objects or relations.
• Ensure CI/CD and Helm values pin OpenFGA to a fixed patched version rather than a floating or vulnerable image tag.
• Because the vulnerability is not in CISA KEV and EPSS is low, treat this as a risk-based remediation item rather than an emergency internet-wide exploitation event, unless the deployment is exposed or protects high-value authorization boundaries.