CVE-2025-25196

Executive Summary

CVE-2025-25196 is an authorization bypass vulnerability in OpenFGA, a high-performance authorization engine inspired by Google Zanzibar. The flaw affects versions prior to v1.8.5 (Helm chart < openfga-0.2.22, docker < v1.8.4). It allows an attacker to bypass access controls when specific conditions involving type-bound public access tuples and userset tuples are met. The vulnerability can lead to unauthorized access to protected resources, potentially exposing sensitive data or allowing privilege escalation. The patch is backwards compatible, and no known workarounds exist.

Supply Chain & Package Security

OpenFGA is a Go-based project. 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 v1.8.5 or later. The Helm chart and Docker images are also affected.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
• Base Score: 9.1 (Critical)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H)
• Integrity Impact: High (I:H)
• Availability Impact: None (A:N)

Threat Level: Critical. The vulnerability can be exploited remotely without authentication, leading to full bypass of authorization checks.

Deep Dive & Mechanics

The vulnerability arises from a flaw in how OpenFGA resolves Check and ListObjects requests when a model has a relation that is directly assignable to both a public access type and a userset with the same type.

Conditions for Exploitation:

1. The authorization model defines a relation that can be assigned to both a type-bound public access (e.g., user:*) and a userset (e.g., group#member).
2. A type-bound public access tuple is assigned to an object (e.g., document:1#viewer@user:*).
3. A userset tuple is not assigned to the same object.
4. The Check request's user field is a userset that has the same type as the type-bound public access tuple's user type (e.g., user:alice).

Mechanism: When a Check request is made for a user that is a member of a userset (e.g., group:engineering#member), OpenFGA incorrectly resolves the type-bound public access tuple. It treats the userset as if it were a direct user, bypassing the intended restriction that public access should only apply to direct users, not usersets. This leads to an authorization bypass.

Vulnerable vs. Patched Code

Vulnerable Code (v1.8.4 and earlier): The issue is in the tuple resolution logic. The code does not properly differentiate between a direct user and a userset when evaluating type-bound public access tuples.

// Vulnerable pseudocode
func checkAccess(tuple, user) bool {
    if tuple.User == "user:*" {
        // Incorrectly grants access to any user, including usersets
        return true
    }
    // ... other checks
}

Patched Code (v1.8.5): The patched code adds a check to ensure that type-bound public access tuples only apply to direct users, not usersets.

// Patched pseudocode
func checkAccess(tuple, user) bool {
    if tuple.User == "user:*" && !isUserset(user) {
        return true
    }
    // ... other checks
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to an OpenFGA instance running v1.8.4 or earlier.
• Knowledge of the authorization model and existing tuples.

Exploitation Steps:

1. Identify a model where a relation is assignable to both user:* and a userset type (e.g., group#member).
2. Ensure a type-bound public access tuple exists (e.g., document:1#viewer@user:*).
3. Craft a Check request with a userset user field that has the same type as the public access tuple (e.g., user:alice).
4. Send the request. If the response indicates access is granted, the vulnerability is confirmed.

Example Request:

{
  "tuple_key": {
    "object": "document:1",
    "relation": "viewer",
    "user": "user:alice"
  }
}

Blue Team (Detection & Defense)

Detection:

• Monitor for Check and ListObjects requests that involve type-bound public access tuples and userset users.
• Look for anomalies in access patterns, such as users gaining access to objects they should not have.

Defense:

• Immediately upgrade to OpenFGA v1.8.5.
• Review authorization models to ensure relations are not assignable to both public access and usersets.
• Implement additional logging and alerting for suspicious Check requests.

Indicators of Compromise (IOCs)

• Log Entries: Check or ListObjects requests that return allowed: true for usersets when only type-bound public access tuples exist.
• Network Traffic: Unusual patterns of Check requests targeting objects with type-bound public access tuples.
• System Changes: Unexpected access to protected resources.

Detection Engineering

YARA Rule

rule CVE_2025_25196_OpenFGA_AuthBypass {
    meta:
        description = "Detects OpenFGA authorization bypass attempts"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-25196"
    strings:
        $check_api = "Check" nocase
        $list_objects = "ListObjects" nocase
        $public_access = "user:*" nocase
        $userset = "#" nocase
    condition:
        ($check_api or $list_objects) and $public_access and $userset
}

Sigma Rule

title: OpenFGA Authorization Bypass Attempt
id: cve-2025-25196
status: experimental
description: Detects attempts to exploit CVE-2025-25196 in OpenFGA
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: openfga
detection:
    selection:
        - "Check" in request
        - "ListObjects" in request
        - "user:*" in request
        - "#" in request
    condition: selection
falsepositives:
    - Legitimate use of type-bound public access with usersets (rare)
level: high

Suricata Rule

alert http any any -> any any (
    msg:"CVE-2025-25196 OpenFGA Authorization Bypass Attempt";
    flow:to_server;
    content:"Check"; http_uri;
    content:"user:*"; http_client_body;
    content:"#"; http_client_body;
    classtype:attempted-admin;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade OpenFGA to v1.8.5 (Helm chart openfga-0.2.22, docker v1.8.5).
2. Review and update authorization models to avoid relations that are assignable to both public access and usersets.

Long-term Measures:

• Implement regular security audits of authorization models.
• Monitor for new CVEs related to OpenFGA.
• Use network segmentation to limit exposure of OpenFGA instances.

Workarounds:

• No known workarounds exist. Upgrade is required.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert