Grafana OSS EUVD-2026-30137

Exploitation requires an authenticated Grafana account with the Editor role assigned - confirmed by the CVSS vector PR:L (low privilege required). The attacker does not need read or create permissions on the target annotation, which is the core of the flaw, but must have valid credentials and network access to the Grafana instance. Exploitation is further limited by the requirement to know or enumerate a valid annotation ID for the target resource; the SSVC Automatable: no rating reflects this enumeration hurdle. Exploitation is not possible by unauthenticated users, Viewer-role accounts, or users with no access to the Grafana instance. The vulnerability affects only the annotation deletion function - all other role-based access controls remain effective.

The CVSS base score of 4.3 (Medium) reflects a network-exploitable, low-complexity, low-privilege-required vector with partial integrity impact and no confidentiality or availability impact - an appropriate calibration. The EPSS score of 0.03% at the 8th percentile signals very low probability of observed exploitation in the near term, consistent with the SSVC assessment of Exploitation: none and Technical Impact: partial. The SSVC Automatable: no designation further reduces concern, as exploitation requires an authenticated session with Editor-level credentials rather than unauthenticated mass scanning. Grafana's own tagging as 'Authentication Bypass' is technically a stretch - the authentication layer functions correctly; the bypass is at the authorization layer (missing permission check on delete). No KEV listing and no public POC exist. The realistic risk is primarily an insider or compromised-editor scenario where annotation data integrity is damaged, not a remotely exploitable critical path. Defenders should treat this as a standard patch cycle item rather than an emergency.

An authenticated Grafana user holding the Editor role enumerates annotation IDs by probing the Grafana API or observing network traffic within their accessible dashboards, then issues DELETE requests against annotation IDs belonging to restricted dashboards or data sources to which they have no read access. The backend processes the deletion without verifying read permissions, permanently removing the targeted annotations. No public exploit code exists, so this scenario currently requires manual crafting of API requests.