Grafana CVE-2026-33374

Requires an authenticated Grafana account (PR:L) with access to the Prometheus rule conversion API endpoints; no user interaction and no special non-default feature toggle is indicated - the missing request-body size limit applies to these endpoints as shipped. Exploitation is limited by the need for valid credentials, so deployments that restrict account provisioning or network-expose the API only to trusted users face substantially lower risk. Impact is limited to availability (server crash via OOM); there is no path to data access or code execution from this flaw.

This is a moderate-severity availability-only issue, correctly rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). The network vector and low attack complexity make it easy to trigger, but PR:L means a valid authenticated account is required, which meaningfully narrows the attacker population versus an unauthenticated DoS. Impact is confined to availability (C:N/I:N) - no data disclosure or integrity loss - so the realistic worst case is a server crash/OOM rather than compromise. No EPSS score, CISA KEV listing, or public POC was provided in the intelligence, so there is no signal of active or widespread exploitation; this reads as a genuine but lower-priority DoS hardening fix rather than an emergency. The authenticated requirement is the dominant mitigating factor: in multi-tenant or loosely-provisioned Grafana deployments where low-privilege users exist, risk is higher; in tightly controlled single-team instances it is low. SSVC framing: exploitation none-observed, technical impact partial (availability only), automatable likely yes given a simple oversized HTTP body.

An authenticated low-privilege Grafana user sends a crafted HTTP request to a Prometheus rule conversion API endpoint with an extremely large request body. Because the endpoint does not cap body size, the server attempts an unbounded memory allocation to parse it, driving the process into an out-of-memory condition and crashing Grafana, denying service to all other users. No public exploit code was identified at time of analysis, but the technique is trivial to reproduce once a valid account is held.