Grafana SQL Expressions routed to DuckDB let Viewer accounts read server files

Grafana's SQL Expressions feature, in releases from 11.0.0 through 11.1.6 and a narrower portion of the 11.2 line, handed panel expressions to a DuckDB client binary on the server. Because DuckDB is a full analytical database engine rather than a simple calculation helper, that design gave authenticated users a path to the host filesystem. The flaw is tracked as CVE-2024-9264, and according to a dev.to analysis of the issue, it let someone holding only the Viewer role — the lowest authenticated role in the product — achieve arbitrary file read, plus file write wherever the Grafana process's own permissions allowed it.

The scoring is contested: the post reports that Grafana's vendor advisory rates the issue 9.9 with NVD in agreement, while some third-party write-ups list 9.4. Either way, the required privilege is the detail that matters operationally — a read-only seat was enough.

How it worked

Two preconditions decided whether an instance was actually exposed. The expressions feature had to be enabled, and a duckdb binary had to be discoverable on the path the server searches. Neither condition is guaranteed, but both are common enough that the version number alone is a poor guide to whether a given deployment was vulnerable.

The mechanism also explains why tightening Grafana's own input handling could never be a complete fix. The expression string is not evaluated purely inside Grafana; it reaches an external process that implements a complete SQL dialect, including functions that read files, write files and load extensions. No amount of validation in the Grafana codebase changes what the receiving process can do once it accepts a string.

What file read exposes

File read is often dismissed as a low-impact outcome, but a monitoring server is a bad place to be dismissive. As the dev.to analysis lays out, the Grafana process and its reachable surroundings typically include the provisioning configuration, which holds datasource connection strings and frequently API tokens in plaintext; the database file behind the Grafana instance itself, containing users, API keys and dashboard definitions; secret mounts rendered into the environment, such as a Kubernetes token that authenticates to the cluster API; and cloud instance metadata where the workload has not been hardened against it.

Converting any of these into impact is usually a single step — a token becomes a session, a connection string becomes warehouse access, a service account becomes a pod. The post also notes that public proof-of-concept code appeared shortly after disclosure, so exploitation is no longer the expensive part of an attack.

A recurring pattern

Grafana's advisory index across late 2025 and 2026, as cited in the post, suggests this is a persistent problem class rather than a one-off: a remote code execution issue in sqlExpressions scored 9.1; an image renderer accepted input that led to arbitrary code execution, scored 9.9; an Alloy feature read an arbitrary local file and sent its contents as a bearer token, scored 7.7; and separate issues covered privilege assignment in the Enterprise build and server-side request forgery through MCP configuration. Grafana is built to be an integration hub, and an integration hub must make outbound calls and read configuration — precisely the capabilities that let modest bugs turn into credential disclosure.

Checking and hardening

The post's verification checklist is straightforward: confirm whether the expressions feature is enabled, since it was often switched on for one team and never revisited; check whether a duckdb binary sits on the process search path and whether the Grafana service account can write anywhere useful; audit Viewer-level accounts, because read-only users may have been able to read server files; rotate any provisioning or datasource tokens that were reachable while the instance ran unpatched; and look for outbound connections from the Grafana pod to unexpected destinations during the exposure window.

For hardening, the recommendation is to upgrade to a patched release and then assume the monitoring server holds credentials rather than just charts: move datasource secrets into a secret manager rendered at runtime with short lifetimes, strip file-write capability from the container filesystem, deny metadata access at the network level, and restrict egress from the Grafana namespace to only the datasources it queries. None of those controls depends on the next CVE being disclosed.

Why it matters

This is a story about composition: a feature that looked like simple math became a filesystem primitive because it delegated to a general-purpose query engine that happened to sit next to secrets. Operators should note the score disagreement but focus on the privilege level — the lowest authenticated role sufficed — and on the fact that monitoring infrastructure concentrates exactly the credentials an attacker wants next. The practical lesson from the dev.to analysis is that another file-read bug in an integration-heavy product is likely to arrive eventually, and the only open question is what it finds when it does.