Grafana EUVD-2026-55221

Exploitation requires a valid Grafana user account with the Editor role or higher - unauthenticated external attackers cannot exploit this (PR:L per CVSS). The Grafana instance must be running version 13.2.0 or earlier with the ngalert unified alerting engine active (not the legacy alerting system). At least one contact point must be configured as 'protected' in the instance; deployments with no protected receivers have no vulnerable resource to target. The network DELETE request must reach the Grafana API endpoint, so network-level access to the Grafana service is required. Exploitation is limited by the Editor-role credential requirement and the existence of protected receivers - organizations that have not designated any receivers as protected are not exposed to the integrity impact even on unpatched versions.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) scores 6.5 and accurately reflects the threat profile: low-complexity network exploitation requiring only Editor-level authentication, with a High integrity impact from permanent deletion of protected notification channels. No CISA KEV listing and no confirmed public exploit code lower the immediate exploitation urgency - EPSS data was not provided so probability-of-exploitation cannot be quantified from available data. The real-world risk is elevated above the CVSS score suggests in environments where protected receivers guard compliance-mandated or on-call notification pipelines, where their silent removal could constitute insider sabotage or cover an attacker's tracks after an initial compromise. The incomplete-fix nature of this CVE is a compounding factor: organizations that patched CVE-2026-21724 and believed protected receivers were fully secured remain exposed through the DELETE path. No CVSS/description signal conflict is present - the local-vs-network vector is consistent.

A malicious insider or attacker who has compromised a Grafana Editor account authenticates to the Grafana HTTP API and enumerates protected contact point UIDs via a GET request to /api/v1/provisioning/contact-points. They then issue a DELETE request against each protected receiver UID; the missing authorization check on the DELETE handler allows the operation to succeed silently, removing the protected PagerDuty or on-call Slack integration. Subsequent alert firings produce no notifications, delaying incident detection. No public exploit code has been confirmed at time of analysis, but the attack requires only standard HTTP calls exploitable with minimal tooling.