GHSA-gj7m-853r-289r
MEDIUMGrafana when using email as a username can block other users from signing in
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/grafana/grafana🐹github.com/grafana/grafanaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Today we are releasing Grafana 9.2. Alongside with new features and other bug fixes, this release includes a Moderate severity security fix for CVE-2022-39229
We are also releasing security patches for Grafana 9.1.8 and Grafana 8.5.14 to fix these issues.
Release 9.2, latest release, also containing security fix:
Release 9.1.8, only containing security fix:
Release 8.5.14, only containing security fix:
Appropriate patches have been applied to Grafana Cloud and as always, we closely coordinated with all cloud providers licensed to offer Grafana Pro. They have received early notification under embargo and confirmed that their offerings are secure at the time of this announcement. This is applicable to Amazon Managed Grafana and Azure's Grafana as a service offering.
Improper authentication - CVE-2022-39229
Summary
On September 7 as a result of an internal security audit we have discovered a security vulnerability in Grafana basic authentication, related to the usage of username and email address.
In Grafana, a user’s username and email address are unique fields, that means no other user can have the same username or email address as another user.
In addition, a user can have an email address as a username and Grafana login allows users to sign in with either username or email address. This creates an unusual behavior, where user_1 can register with one email address and user_2 can register their username as user_1’s email address. As a result, user_1 would be prevented to sign in Grafana, since user_1 password won’t match with users_2 email address.
The CVSS score for this vulnerability is 4.3 Moderate (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L).
Impacted versions
All installations for Grafana versions <=9.x, <=8.x
Solutions and mitigations
To fully address CVE-2022-39229 please upgrade your Grafana instances. Appropriate patches have been applied to Grafana Cloud.
Reporting security issues
If you think you have found a security vulnerability, please send a report to [email protected]. This address can be used for all of Grafana Labs' open source and commercial products (including, but not limited to Grafana, Grafana Cloud, Grafana Enterprise, and grafana.com). We can accept only vulnerability reports at this address. We would prefer that you encrypt your message to us by using our PGP key. The key fingerprint is
F988 7BEA 027A 049F AE8E 5CAA D125 8932 BE24 C5CA
The key is available from keyserver.ubuntu.com.
Security announcements
We maintain a security category on our blog, where we will always post a summary, remediation, and mitigation details for any patch containing security fixes.
You can also subscribe to our RSS feed.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/grafana/grafana | all versions | 8.5.14 |
| 🐹Go | github.com/grafana/grafana | ≥ 9.0.0&&< 9.1.8 | 9.1.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/grafana/grafana. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/grafana/grafana to 8.5.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gj7m-853r-289r is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-gj7m-853r-289r is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-gj7m-853r-289r. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-gj7m-853r-289r in your dependencies?
O3 detects GHSA-gj7m-853r-289r across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.