Grafana CVE-2021-43798: Directory Traversal in Everyone's Favorite Dashboard Tool

On December 3, 2021, a zero-day directory traversal vulnerability in Grafana began circulating on social media before an official patch was available. CVE-2021-43798 allowed unauthenticated attackers to read arbitrary files from Grafana servers, including configuration files containing database credentials, SMTP passwords, and API keys. The exploit was a single HTTP request. The vulnerability affected Grafana versions 8.0.0-beta1 through 8.3.0, and exploitation was already underway before the advisory was published.

What Grafana Is and Why It Matters

Grafana is the de facto standard for infrastructure monitoring dashboards. It's deployed in virtually every modern DevOps environment, connecting to data sources like Prometheus, InfluxDB, Elasticsearch, PostgreSQL, and dozens of others. Organizations use Grafana to visualize everything from application performance to business metrics.

Because Grafana connects to so many data sources, its configuration file (grafana.ini or environment variables) typically contains credentials for databases, LDAP servers, OAuth providers, and cloud services. Compromising Grafana's configuration doesn't just compromise the dashboard — it compromises every data source it connects to.

The Vulnerability

CVE-2021-43798 was a path traversal vulnerability in Grafana's plugin handling. Grafana serves plugin files through a URL path pattern like /public/plugins/<plugin-id>/<file-path>. The vulnerability allowed an attacker to inject directory traversal sequences into the file path parameter, escaping the plugin directory and reading arbitrary files from the server.

The exploit was trivial:

GET /public/plugins/alertlist/../../../../../../../../../etc/passwd HTTP/1.1

Any installed plugin could be used as the entry point — alertlist, graph, table, text, heatmap, and others that ship with Grafana by default. The only requirement was knowing the name of an installed plugin, and the defaults are well-known.

The vulnerability existed because the file-serving handler didn't properly sanitize the path after resolving the plugin ID. It checked that the plugin existed but then appended the remaining path without normalization, allowing ../ sequences to traverse outside the intended directory.

The Disclosure Timeline Problem

This vulnerability had an unusual and problematic disclosure timeline:

• December 2, 2021: Exploit details began circulating on Chinese security forums and social media
• December 3, 2021: Multiple security researchers independently confirmed the vulnerability and published PoC exploits on Twitter
• December 3, 2021: Grafana Labs received reports and began working on a fix
• December 7, 2021: Grafana released patched versions (8.3.1, 8.2.7, 8.1.8, 8.0.7)

This meant there were roughly four days between public exploitation and the availability of a patch. During that window, every Grafana 8.x installation exposed to the internet was a target with no defense beyond network-level access controls.

What Attackers Targeted

The first thing most attackers went after was Grafana's configuration file:

GET /public/plugins/alertlist/../../../../../../../../../etc/grafana/grafana.ini

This file typically contains:

• Database credentials: The connection string for Grafana's backend database (often PostgreSQL or MySQL), including username and password
• Secret key: Used for signing cookies and encrypting stored credentials
• SMTP credentials: Email server authentication for alert notifications
• OAuth/LDAP configuration: Including client secrets and bind passwords
• API keys: For integrated services

Beyond the configuration file, attackers also targeted:

• /etc/passwd and /etc/shadow (on systems with weak permissions)
• SSH private keys (/root/.ssh/id_rsa, /home/*/.ssh/id_rsa)
• Cloud credential files (~/.aws/credentials, ~/.azure/)
• Docker and Kubernetes configuration files
• Other application configuration files on shared servers

The Scale of Exposure

Grafana's popularity meant the exposure was enormous. Shodan and Censys searches revealed tens of thousands of Grafana instances directly accessible from the internet. Many organizations expose Grafana publicly for operational dashboards, status pages, or because remote teams need access.

Automated scanning for CVE-2021-43798 was detected within hours of the initial public disclosure. Multiple threat intelligence providers reported widespread exploitation attempts across their honeypot networks.

A Broader Pattern in DevOps Tools

CVE-2021-43798 fits a pattern of critical vulnerabilities in DevOps infrastructure tools:

• Jenkins: Numerous RCE vulnerabilities over the years
• GitLab: Multiple critical authentication and authorization bugs
• Elasticsearch/Kibana: Repeated injection and access control vulnerabilities
• Prometheus: Configuration exposure through unauthenticated endpoints

DevOps tools are often deployed with minimal security hardening. They're treated as internal tools, but they frequently end up internet-facing. They're configured by developers who prioritize functionality over security. And they connect to critical infrastructure with privileged credentials.

This creates a pattern where compromising a single DevOps tool provides attackers with credentials to move laterally across the entire infrastructure.

Mitigation and Remediation

Immediate Steps

1. Patch Grafana to the latest version in the affected series
2. Rotate all credentials stored in Grafana's configuration, including database passwords, SMTP credentials, OAuth secrets, and API keys
3. Review access logs for path traversal patterns in plugin file requests
4. Restrict network access to Grafana — it should not be directly accessible from the internet without a reverse proxy and authentication layer

Long-Term Improvements

• Don't store credentials in configuration files. Use environment variables, secrets management tools (HashiCorp Vault, AWS Secrets Manager), or Grafana's built-in credential provisioning with external secrets.
• Run Grafana with minimal file system permissions. The Grafana process should only have read access to its own configuration and data directories.
• Deploy Grafana behind authentication. Even if Grafana has its own authentication, put it behind an additional authentication proxy (OAuth2 Proxy, Pomerium, etc.) to add defense in depth.
• Monitor for anomalous file access. File integrity monitoring and auditd rules can detect when the Grafana process reads files outside its expected directories.

How Safeguard.sh Helps

Safeguard.sh addresses the unique security challenges of DevOps infrastructure tools like Grafana:

• DevOps Tool Inventory: Safeguard.sh catalogs every tool in your DevOps toolchain, tracking versions and identifying components with known vulnerabilities.
• Rapid Vulnerability Alerts: When a zero-day like CVE-2021-43798 drops, Safeguard.sh immediately identifies affected instances in your environment, cutting response time from days to minutes.
• Credential Exposure Assessment: Safeguard.sh evaluates your software configurations for stored credentials and secrets, helping you identify and remediate credential exposure before attackers exploit it.
• Continuous Monitoring: Safeguard.sh provides ongoing visibility into your infrastructure's security posture, ensuring that newly deployed or updated Grafana instances don't introduce unpatched versions into your environment.

Grafana CVE-2021-43798 was a reminder that the tools we use to monitor our infrastructure can become the tools attackers use to compromise it. Safeguard.sh keeps watch on the watchers.