Grafana — CVE-2024-9264

TL;DR

CVE-2024-9264 is a critical vulnerability in Grafana 11.x where the SQL Expressions feature forwards attacker-controlled SQL to a backend (DuckDB), enabling local file reads (LFI) and, in some setups, remote code execution (RCE). In many configurations the flaw can be triggered by accounts with Viewer-level access or higher. Grafana released security patches in October 2024 — upgrade to the patched 11.x builds or later immediately.

Short story

Imagine a public library where a reader can ask the front desk for a book. The desk clerk fetches only from the public shelves — except there’s a new, eager helper (an automated archive clerk) who will fetch any file the desk asks for. One careless instruction to that helper, and a curious reader ends up handed private files from the staff-only archive. That’s what happened with Grafana’s SQL Expressions: a feature meant for harmless post-processing could be used to ask the backend to read or execute things it shouldn’t.

What happened and why you should care

Grafana added the SQL Expressions feature to let dashboards do lightweight data transformations on the server. That feature relies on an SQL engine (DuckDB) on the Grafana host to run queries. Due to insufficient sanitization and the presence of DuckDB helpers that can access files or load extensions, an attacker who can submit an expression can trick the engine into reading arbitrary files (like /etc/passwd or /opt/secret.txt) — and in some setups, can even get code execution by loading extensions or abusing functions that call the OS. The vulnerability affects Grafana 11.0.x, 11.1.x and 11.2.x and is tracked as CVE-2024-9264.

Why care? Many organizations expose Grafana to internal teams or the internet. If low-privilege users (or attackers who gain a Viewer account) can run expressions, they can exfiltrate secrets, read config files, and potentially pivot to further compromise. Real-world proof-of-concepts were published soon after disclosure, demonstrating file reads and RCE paths.

Technical deep dive

Components involved

• Grafana SQL Expressions: a server-side post-processing datasource that evaluates SQL-like expressions.

• DuckDB: an embeddable SQL engine Grafana can call to execute those expressions. DuckDB exposes helper functions (for example, functions that read text/files or can load extensions).

• Unsafe path: user-supplied input flowed into DuckDB without adequate sandboxing or sanitization, enabling read_text()-style file reads and extension loading.

Typical exploitation flow

1. Authenticate (some setups require an account; many PoCs assume Viewer or higher).

2. Send a POST to Grafana’s expression API (/api/ds/query?ds_type=__expr__&expression=true) with a JSON body where expression contains a DuckDB call such as SELECT * FROM read_text('/opt/flag.txt').

3. Grafana forwards the query to DuckDB; DuckDB executes read_text() and returns the file contents inside Grafana’s JSON response. Parsing the response yields the secret. In configurations where extensions like shellfs are available or DuckDB is run with broader privileges, an attacker can escalate to arbitrary command execution.

Conditions that make the exploit possible

• Grafana 11.0–11.2 with SQL Expressions enabled (default in some builds).

• DuckDB or vulnerable helper functions accessible to Grafana (in PATH or installed).

• An account that can call the Expressions API — PoCs show Viewer-level accounts may be sufficient.

Fix & mitigation

Immediate (do now)

1. Upgrade Grafana to a patched release. Grafana published security patch releases for 11.0.x, 11.1.x and 11.2.x on Oct 17, 2024 — upgrade to the recommended +security builds or later.

2. If you can’t upgrade immediately, disable or restrict Expressions: remove or disable the Expression datasource, or restrict its usage to trusted admin roles only.

3. Remove DuckDB from PATH on systems that don’t need it for Grafana, and avoid installing risky DuckDB extensions (e.g., community extensions that allow shell access).

4. Contain Grafana’s runtime: run Grafana with least privilege (dedicated non-root user, minimal FS permissions, read-only root if possible, container seccomp/AppArmor).

Detect & monitor

• Log and alert on calls to /api/ds/query (Expression API), especially queries containing suspicious functions like read_text, ATTACH, load_extension, or long multi-line SQL.

• Search historic logs for read_text or unusual /api/ds/query payloads to detect past exploitation attempts.

• Monitor outbound connections and unusual processes launched by Grafana host.

Longer-term

• Harden host OS with file ACLs so Grafana’s process user cannot read sensitive files.

• Consider network segmentation: avoid exposing Grafana dashboards to untrusted networks if not necessary.

Responsible disclosure & precautions

• If you find this behavior on a production Grafana, do not run exploit PoCs on those systems. Instead, take the instance offline or restrict access and patch immediately. If you are a defender, gather logs and follow your incident response process.

• If you’re a researcher, disclose findings responsibly to vendor (Grafana Labs) per their policy before posting exploit details publicly. Grafana already released advisories and patches in Oct 2024.

CVE-2024-9264 is a reminder that powerful features (server-side expression engines, embedded SQL runtimes) increase attack surface. The fix is straightforward: patch, restrict, and harden. Treat server-side evaluation capabilities as untrusted input sinks and apply the same distrust you’d apply to user input on any public-facing service.

References

• Grafana Labs — Security release & advisory for CVE-2024-9264.

• NVD / CVE entry for CVE-2024-9264.

• Public PoC repositories demonstrating file-read and RCE techniques.

• Technical writeups and vendor analyses (Wiz / Indusface / Tenable coverage summaries).