Today, we're going to break down CVE-2022-24812, a privilege escalation vulnerability that affected Grafana Enterprise when using the "fine-grained access control" (FGAC) beta feature. If you're running an impacted version, this is something you’ll want to address right away — the bug puts your sensitive dashboards and data at risk.
Let's cover what happened, how it works, and how you can fix or mitigate it. We'll use simple, plain language and offer exclusive insight for a clear, hands-on understanding.
What Is Grafana?
Grafana is an open-source platform for monitoring, visualizing, and analyzing data from various sources. Its Enterprise edition adds features for large organizations, including fine-grained access controls, extra integrations, and more.
See the official site:
https://grafana.com/docs/grafana/latest/
Where’s the Bug?
When the fine-grained access control (_FGAC_) feature is enabled and users make requests with API keys, Grafana caches the permissions tied to those keys for 30 seconds per organization.
But there’s a catch:
> When building their cache ID (which tells Grafana which permissions to use), it does not consider the unique API key itself—just the organization and check type.
Consequence:
If someone makes a request with one API key with Admin rights, and shortly after another, less privileged key (like a Viewer) makes a request, the SECOND request fetches the Admin's cached permissions from the first one! The Viewer key can now act as an Admin for up to 30 seconds.
The Exploit: Step by Step
Here’s how an attacker could escalate privileges in a targeted org.
2. Admin Makes a Request
User A sends a privileged request, say, to create or delete a dashboard. Grafana checks the key and caches the result:
# Pseudocode for cache
cache.set((org_id, check_type), permissions="admin", timeout=30)
Within 30 seconds, User B uses their viewer API key for the same endpoint
# User B sends a viewer request, but cache returns "admin"
permissions = cache.get((org_id, check_type)) # returns "admin"
if permissions == "admin":
# User B can delete dashboards!
delete_dashboard()
The API sees the cache and uses the Admin permissions—so the Viewer is unwittingly upgraded to Admin, for any requests matching that type and org, during the cache window.
Example HTTP Requests
# 1. Admin deletes a dashboard (cache created)
curl -H "Authorization: Bearer ADMIN_KEY" \
-X DELETE "https://grafana.example.com/api/dashboards/uid/abc123";
# 2. Viewer (within 30s) deletes another dashboard (unauthorized, but works!)
curl -H "Authorization: Bearer VIEWER_KEY" \
-X DELETE "https://grafana.example.com/api/dashboards/uid/xyz789";
Result: If the cache is warm (recent Admin request for the same action), the viewer's request gets granted as if they are admin!
Responsible Disclosure and References
This bug was responsibly reported on GitHub’s Security Advisory portal, and promptly fixed by the Grafana team in April 2022.
Official advisories and links
- GitHub Security Advisory
- Grafana Blog Post
- NVD Entry
You have fine-grained access control enabled.
- There are two or more API keys in use in the same organization, and those keys have different permission levels.
If you’re running open-source Grafana, or have only one API key, or do not use fine-grained access control—you’re safe.
## How to Fix / Mitigate
1. Upgrade Grafana
Grafana fixed the bug in Enterprise v8.3.5 and later.
> Update to the latest Enterprise release as soon as possible!
2. Temporary Mitigation
Limit the number or usage of API keys.
3. Review API Key Usage
Check your logs for any suspicious usage of your Viewer or Editor-type API keys. Consider rotating keys after patching.
Summary Table
| Grafana Version | Is FGAC Enabled? | Multiple API Keys with Mixed Roles? | Vulnerable? | Fix |
|--------------------|:----------------:|:-----------------------------------:|:-----------:|:-------------|
| < v8.1.-beta1 | Any | Any | No | - |
| v8.1.-beta1—8.3.5 | Yes | Yes | Yes | Upgrade |
| v8.1.-beta1—8.3.5 | No | Any | No | - |
| >= 8.3.5 | Any | Any | No | - |
Conclusion
CVE-2022-24812 is a classic case of "cache confusion" — user credentials were cached too broadly, enabling privilege escalation. Grafana’s quick fix involved making the API key itself part of the cache ID, making sure each user’s permissions are checked fairly.
If you’re a Grafana Enterprise user with fine-grained access control, upgrade your deployment. In the meantime, consider temporarily disabling FGAC if you can’t patch right away.
More Resources
- Grafana Fine Grained Access Control Docs
- Grafana GitHub Release Notes
For hands-on questions or help, feel free to post below or contact Grafana support. Stay safe and keep your dashboards secure!
Timeline
Published on: 04/12/2022 17:15:00 UTC
Last modified on: 05/19/2022 20:15:00 UTC