CVE-2026-13719 in Grafana
Summary
by MITRE • 09/30/2026
An authenticated user can list alert rules stored in folders they are not allowed to read through the alert rules API list endpoint. When the set of folders the user may read was empty, the folder restriction was dropped and every alert rule in the organization was returned. From Grafana 13.1.0, any user can trigger this with a folder filter. The exposed data is rule configuration; data source credentials are not exposed.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability described constitutes an authorization bypass within the Grafana application's alerting subsystem, specifically affecting the API endpoint responsible for listing alert rules organized by folders. This flaw allows authenticated users to access sensitive organizational security configurations beyond their assigned permissions. The core technical issue stems from a logic error in how the backend service evaluates folder-level access controls when processing list requests. Under normal circumstances, Grafana enforces strict role-based access control (RBAC) policies that restrict visibility of alert rules to only those folders explicitly granted to the requesting user identity. However, the implementation fails to correctly handle edge cases where the calculated set of accessible folders is empty or null during request validation.
In versions prior to 13.1.0, this vulnerability was triggered when a user with no explicit folder read permissions submitted a list request without specifying any specific folder filters. The backend logic incorrectly interpreted an empty access control set as a signal to bypass the restriction entirely, resulting in the return of all alert rules across the entire organization rather than an empty result or an authorization denied error. This behavior effectively nullified the intended isolation between different teams or projects within a multi-tenant Grafana instance. From version 13.1.0 onwards, the attack surface expanded significantly because any authenticated user can now trigger this bypass by explicitly providing a folder filter parameter in their API request. The presence of this filter appears to alter the code path such that the empty set check is circumvented or evaluated incorrectly, allowing unauthorized enumeration of alert rules regardless of the user's actual permissions on those specific folders.
The operational impact of this vulnerability centers on information disclosure and potential lateral movement within an organization's infrastructure monitoring ecosystem. While the exposed data consists primarily of rule configuration details rather than raw credentials, it still poses significant security risks. Alert rule configurations often contain critical intelligence regarding which systems are being monitored, what thresholds define anomalies or attacks, and how alerts are routed to notification channels such as Slack, PagerDuty, or email services. Attackers can use this information to map the organization's monitoring landscape, identifying high-value assets that trigger specific alerts. Furthermore, knowledge of alerting logic allows adversaries to tailor their attack techniques to avoid detection by understanding exactly which metrics and log patterns are being watched. This aligns with the ATT&CK technique T1592, Gather Victim Host Information, as it enables reconnaissance against the monitoring infrastructure itself.
From a classification perspective, this vulnerability is best categorized under CWE-862, Missing Authorization, as the application fails to enforce proper access controls on a protected resource. It also relates closely to CWE-200, Exposure of Sensitive Information to an Unauthorized Actor, due to the unauthorized retrieval of configuration data that aids in further exploitation or evasion. The flaw represents a classic example of improper input validation and state management within API handlers, where edge cases involving empty collections are not rigorously tested against security policies.
Mitigation for this vulnerability requires immediate patching to the latest stable version of Grafana where these logic errors have been corrected by the development team. Organizations should verify that their instances are updated past 13.0.x and ideally running a patched release from the 13.1 series or later, as indicated in the advisory context. In addition to software updates, administrators should review their RBAC policies to ensure they follow the principle of least privilege, minimizing the number of users with broad access rights even if such vulnerabilities exist. Implementing network-level controls such as Web Application Firewalls can also help detect anomalous API usage patterns that might indicate exploitation attempts, although this is a compensatory control rather than a fix for the underlying code defect. Regular auditing of user permissions and monitoring for unusual spikes in alert rule listing requests are recommended operational practices to maintain visibility into potential abuse of these endpoints.