CVE-2026-55170: OpenFGA MySQL Case-Sensitivity Authorization Bypass

Technical summary

CVE-2026-55170 stems from case-insensitive string comparison in OpenFGA's MySQL datastore implementation. The vulnerability resides in how identifier columns for tuples, changelogs, and authorization_model entries are compared during lookups. MySQL's default collation behavior treats 'Alice' and 'alice' as equivalent matches, causing the authorization engine to return identical responses for distinct principals. This violates the expected case-sensitive semantics when authorization policies explicitly reference different user strings. The flaw is confined to MySQL deployments; other datastores (PostgreSQL, etc.) with case-sensitive collations are unaffected. The issue requires the attacker to be authenticated and to have crafted permission policies that rely on case-sensitive user string differentiation.

Business impact

Organizations using OpenFGA with MySQL risk authorization bypass scenarios where permission inheritance or denial rules intended for one user account leak to accounts with identical names differing only in case. This creates a compliance exposure if access control decisions are logged or audited separately per user identity but actually applied interchangeably. The impact scales with reliance on case-sensitive naming conventions for role-based or attribute-based access control. For applications managing sensitive operations—finance, healthcare, multi-tenant SaaS—this can undermine the separation of duties and audit trail integrity. Remediation is straightforward via a patch, but the window prior to detection could leave systems in a compromised authorization state.

Affected systems

OpenFGA versions prior to 1.18.0 using MySQL as the datastore are affected. This includes deployments of the core OpenFGA software and instances deployed via the OpenFGA Helm charts. Other storage backends (PostgreSQL, in-memory stores, or other databases with case-sensitive collation by default) do not exhibit this vulnerability. Affected organizations should verify their datastore configuration and OpenFGA version to determine exposure.

Exploitability

The vulnerability requires authentication and knowledge of a target user's identity plus an alternate casing variant of that identity. An authenticated user cannot directly observe authorization decisions for other users; they must either be in the same authorization domain or have prior intelligence about naming patterns. The exploit path is limited to authenticated contexts and does not propagate unauthenticated attacks. Practical exploitation depends on organizational naming practices—strict lowercase or uppercase conventions reduce risk, while mixed-case identifiers increase exposure. The CVSS score of 5.4 reflects these constraints: network accessibility, low attack complexity, and requirement for authentication, balanced against confidentiality and integrity impact.

Remediation

Upgrade OpenFGA to version 1.18.0 or later. This release corrects the case-sensitivity handling in MySQL identifier comparisons. For organizations unable to upgrade immediately, consider enforcing a strict naming convention (all lowercase or all uppercase) for user identifiers to eliminate case-variant collisions, though this is a compensating control and not a substitute for patching. Review authorization policies and audit logs for evidence of cross-user authorization leakage prior to remediation.

Patch guidance

Deploy OpenFGA 1.18.0 or newer in your environment. If using Helm charts, verify that the chart version pulls the patched OpenFGA image. Test the upgrade in a staging environment to confirm that case-sensitive authorization semantics are restored—specifically, verify that authorization checks for 'user:Alice' and 'user:alice' return distinct responses if policies differ. Rollback procedures should be documented in case of integration issues. No data migration is required; the fix is application-layer logic correction.

Detection guidance

Audit OpenFGA deployment version by running 'openfga --version' or checking container image tags. Query your MySQL database to identify cases where authorization tuples, changelogs, or authorization_model entries with case-distinct identifiers exist (e.g., SELECT DISTINCT identifier FROM tuples WHERE LOWER(identifier) = UPPER(identifier) is false). Review authorization decision logs for anomalies—identical responses to check requests from different user principals. If your organization enforces strict lowercase naming for all identifiers, the exposure is minimal; however, verify this across all authorization policies and user provisioning workflows.

Why prioritize this

This vulnerability warrants prompt but measured attention. The CVSS score of 5.4 (MEDIUM) reflects bounded exploitability and authentication requirement, but the integrity and confidentiality impact are real in multi-tenant or role-separated environments. It is not listed on the KEV catalog, indicating limited evidence of active exploitation in the wild. However, the fix is simple and low-risk, making remediation a sound investment. Prioritize patching for systems handling sensitive access control decisions or multi-tenant scenarios; lower-risk deployments can follow standard change management windows.

Risk score, explained

CVSS 3.1 score of 5.4 is assigned as MEDIUM. Attack Vector (N) reflects network accessibility of OpenFGA endpoints; Attack Complexity (L) captures straightforward case-variant exploitation; Privileges Required (L) mandates authentication; User Interaction (N) indicates no social engineering or user action needed. Confidentiality Impact (L) and Integrity Impact (L) reflect potential unauthorized information disclosure and policy subversion respectively; Availability Impact (N) means the service remains operational. The score appropriately penalizes the authentication requirement and limits on discoverability, but credits the authorization bypass potential.

Frequently asked questions