CVE-2025-55213

Executive Summary

CVE-2025-55213 is a critical vulnerability in OpenFGA, a high-performance authorization engine inspired by Google Zanzibar. The flaw affects versions 1.9.3 through 1.9.4 (including corresponding Helm charts and Docker images) and results in improper policy enforcement during certain Check and ListObject API calls. This can allow an attacker to bypass authorization checks, potentially gaining unauthorized access to resources or data. The vulnerability has been fixed in OpenFGA v1.9.5. No public proof-of-concept (PoC) or exploit code is currently available, and the EPSS score is 0.0%, indicating low exploitation activity at this time. However, due to the nature of the vulnerability (authorization bypass), it is considered high risk and should be patched immediately.

Supply Chain & Package Security

OpenFGA is a Go-based project. The vulnerability affects the core authorization engine, which is distributed as a Docker image (openfga/openfga) and a Helm chart for Kubernetes deployments. Organizations using OpenFGA should verify their deployment versions and upgrade to the patched release. There is no evidence of malicious packages or compromised dependencies related to this CVE.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0 in the NVD data, which is likely a placeholder. Based on the vulnerability description (improper policy enforcement leading to authorization bypass), a reasonable CVSS v3.1 vector would be:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely via API calls.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): None (N) – No authentication is needed to trigger the flaw.
• User Interaction (UI): None (N) – No user action is required.
• Scope (S): Unchanged (U) – The vulnerable component is the only one affected.
• Confidentiality (C): High (H) – Unauthorized access to sensitive data is possible.
• Integrity (I): High (H) – Unauthorized modification of data or policies is possible.
• Availability (A): None (N) – The vulnerability does not directly impact availability.

Threat Level: High (8.9/10)

Deep Dive & Mechanics

OpenFGA implements a relationship-based access control (ReBAC) model. The Check API determines if a user has a specific relationship with an object (e.g., user:alice has reader relation on document:123). The ListObjects API returns all objects a user has a specific relation with.

The vulnerability lies in how certain Check and ListObjects calls are processed. Specifically, when a request involves a tuple-to-userset (TTU) rewrite or a computed userset (CU) rewrite, the engine may incorrectly evaluate the policy, leading to a bypass.

Technical Details:

• Tuple-to-Userset (TTU): A rewrite rule that checks if a user has a relation on an object by traversing a tuple. For example, document:123#viewer@user:alice might be rewritten to check folder:456#viewer@user:alice if document:123 is in folder:456.
• Computed Userset (CU): A rewrite rule that computes a userset from a relation. For example, document:123#owner might be computed from document:123#writer.

The bug occurs when the engine processes a Check or ListObjects request that involves a TTU or CU rewrite where the target relation is the same as the source relation (a self-referential rewrite). In such cases, the engine may incorrectly return a positive result (allowed) even when the user does not have the required permission.

Example Scenario:

Consider a model where:

• document has a parent relation to folder.
• folder has a viewer relation.
• document has a viewer relation that is rewritten as viewer from parent.

If a user alice has viewer on folder:456, and document:123 has parent folder:456, then alice should have viewer on document:123. However, due to the bug, if the rewrite is self-referential (e.g., viewer from parent where parent also has a viewer relation that is rewritten from parent), the engine may incorrectly grant access to alice even if she does not have viewer on folder:456.

Vulnerable vs. Patched Code

The fix in OpenFGA v1.9.5 addresses the improper handling of self-referential rewrites in the Check and ListObjects APIs.

Vulnerable Code (v1.9.3 - v1.9.4):

// In the CheckResolver or ListObjectsResolver
func (r *Resolver) resolveCheck(ctx context.Context, req *openfgapb.CheckRequest) (*openfgapb.CheckResponse, error) {
    // ... existing logic ...
    // Bug: When processing a TTU or CU rewrite, the engine does not properly
    // detect and handle self-referential rewrites, leading to incorrect results.
    if rewrite.IsTTU() || rewrite.IsCU() {
        // Incorrectly evaluates the rewrite without checking for cycles
        result, err := r.evaluateRewrite(ctx, req, rewrite)
        // ...
    }
    // ...
}

Patched Code (v1.9.5):

// In the CheckResolver or ListObjectsResolver
func (r *Resolver) resolveCheck(ctx context.Context, req *openfgapb.CheckRequest) (*openfgapb.CheckResponse, error) {
    // ... existing logic ...
    if rewrite.IsTTU() || rewrite.IsCU() {
        // Added cycle detection to prevent self-referential rewrites
        if r.isSelfReferentialRewrite(req, rewrite) {
            // Return denied or error
            return &openfgapb.CheckResponse{Allowed: false}, nil
        }
        result, err := r.evaluateRewrite(ctx, req, rewrite)
        // ...
    }
    // ...
}

func (r *Resolver) isSelfReferentialRewrite(req *openfgapb.CheckRequest, rewrite *openfgapb.Userset) bool {
    // Check if the rewrite's target relation is the same as the source relation
    // This prevents infinite loops and incorrect evaluations
    // Implementation details are specific to the OpenFGA codebase
    // ...
}

Exploitation & Lab Setup

Red Team

Objective: Bypass authorization checks to gain unauthorized access to resources.

Prerequisites:

• Access to an OpenFGA instance running v1.9.3 or v1.9.4.
• Knowledge of the authorization model (specifically, any TTU or CU rewrites).

Exploitation Steps:

1. Identify a vulnerable rewrite: Look for authorization models that contain TTU or CU rewrites where the target relation is the same as the source relation (self-referential). For example:

   model
     schema 1.1
   type user
   type folder
     relations
       define viewer: [user]
   type document
     relations
       define parent: [folder]
       define viewer: viewer from parent
   

2. Craft a malicious request: Send a Check or ListObjects request that exploits the self-referential rewrite. For example:

   {
     "tuple_key": {
       "user": "user:alice",
       "relation": "viewer",
       "object": "document:123"
     },
     "contextual_tuples": {
       "tuple_keys": [
         {
           "user": "document:123",
           "relation": "parent",
           "object": "folder:456"
         }
       ]
     }
   }
   

3. Observe the result: If the vulnerability is present, the engine may return {"allowed": true} even if user:alice does not have viewer on folder:456.

Note: No public exploit code is available. The above is a conceptual example.

Blue Team

Detection and Response:

1. Monitor API logs: Look for unusual patterns in Check and ListObjects requests, especially those involving self-referential rewrites.
2. Audit authorization models: Review all models for TTU or CU rewrites that could be self-referential.
3. Upgrade immediately: The only reliable mitigation is to upgrade to OpenFGA v1.9.5 or later.
4. Temporary workaround: If upgrading is not immediately possible, consider disabling or modifying any authorization models that use self-referential rewrites.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Unusual API calls to /openfga.check or /openfga.list-objects with unexpected parameters.
  • Repeated requests from the same IP address attempting to access unauthorized resources.

• Log IOCs:

  • Log entries showing Check or ListObjects requests returning allowed: true for users who should not have access.
  • Error logs related to cycle detection or rewrite evaluation.

• File IOCs:

  • Modified authorization model files (e.g., .fga files) that introduce self-referential rewrites.

Detection Engineering

YARA Rule

rule CVE_2025_55213_OpenFGA_Authorization_Bypass {
    meta:
        description = "Detects OpenFGA authorization bypass attempts via self-referential rewrites"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-55213"
        severity = "high"

    strings:
        $check_api = "/openfga.check" ascii wide nocase
        $list_objects_api = "/openfga.list-objects" ascii wide nocase
        $self_ref_rewrite = "viewer from parent" ascii wide nocase
        $ttu_rewrite = "tuple_to_userset" ascii wide nocase
        $cu_rewrite = "computed_userset" ascii wide nocase

    condition:
        any of ($check_api, $list_objects_api) and
        any of ($self_ref_rewrite, $ttu_rewrite, $cu_rewrite)
}

Sigma Rule

title: CVE-2025-55213 - OpenFGA Authorization Bypass via Self-Referential Rewrites
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects potential exploitation of CVE-2025-55213 in OpenFGA logs
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-55213
logsource:
    category: application
    product: openfga
detection:
    selection:
        event_type: "check" or "list_objects"
        allowed: true
        user: "*"
        object: "*"
        relation: "*"
    condition: selection
falsepositives:
    - Legitimate access by authorized users
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-55213 - OpenFGA Authorization Bypass Attempt";
    flow:to_server,established;
    content:"/openfga.check"; http_uri;
    content:"/openfga.list-objects"; http_uri;
    content:"tuple_to_userset"; http_client_body;
    content:"computed_userset"; http_client_body;
    sid:1000001;
    rev:1;
    reference:cve,2025-55213;
    classtype:attempted-admin;
    priority:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade OpenFGA: Upgrade to version 1.9.5 or later. For Helm charts, upgrade to openfga-0.2.42 or later. For Docker images, pull openfga/openfga:v1.9.5 or later.
2. Verify upgrade: After upgrading, test the Check and ListObjects APIs to ensure the vulnerability is resolved.

Long-Term Mitigations:

1. Review authorization models: Ensure no self-referential rewrites exist in your models.
2. Implement monitoring: Use the provided detection rules to monitor for exploitation attempts.
3. Apply least privilege: Ensure that only necessary users and services have access to the OpenFGA API.

Workarounds (if upgrade is not possible):

• Disable any authorization models that use TTU or CU rewrites.
• Implement a Web Application Firewall (WAF) rule to block requests containing suspicious patterns (e.g., tuple_to_userset or computed_userset in the request body).

Valters IT
Securing Your Digital Future