← Back to Feed CACHED · 2026-09-22 02:00:56 · CACHE_KEY tenable:215000
tenable:215000 · CWE-200 · Disclosed 2025-01-31

Grafana Labs 10.4.x < 10.4.15 / 11.0.x < 11.0.11 / 11.1.x < 11...

ASSESSED — NOISGATE
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

Someone left the VictorOps API key taped to the break-room fridge, but only employees with badges can see it

CVE-2024-11741 is an authorization bypass in Grafana's Alerting module, specifically in the VictorOps (now Splunk On-Call) contact-point integration. Users authenticated with only Viewer permissions can read configuration data for the VictorOps integration — including the API key, routing key, and webhook URL — that should be restricted to Editor and Admin roles. The flaw affects a wide span of Grafana releases: 10.4.x < 10.4.15, 11.0.x < 11.0.11, 11.1.x < 11.1.11, 11.2.x < 11.2.6, 11.3.x < 11.3.3, and 11.4.x < 11.4.1. It is fixed in those respective patch versions and in 11.5.0+.

Grafana Labs rated this MEDIUM (4.3), and for once, even that feels generous. The CVSS vector shows C:L/I:N/A:N — low confidentiality impact, zero integrity, zero availability. The leaked data is an API key for a *third-party incident-management webhook*, not Grafana datasource credentials, database connection strings, or dashboard data. The worst realistic outcome is an attacker injecting fake alerts into your Splunk On-Call pipeline — annoying, not catastrophic. Tenable's own VPR score of 1.2 (0.01 percentile) agrees this is noise. Add the fact that VictorOps is an increasingly niche integration — Splunk On-Call's future is uncertain under Cisco ownership — and the affected population shrinks further. The vendor severity overstates the real-world risk.

"Authenticated info leak of a niche alerting integration config. Backlog it."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Obtain Grafana Viewer credentials

The attacker must have a valid Grafana account with at least Viewer role permissions. This could be a legitimately provisioned low-privilege user, a contractor account, or credentials obtained via phishing or credential stuffing against the Grafana login page. Anonymous access does not suffice — the Grafana instance must be configured to allow user registration or the attacker must already have been onboarded.
Conditions required:
  • Valid Grafana account with Viewer role or higher
  • Network access to the Grafana instance (internal or external)
Where this breaks in practice:
  • Most enterprise Grafana deployments use SSO/SAML with MFA, making credential stuffing impractical
  • Viewer accounts are typically provisioned deliberately; random internet attackers don't have them
  • If Grafana is internal-only (majority of enterprise deployments), external attackers need prior network access
Detection/coverage: Failed login attempts visible in Grafana server logs and SIEM. Successful auth from unusual IPs detectable with standard log correlation.
STEP 02

Query the VictorOps contact point API

Once authenticated, the attacker calls the Grafana Alerting API endpoint for contact points (e.g., GET /api/v1/provisioning/contact-points or the equivalent UI route). Due to the missing authorization check, the response includes VictorOps integration configuration fields — the API key, routing key, and webhook URL — that should be masked or omitted for Viewer-role users.
Conditions required:
  • VictorOps (Splunk On-Call) integration must be configured as a contact point
  • Grafana Alerting must be enabled (default in Grafana 9+)
Where this breaks in practice:
  • Many Grafana deployments use PagerDuty, Opsgenie, or Grafana OnCall instead of VictorOps — the integration must actually exist
  • Organizations that never configured VictorOps are completely unaffected
  • The data returned is limited to VictorOps config — no datasource secrets, no dashboard data, no user credentials are leaked
Detection/coverage: API access to contact-point endpoints can be logged via Grafana audit logging (Enterprise) or reverse-proxy access logs. No CVE-specific scanner signature exists; Tenable plugin 215000 checks version only.
STEP 03

Abuse the leaked VictorOps API key

With the VictorOps API key and routing key, the attacker can call the VictorOps REST API directly to inject fake incidents into the target's on-call pipeline (create, acknowledge, or resolve incidents). This could cause alert fatigue, mask real incidents by flooding the queue, or cause unnecessary pager storms. The attacker cannot use these credentials to pivot into Grafana, its datasources, or any other infrastructure.
Conditions required:
  • The leaked API key must still be valid and not rotated
  • The attacker must have outbound internet access to reach the VictorOps/Splunk On-Call API
Where this breaks in practice:
  • Impact is limited to the incident-management plane — no lateral movement, no code execution, no data exfiltration from monitored systems
  • VictorOps API keys can be rotated instantly, killing the attack
  • Fake incidents are visible and quickly attributable; the blast radius is operational nuisance, not compromise
Detection/coverage: VictorOps/Splunk On-Call audit logs show API calls with source IP. Anomalous incident creation patterns (volume, timing, routing key) are detectable.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. Not listed in CISA KEV. No known campaigns or threat-actor usage. No mentions in threat intel feeds.
Proof-of-ConceptNone public. No PoC code on GitHub, Exploit-DB, or researcher blogs. Exploitation is trivial (single authenticated API call) but uninteresting — the payoff is a webhook API key.
EPSS Score0.00411 (0.411%) — 35th percentile. FIRST's model predicts negligible exploitation likelihood within 30 days.
CISA KEV StatusNot listed. No federal remediation deadline.
Tenable VPR1.2 / 10 (0.01 percentile) — Tenable's own risk-based score classifies this as the lowest tier of real-world risk.
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N — Network-accessible but requires authentication (PR:L). Confidentiality impact is Low. No integrity or availability impact.
Affected VersionsGrafana 10.4.0–10.4.14, 11.0.0–11.0.10, 11.1.0–11.1.10, 11.2.0–11.2.5, 11.3.0–11.3.2, 11.4.0
Fixed Versions10.4.15, 11.0.11, 11.1.11, 11.2.6, 11.3.3, 11.4.1, 11.5.0. Distro backports: RHEL 10 via RHSA-2025:7475.
Internet ExposureShodan indexes ~128,000+ Grafana instances globally. However, this CVE requires *authenticated* Viewer access, so internet exposure alone is insufficient — the attacker also needs credentials.
Disclosure Date2025-01-31 — disclosed by Grafana Labs via security advisory. Researcher not publicly credited.
04 · The Call

Final Verdict
DOWNGRADED to LOW (2.5/10)

Why this verdict

  • Authentication gate: Exploitation requires a valid Grafana Viewer account — this is not an unauthenticated attack. The attacker must already have been provisioned credentials or compromised them, which dramatically reduces the reachable population. Most enterprise Grafana instances use SSO+MFA, adding another layer.
  • Integration-specific scope: The bug only leaks VictorOps/Splunk On-Call configuration. If the target doesn't use VictorOps (and many don't — PagerDuty and Opsgenie dominate), there is literally nothing to leak. This narrows the vulnerable population to a fraction of Grafana deployments.
  • Confidentiality-only, Low impact: The CVSS vector itself says C:L/I:N/A:N. The leaked data is a third-party webhook API key — not Grafana datasource credentials, not database connection strings, not user tokens. The worst outcome is fake alert injection into an incident management tool.
  • No escalation path: The leaked VictorOps key cannot be used to escalate privileges in Grafana, pivot to monitored systems, access datasources, or move laterally. The attack chain dead-ends at operational nuisance.
  • Role multiplier: Grafana occupies the observability/SIEM visualization tier. In its highest-value role (security monitoring frontend), the blast radius of this CVE is still limited to a single third-party notification integration's API key. The chain does NOT produce domain takeover, fleet compromise, mass data egress, or supply-chain impact in any deployment role. No floor override applies.
  • Signal convergence: EPSS 0.411% (35th percentile), Tenable VPR 1.2 (0.01 percentile), no PoC, no KEV, no in-the-wild exploitation — every risk signal points to backlog-tier priority.

Why not higher?

Promoting to MEDIUM would require either a viable escalation path from the leaked data or evidence of active exploitation — neither exists. The leaked VictorOps API key is scoped to a third-party incident-management service and cannot be leveraged for privilege escalation, lateral movement, or data exfiltration from monitored infrastructure. The authentication requirement and integration-specific scope compound to make this a narrow, low-impact information disclosure.

Why not lower?

Dropping to IGNORE would be premature because the bug is real — it is an actual authorization bypass that leaks third-party API credentials. If VictorOps is configured, those keys should be rotated and the patch applied. The information disclosure could enable fake-alert injection, which, while a nuisance, is a tangible operational impact that warrants tracking.

05 · Compensating Control

What to do — in priority order.

  1. Rotate VictorOps/Splunk On-Call API keys immediately — If you have the VictorOps contact point configured in Grafana, rotate the API key and routing key in Splunk On-Call and update the Grafana contact point. This neutralizes any previously leaked credentials. No noisgate mitigation SLA applies for LOW-severity findings — treat this as backlog hygiene.
  2. Audit Grafana Viewer accounts — Review all accounts with Viewer role. Remove any stale, orphaned, or contractor accounts that no longer need access. This reduces the pool of users who could exploit the authorization bypass.
  3. Enable Grafana Enterprise audit logging — If running Grafana Enterprise, enable audit logging for API access to contact-point endpoints. This provides detection coverage for any unauthorized reads of integration configuration. In OSS Grafana, configure reverse-proxy access logging to capture API calls.
  4. Patch to fixed version within 365 days (noisgate remediation SLA) — Upgrade to Grafana 10.4.15, 11.0.11, 11.1.11, 11.2.6, 11.3.3, 11.4.1, or 11.5.0+ during your next regular patching cycle. For a LOW-severity finding, there is no noisgate mitigation SLA — go straight to the 365-day remediation window.
What doesn't work
  • WAF rules — the exploit is a standard authenticated API call to a legitimate Grafana endpoint. No WAF signature can distinguish a malicious read from a normal one without breaking Grafana functionality.
  • Network segmentation alone — restricting Grafana to internal networks helps reduce the attacker population but does not fix the authorization bypass. Internal Viewer users can still exploit it.
  • Disabling Grafana Alerting — this would break all alerting functionality, which is disproportionate to the risk of leaking a single integration's API key.
06 · Verification

Crowdsourced verification payload.

Run this script on any host that can reach the Grafana HTTP API. Pass the Grafana base URL as the first argument. Requires curl and jq. No special Grafana privileges needed — it checks the running version against the fixed version list. Example: bash check_cve_2024_11741.sh https://grafana.internal:3000

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2024_11741.sh — Version check for CVE-2024-11741
# Grafana Alerting VictorOps info disclosure
# Usage: bash check_cve_2024_11741.sh <GRAFANA_URL>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

GRAFANA_URL="${1:?Usage: $0 <GRAFANA_URL>}"
GRAFANA_URL="${GRAFANA_URL%/}"

# Fetch version from health endpoint (unauthenticated)
VERSION=$(curl -sf "${GRAFANA_URL}/api/health" 2>/dev/null | jq -r '.version // empty' 2>/dev/null)

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN — could not retrieve Grafana version from ${GRAFANA_URL}/api/health"
  exit 2
fi

echo "Detected Grafana version: $VERSION"

# Compare versions using sort -V
version_gte() {
  # Returns 0 if $1 >= $2
  [[ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" == "$2" ]]
}

# Extract major.minor
MAJOR_MINOR=$(echo "$VERSION" | grep -oP '^\d+\.\d+')

case "$MAJOR_MINOR" in
  10.4)
    if version_gte "$VERSION" "10.4.15"; then
      echo "PATCHED — $VERSION >= 10.4.15"
      exit 0
    else
      echo "VULNERABLE — $VERSION < 10.4.15 (CVE-2024-11741)"
      exit 1
    fi
    ;;
  11.0)
    if version_gte "$VERSION" "11.0.11"; then
      echo "PATCHED — $VERSION >= 11.0.11"
      exit 0
    else
      echo "VULNERABLE — $VERSION < 11.0.11 (CVE-2024-11741)"
      exit 1
    fi
    ;;
  11.1)
    if version_gte "$VERSION" "11.1.11"; then
      echo "PATCHED — $VERSION >= 11.1.11"
      exit 0
    else
      echo "VULNERABLE — $VERSION < 11.1.11 (CVE-2024-11741)"
      exit 1
    fi
    ;;
  11.2)
    if version_gte "$VERSION" "11.2.6"; then
      echo "PATCHED — $VERSION >= 11.2.6"
      exit 0
    else
      echo "VULNERABLE — $VERSION < 11.2.6 (CVE-2024-11741)"
      exit 1
    fi
    ;;
  11.3)
    if version_gte "$VERSION" "11.3.3"; then
      echo "PATCHED — $VERSION >= 11.3.3"
      exit 0
    else
      echo "VULNERABLE — $VERSION < 11.3.3 (CVE-2024-11741)"
      exit 1
    fi
    ;;
  11.4)
    if version_gte "$VERSION" "11.4.1"; then
      echo "PATCHED — $VERSION >= 11.4.1"
      exit 0
    else
      echo "VULNERABLE — $VERSION < 11.4.1 (CVE-2024-11741)"
      exit 1
    fi
    ;;
  11.5|11.[6-9]|1[2-9].*)
    echo "PATCHED — $VERSION is 11.5+ (fixed)"
    exit 0
    ;;
  *)
    if version_gte "$MAJOR_MINOR" "11.5"; then
      echo "PATCHED — $VERSION is beyond all affected branches"
      exit 0
    fi
    echo "UNKNOWN — $VERSION is outside the known affected range (10.4.x–11.4.x)"
    exit 2
    ;;
esac
07 · Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.