CVE-2026-55170: 
Grafana vulnerability analysis and mitigation

CVE-2026-55170 is an authorization bypass vulnerability in OpenFGA, an open-source authorization/permission engine, caused by improper handling of case sensitivity when MySQL is used as the datastore. When authorization decisions rely on case-sensitive user strings, the tuple, changelog, and authorization_model identifier columns use a case-insensitive collation by default, causing distinct identifiers such as user:Alice and user:alice to be treated as equivalent. This results in two distinct authorization check requests returning the same response, potentially granting unintended access. All OpenFGA versions prior to 1.18.0 (and Helm chart versions prior to 0.3.9) are affected. The vulnerability was disclosed on June 18, 2026, and carries a CVSS v3.1 base score of 5.4 (Medium) and a CVSS v4.0 base score of 2.1 (Low) (GitHub Advisory).

The root cause is classified as CWE-178 (Improper Handling of Case Sensitivity). MySQL's default collation for string columns is case-insensitive (e.g., utf8mb4_general_ci), meaning the tuple, changelog, and authorization_model identifier columns did not distinguish between case-variant strings at the database layer. The fix (schema migration 008) converts these columns to the utf8mb4_bin collation, which performs byte-exact comparisons, matching the behavior of PostgreSQL and SQLite backends. Exploitation requires an authenticated attacker (low privileges) and the specific deployment condition of MySQL as the datastore with case-sensitive user identifiers in the authorization model. The patch commit details the precise ALTER TABLE statements applied to the tuple, changelog, and authorization_model tables (GitHub Commit, GitHub Advisory).

Successful exploitation allows an authenticated user to bypass authorization controls by submitting check requests using a case-variant of another user's identifier (e.g., user:Alice instead of user:alice), potentially gaining access to resources or permissions intended for a different principal. The impact is limited to confidentiality and integrity — there is no availability impact — and is scoped to the vulnerable OpenFGA instance without lateral movement potential beyond the authorization decisions it governs. The vulnerability does not enable unauthenticated access or remote code execution, but in systems where OpenFGA enforces access to sensitive resources, the authorization bypass could expose confidential data or allow unauthorized actions (GitHub Advisory).

1. Identify target: Confirm the target OpenFGA deployment uses MySQL as its datastore and that authorization policies distinguish between case-variant user identifiers (e.g., user:Alice vs. user:alice).
2. Authenticate: Obtain valid low-privilege credentials or an API token for the OpenFGA instance.
3. Enumerate authorization model: Query the OpenFGA API to identify stores and authorization models that reference case-sensitive user identifiers.
4. Craft case-variant check request: Submit an authorization check request using a case-variant of a known privileged user identifier (e.g., send a check for user:Admin when the intended privileged user is user:admin).
5. Observe response: Due to MySQL's case-insensitive collation, the check returns the same authorization result as the case-exact identifier, granting the attacker the same access level as the target user.
6. Access resources: Use the authorization bypass to access resources or perform actions that should be restricted to the case-exact principal (GitHub Advisory, GitHub Commit).

• Logs: OpenFGA API access logs showing authorization check requests for user identifiers that differ only in case from known legitimate principals (e.g., user:Admin vs. user:admin); repeated check requests from the same source IP using multiple case variants of the same identifier.
• Database: MySQL tuple or changelog tables where rows with case-distinct identifiers (e.g., user:Alice and user:alice) are stored as a single row or return identical query results, indicating the pre-patch case-insensitive collation is still in effect.
• Application: Authorization decisions granting access to a principal whose exact-case identifier does not match any configured tuple, suggesting a case-insensitive match occurred.

Upgrade OpenFGA to version 1.18.0 or later, which ships schema migration 008 (008_collate_identifiers.sql) that converts the affected MySQL columns to utf8mb4_bin collation. For Helm chart deployments, upgrade to openfga-0.3.9 or later (Helm Chart Release). Important: The migration acquires a shared lock on the tuple and changelog tables, blocking writes; operators should drain traffic before applying the migration on production instances with active write load, and consult the operator runbook for the full procedure. As a temporary workaround if upgrading is not immediately possible, review authorization policies to avoid relying on case-sensitive user string differentiation when using MySQL, or migrate to PostgreSQL or SQLite, which are not affected by this issue (GitHub Advisory, OpenFGA v1.18.0 Release).

The OpenFGA maintainers credited researcher @sahajamoth for the detailed report and published a thorough security advisory alongside the fix, including an operator runbook for the required MySQL schema migration (GitHub Advisory). The v1.18.0 release notes include an explicit operational warning for MySQL users about the potentially disruptive nature of the migration (OpenFGA v1.18.0 Release). No significant broader media coverage or social media discussion has been observed for this vulnerability.