OpenFGA CVE-2026-55170
LOW
GHSA-cf98-j28v-49v6
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AC:H because exploitation requires MySQL datastore plus case-sensitive user string semantics; S:C because the authorization bypass affects downstream applications that depend on OpenFGA decisions.
Primary rating from Vendor (https://github.com/openfga/openfga).
CVSS VectorVendor: https://github.com/openfga/openfga
Lifecycle Timeline
3DescriptionCVE.org
Description
In OpenFGA, when MySQL is being used as the datastore, two distinct check requests can return the same response.
Preconditions
This applies if the following preconditions are met:
- You run OpenFGA with MySQL as the datastore
- Your authorization decisions rely on case-sensitive user strings.
Fix
Upgrade to OpenFGA 1.18.0 or greater.
Acknowledgements
OpenFGA would like to thank @sahajamoth for the detailed report.
AnalysisAI
OpenFGA's authorization Check API returns incorrect results when MySQL is configured as the datastore and authorization policies depend on case-sensitive user string differentiation. MySQL's default case-insensitive collations cause two distinct user identifiers - identical except for letter casing - to match the same stored authorization tuple, producing an 'allowed' response for a user identity that should be denied. This constitutes an improper policy enforcement flaw (GHSA-cf98-j28v-49v6) that can silently bypass fine-grained access controls in any deployment meeting the two required preconditions. No public exploit identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Technical ContextAI
OpenFGA is a CNCF-hosted open-source fine-grained authorization engine implemented in Go (CPE: pkg:go/github.com/openfga/openfga), based on Google's Zanzibar authorization model. It evaluates Check API requests by querying stored relationship tuples in a backend datastore. When MySQL is configured as that datastore, string comparisons for user identifiers inherit MySQL's default collation behavior. Common MySQL collations such as utf8mb4_general_ci and utf8mb4_0900_ai_ci perform case-insensitive string matching by default, meaning a stored tuple for 'alice@corp.com' is indistinguishable from a query for 'ALICE@CORP.COM' at the database layer. CWE-178 (Improper Handling of Case Sensitivity) precisely captures this root cause: the software's internal semantics expect case-sensitive user string matching, but the underlying storage and query layer silently normalizes case, collapsing distinct identities into the same authorization record and producing incorrect policy evaluation outcomes.
RemediationAI
Vendor-released patch: OpenFGA 1.18.0. Upgrade to OpenFGA 1.18.0 or greater as documented in the vendor security advisory at https://github.com/openfga/openfga/security/advisories/GHSA-cf98-j28v-49v6. For deployments that cannot immediately upgrade, the most reliable compensating control is to normalize all user identifier strings to a consistent case (e.g., lowercase) at the application layer before writing tuples to or querying OpenFGA - this eliminates the case-sensitivity dependency but requires coordinated changes across all tuple-writing and tuple-querying clients and may not be feasible without significant refactoring. An alternative database-level mitigation is to change the MySQL column collation for user string fields to a binary or case-sensitive collation (e.g., utf8mb4_bin), which would restore expected behavior; however, this requires a schema migration, thorough regression testing, and may affect query performance and indexing. A third option for teams with infrastructure flexibility is to migrate the datastore from MySQL to PostgreSQL, which is not affected by this class of collation issue.
Same weakness CWE-178 – Improper Handling of Case Sensitivity
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today