Grafana CVE-2026-100105

Exploitation requires an authenticated Grafana account that has been granted permission to edit contact points but has been denied permission to edit their protected fields (PR:L) - i.e. a specifically delegated, constrained alerting-management role. The concrete trigger named in the description is switching a contact-point integration to a legacy schema version, which causes the protected-field authorization check to be applied incorrectly; this is the exact condition and it does not require user interaction or a non-default feature toggle beyond having legacy schema handling available. Limiting factors: the attacker must already possess the contact-point editing role (no anonymous or pre-auth path), the target deployment must run an affected version (OSS 12.4.x-13.2.x or Enterprise 12.4.x-13.2.x within the listed ranges), and value is realized only where contact points store sensitive credentials or route security-relevant alerts.

This is a credible operational priority but not an emergency: the vuln.today decision label is 'this_week', and the signals are internally consistent with a moderate-to-serious authorization flaw rather than a mass-exploitation threat. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, 7.7) indicates a network-reachable, low-complexity attack that requires an authenticated low-privileged account (PR:L) - specifically a user already granted permission to edit contact points - and crosses a security authority (S:C) to reach protected data it should not control. There is no CISA KEV listing and no EPSS score was provided, so there is no evidence of active or widespread exploitation; likewise no public exploit or PoC reference appears in the input, so this is a privilege/authorization weakness exploitable by insiders or any attacker who already holds a constrained Grafana editing role, not a pre-auth internet mass-exploitation bug. The CWE-863 (incorrect authorization) classification aligns well with the description. One tension worth verifying: the CVSS scores integrity as I:N even though the described attack modifies protected settings such as a contact point's destination URL, which is a modification of trusted configuration - so the real-world impact arguably includes an integrity element beyond the C:H confidentiality rating.

A Grafana user who has been delegated permission to edit contact points - but who is explicitly not allowed to edit the protected fields of those contact points - switches an existing integration to a legacy schema version. Because the legacy-schema code path applies authorization incorrectly, the user can then alter protected settings such as the notification destination URL, exposing stored credentials and silently redirecting alert notifications to an attacker-controlled endpoint. No public exploit code is identified in the provided data, and the attack requires an existing low-privileged authenticated Grafana account.