CVE-2026-41131

What it actually does

OpenFGA versions prior to 1.14.1 can incorrectly reuse cached authorization check results when an authorization model uses conditions and check-result caching is enabled. In affected scenarios, two logically different check requests can generate the same cache key, causing the result of an earlier permission decision to be applied to a later request. Depending on which result is reused, this can incorrectly allow access that should be denied, deny access that should be allowed, or return stale authorization behavior. The issue requires a model that relies on condition evaluation and an attacker or user capable of making relevant authorization check requests, so exploitation is scenario-dependent and has high complexity.

Why it matters to the business

Applications that rely on OpenFGA for access control may make incorrect authorization decisions, potentially exposing data or functions to users who should not have access, or disrupting legitimate user access. Because OpenFGA is commonly embedded as a central permission service, a flawed decision can affect multiple downstream applications or APIs that trust its responses. The current public exploitation signal is low: EPSS is approximately 0.00145 with no meaningful 30-day increase, it is not listed in CISA KEV, and no mature public exploit is indicated. However, organizations using conditional authorization models with caching enabled should treat the fix as important because authorization bypass flaws can directly undermine application security boundaries.

How an attack unfolds

An attacker first needs authenticated or otherwise permitted access to submit authorization checks through an application or service backed by OpenFGA. The attacker then identifies functionality where access decisions depend on OpenFGA conditions, such as contextual attributes, time-based checks, object attributes, relationship metadata, or other conditional tuples. If caching is enabled, the attacker attempts to create or trigger two different check requests that should evaluate differently but collide on the same cache key. By causing a favorable authorization result to be cached first, the attacker may then submit a subsequent request that should be denied but receives the previously cached allow result. Successful exploitation depends heavily on the authorization model, the use of conditions, cache configuration, and the ability to influence request context; there are no known public exploitation campaigns or KEV-listed activity at this time.

How to fix it

Upgrade OpenFGA to version 1.14.1 or later. For deployments using OpenFGA Helm charts, update the chart and image values so the deployed OpenFGA server version is 1.14.1 or newer, then roll the service and confirm all replicas are running the fixed image. If immediate upgrade is not possible, reduce risk by disabling authorization check caching for affected deployments, especially where models use conditions, until the upgrade is complete. Review authorization models that use conditions and test high-risk relations to ensure decisions are evaluated independently and correctly. Avoid relying on cache invalidation alone as a permanent mitigation; the defect is in cache-key generation behavior and is fixed in the patched version.

How to confirm the fix worked

Confirm the deployed OpenFGA server version is 1.14.1 or later across all runtime instances, containers, and Helm-managed releases. Validate that the running image tag or binary version matches the expected fixed version, not only the repository or chart configuration. Review configuration to determine whether check caching is enabled and whether authorization models use conditions; systems meeting both criteria were in the vulnerable precondition set before upgrade. Run regression tests with pairs of authorization checks that differ only in condition context and verify that each request receives the correct independent decision. Where possible, compare behavior before and after the upgrade using representative conditional authorization models to confirm that differing condition inputs no longer produce incorrect reused results.

Typical attack path

1. Obtain access to an application or API that relies on OpenFGA for authorization checks.
2. Identify endpoints, objects, or actions where authorization decisions are based on conditional OpenFGA model logic.
3. Determine whether authorization check caching is enabled and whether repeated checks produce consistent cached behavior.
4. Trigger a check request that returns an authorization result favorable to the attacker and causes that result to be cached.
5. Submit a different check request whose condition evaluation should produce a different result but may reuse the same cache key.
6. Access data or perform an action using the incorrectly reused authorization decision.
7. Repeat the technique against other objects, relations, or actions that use similar conditional authorization patterns.

How to detect it

There is no universal network signature or file artifact for exploitation because abuse manifests as incorrect authorization decisions inside application workflows. To investigate possible prior exploitation, review OpenFGA service logs, application access logs, API gateway logs, and audit logs for protected actions whose authorization depends on conditional model evaluation. Focus on periods before the upgrade where caching was enabled and models used conditions. Look for repeated authorization checks from the same principal against different objects, relations, or condition contexts where an allow decision appears inconsistent with expected policy. Correlate OpenFGA check requests with downstream application actions: suspicious cases include successful object reads, writes, sharing changes, administrative actions, or data exports immediately following a pattern of repeated permission checks with changing contextual attributes. If OpenFGA debug or structured decision logs are available, compare condition inputs, relation names, tuple keys, request timestamps, and final decisions to identify pairs of different checks that received identical cached results despite different expected evaluations. Threat actor activity has not been publicly associated with this vulnerability, so detection should be behavior- and policy-focused rather than actor-IOC-focused.

• openfga
• OpenFGA
• check
• conditions
• cached
• cache
• authorization_model_id
• tuple_key
• user
• relation
• object
• allowed=true
• allowed=false

What your security team should do

• Inventory all OpenFGA deployments, including Helm-based deployments, sidecar deployments, development clusters, and embedded service deployments.
• Prioritize upgrade to OpenFGA 1.14.1 or later for any deployment using authorization model conditions with check caching enabled.
• Temporarily disable check-result caching on vulnerable deployments if upgrade cannot be completed promptly.
• Ask application teams to identify high-value actions and data paths protected by conditional OpenFGA checks and run targeted authorization regression tests.
• Review recent access events for unusual successful access to objects or actions protected by conditional relations, especially where the same user generated repeated checks with varying contextual attributes.
• Ensure CI/CD and infrastructure-as-code pin OpenFGA to a fixed, patched version rather than floating vulnerable tags.
• Because current EPSS and KEV signals are low, handle this as a prioritized authorization integrity fix rather than an emergency internet-wide exploitation event, unless local exposure or sensitive authorization models raise risk.