OpenFGA CVE-2026-55170
LOWSeverity 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
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
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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Both of the following conditions must be true simultaneously for exploitation to be possible: (1) OpenFGA must be deployed with MySQL as the backend datastore - instances using PostgreSQL, SQLite, or the built-in in-memory store are entirely unaffected regardless of version; and (2) the application's authorization model must treat user strings as case-sensitive, meaning 'alice@corp.com' and 'ALICE@CORP.COM' are intended to represent distinct principals with potentially different permission sets. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | No CVSS vector or EPSS score was provided for this CVE, preventing quantitative risk comparison. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker with knowledge of a privileged user's OpenFGA user string - for example, 'Admin@corp.com' - submits a Check API request using a case-variant of that identifier, such as 'admin@corp.com', against an OpenFGA instance backed by MySQL. MySQL's case-insensitive collation matches the stored authorization tuple for 'Admin@corp.com', and OpenFGA returns an 'allowed' response for the attacker's alternate-case identity, which legitimately holds no such permission. … |
| Remediation | Vendor-released patch: OpenFGA 1.18.0. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-178 – Improper Handling of Case Sensitivity
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-cf98-j28v-49v6