Grafana data source credential theft

Most services on this site are worth compromising for what they hold. Grafana is worth compromising for what it can reach.

A monitoring server is a deliberate concentration of access: to draw a graph of your database it needs a database credential, and it needs one for every system on every dashboard. Whoever gets Grafana gets that set — not a foothold to escalate from, but a working credential for each backend, already collected and labelled.

The chain

Three steps, none of them requiring a novel attack:

1. Reach the file or the database. Grafana keeps its state in grafana.db (SQLite by default), including a data_source table whose secure_json_data column holds encrypted credentials.

2. Decrypt it with a key you already have. The secret_key default — SW2YcwTIb9zpOOhoPsMm — is the same in every installation and sits in the public source tree. Open-source tools take a grafana.db and that key and print the credentials. If nobody changed it, the encryption is decoration.

3. Use them. The credentials work, from anywhere that can reach the backends. Nothing about them indicates they came from Grafana.

This is not hypothetical

CVE-2021-43798 supplied step one for a large number of real installations. An unauthenticated path traversal in Grafana 8.x — a ..%2f sequence against /public/plugins/<plugin-id>/ — let anyone read arbitrary files as the Grafana process, with no login at all. /etc/grafana/grafana.ini and /var/lib/grafana/grafana.db were both readable.

It affected 8.0.0-beta1 through 8.3.0, was fixed in 8.0.7, 8.1.8, 8.2.7 and 8.3.1, was exploited in the wild, and sits in CISA’s Known Exploited Vulnerabilities catalogue.

The pattern to take from it is not “patch Grafana 8”, which is long done. It is that a read-only file disclosure bug in a monitoring server is a full credential compromise of everything it monitors, because the default key turns file access into credential access at no cost.

More recently, CVE-2026-27876 (CVSS 9.1) chained SQL Expressions with a Grafana Enterprise plugin to reach remote code execution — affecting only instances with the sqlExpressions feature toggle enabled, fixed in 11.6.14, 12.1.10, 12.2.8, 12.3.6 and 12.4.2, with v13 never affected. Different mechanism, same destination.

What the credentials are worth

This is where it stops being a monitoring incident:

• A database data source using the application’s own account — read the application’s data directly, and write it if the account can.
• A cloud credential scoped beyond the metrics API — the incident continues into the cloud account, the same way a container escape does.
• An Elasticsearch superuser rather than a scoped API key — every index. See API keys and least privilege.
• A Prometheus with its admin API enabled — delete series, and with it the evidence.

The blast radius is defined entirely by what those credentials were permitted to do, which is why that control matters more here than its medium rating suggests in isolation.

The other direction: Grafana as an SSRF engine

Worth knowing because it needs no vulnerability at all. Anyone who can add or edit a data source — Admin within an organisation — can point it at any address Grafana can reach and have Grafana make the request for them. Internal services, admin ports, and cloud metadata at 169.254.169.254 are all fair game from Grafana’s network position.

That is documented behaviour, not a bug. The guards are keeping the Admin role list short and populating data_source_proxy_whitelist, which is empty by default.

What actually reduces it

In order of how much they change the outcome:

1. Rotate the secret key. This is the step that breaks the chain — a stolen database becomes an encrypted blob rather than a credential list. Read the safety notes; it is not a one-line edit.
2. Scope every data source credential. Decides what the theft is worth. Read-only, per-source accounts turn a breach into a disclosure.
3. Patch, and know your feature toggles. Both CVEs above were fixed by upgrading and by nothing else.
4. Protect the database and its backups as the credential store it is — the backup is as sensitive as the server.
5. Change the admin password and put it behind TLS, which close the ordinary front-door routes to step one.

Verify it worked

Size the exposure first — how many credentials are in play:

sudo sqlite3 /var/lib/grafana/grafana.db \
  'SELECT type, name FROM data_source WHERE secure_json_data IS NOT NULL AND secure_json_data != "";'

Then the decisive question, whether the key is still the shipped one:

grep -E '^\s*secret_key' /etc/grafana/grafana.ini
docker inspect grafana --format '{{range .Config.Env}}{{println .}}{{end}}' | grep GF_SECURITY_SECRET_KEY

No output from either means the default is in use, and everything the first query listed is decryptable by anyone who obtains the file.

Find copies of the database outside the Grafana directory — backups are the realistic path:

sudo find / -name 'grafana.db*' -not -path '/var/lib/grafana/*' 2>/dev/null
ls -l /var/lib/grafana/grafana.db

Confirm the version is not in the historically exploited range, and check the feature toggle from the newer CVE:

grafana server -v
grep -A10 '^\[feature_toggles\]' /etc/grafana/grafana.ini

Test the traversal only against an instance you are responsible for — a 200 with file contents on a current version would be a finding worth escalating:

curl -sS --path-as-is \
  'https://grafana.example.com/public/plugins/alertlist/../../../../../../../../etc/passwd' | head -3

Expect a 404 or an error page.

Before you apply this

If you conclude this has happened, the order matters and the instinct is wrong.

Rotating the Grafana secret key first does not help. It does not un-decrypt what was already taken. The credentials in that database are compromised the moment the file left, and they keep working until they are changed at the backends.

So:

1. Rotate the backend credentials — the database passwords, the API keys, the cloud roles. That is what actually revokes the access.
2. Then rotate the Grafana secret key, following the migration steps on its own page, so the next copy is worth less.
3. Then re-enter the new credentials into the data sources.

Doing this in the wrong order produces an outage without closing anything.

Check what the credentials did while they were valid — backend logs, not Grafana’s:

sudo journalctl -u grafana-server --since '30 days ago' | grep -iE 'datasource|proxy' | tail -100

Grafana’s own logs will not show an attacker using a stolen credential directly against a database — that use bypasses Grafana entirely, which is the point. Audit logging is not an OSS feature, so the record you want may not exist at all; the backends’ logs are the ones to read. That gap is the same one MongoDB and Elasticsearch have, and it is worth knowing before an incident rather than during one.

Related

• Rotate the Grafana secret key — the single change that breaks this chain.
• Restrict data source permissions — what decides the blast radius.