Grafana OSS EUVD-2026-47869

The CVSS vector specifies PR:L (low-privilege authentication) as the baseline requirement; however, the description explicitly states exploitation is viable with anonymous access enabled, reducing authentication to PR:N in that deployment configuration. The specific vulnerable endpoint is /api/alertmanager/grafana/config/api/v1/templates/test, which must be network-reachable. Successful OOM triggering requires mass-execution of template requests in a short period - a single request is insufficient, meaning the attacker must sustain a rapid request burst. Exploitation is strictly limited to availability impact (service crash); there is no confidentiality or integrity component. Deployments with anonymous access disabled and low-privilege access restricted to trusted users face a meaningfully lower risk than internet-exposed instances with anonymous access enabled.

The official CVSS 3.1 score of 5.3 with vector AV:N/AC:H/PR:L reflects a network-accessible availability-only flaw requiring low privileges and rated high complexity, likely because triggering OOM demands sustained rapid requests rather than a single packet. However, the description explicitly calls out anonymous access as a viable exploitation path, which would lower the effective privilege requirement to none - meaning the PR:L baseline understates realistic risk in common Grafana deployments where anonymous access is enabled for embedded dashboards. The impact is strictly availability (C:N/I:N/A:H), resulting in a complete service crash rather than data exposure or tampering. No EPSS score, KEV listing, or proof-of-concept code was provided in the intelligence data, so exploitation probability cannot be quantified. Real-world prioritization should hinge on whether the affected instance has anonymous access enabled and is internet-exposed - those deployments face a materially lower exploitation bar than the CVSS PR:L suggests. Air-gapped or fully authenticated deployments are less immediately at risk but remain vulnerable to insider or compromised-credential scenarios.

An attacker with knowledge of a Grafana instance configured with anonymous access sends a high-volume burst of POST requests to /api/alertmanager/grafana/config/api/v1/templates/test, each containing a valid but memory-intensive template payload. Without memory limits enforced server-side, the Grafana process rapidly exhausts available heap, triggering an OOM condition that crashes the service and denies access to all dashboards, alerts, and data sources until manually restarted. No public exploit code has been identified at time of analysis, but the technique requires only standard HTTP tooling.