Grafana vulnerabilities

In Grafana, a user with the Editor role can set file-provisioning metadata (grafana.app/managedBy, grafana.app/managerId and grafana.app/sourcePath annotations) when creating a dashboard through the dashboard API, because these fields were stored without an authorization check. The dashboard then appears file-provisioned, and administrators can no longer update or delete it through Grafana. The impact is limited to the same organization and no data is exposed.

In Grafana, 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.

An authenticated user with edit permission on one folder can move a library panel into another folder where they only have view permission, through the library elements API or the equivalent App Platform resource. The update path did not check library panel create permission on the destination folder (incorrect authorization). No data from the destination folder is disclosed, and existing content there cannot be changed.

Pausing a shared (public) dashboard did not revoke its access token for the endpoints that serve frontend bootstrap data. Anyone holding the link to a paused shared dashboard could still retrieve, without authenticating, the configuration of the dashboard's data sources, including stored credentials for data sources using browser access (missing authorization). Deleting the shared dashboard does revoke the token.

The Snowflake datasource vulnerability allows GET/PUT commands, enabling any user with query access to read/write files between the local Grafana server and the connected Snowflake host.

A chained attack via SQL Expressions and a Grafana Enterprise plugin can lead to remote arbitrary code execution (RCE). The vulnerability requires the sqlExpressions feature toggle to be enabled and affects specific Grafana OSS versions.

In Grafana versions 12.x where SCIM provisioning is enabled and configured, a vulnerability in user identity handling allows a malicious or compromised SCIM client to provision a user with a numeric externalId, which could allow overriding internal user IDs and lead to impersonation or privilege escalation.

Grafana validates Azure AD accounts based on the email claim. The email field in Azure AD profiles is not unique and can be easily modified, leading to account takeover and authentication bypass when Azure AD OAuth is configured with a multi-tenant app.

Grafana OSS and Grafana Enterprise did not safely resolve symbolic links when extracting plugin archives. A crafted archive can chain relative symlinks to escape the plugin installation directory, writing arbitrary files and an executable backend binary outside it, which then runs with Grafana server privileges.

An authenticated user with permission to query a SQL data source can bypass the fix for CVE-2026-33375 by injecting the timeGroup macro through a WHERE clause, which Grafana's regex-based macro parsing does not reject. Evaluating the injected macro causes uncontrolled memory consumption that can terminate the Grafana server process, resulting in a denial of service. The Microsoft SQL Server, PostgreSQL, and MySQL data sources are affected.

A vulnerability in Grafana (only self-managed instances with Auth Proxy authentication and identity caching enabled) where the Auth Proxy cache key concatenates username and forwarded identity attributes without a delimiter, allowing distinct identities to collide. An authenticated user can spoof a higher-privileged user.

A user with organization administrator permissions can delete dashboard snapshots belonging to other organizations on the same Grafana instance, and can recover a snapshot's secret delete key using only its public share key (broken access control).

An authenticated attacker with Editor access or alert.instances.external:write can submit an external Alertmanager alert containing a controlled generatorURL. Grafana renders alert.generatorURL directly as the Alert Details See source LinkButton href without URL-scheme sanitization or a safe-protocol allowlist. The click interceptor's :// heuristic can be bypassed by placing :// inside a JavaScript comment. When a user with read access clicks See source, the browser executes attacker-controlled JavaScript in the Grafana origin with the clicking user's permissions.

An authenticated user with permission to create or edit alert rules can bypass datasource query authorization by marking an alert rule query as a server-side expression while referencing a real datasource UID (incorrect authorization). This can expose data accessible through Grafana's configured datasource credentials to users who lack permission to query that datasource.

This vulnerability only affects Grafana stacks with multiple organizations. A user who is an Org Admin of one organization can call GET /api/access-control/users/permissions/search?actionPrefix=dashboards: and receive permission data from other organizations. Disclosed data is limited to dashboard/folder UIDs and permission mappings, not content or personal data.

The alertmanager templates test endpoint (/api/alertmanager/grafana/config/api/v1/templates/test) in Grafana can execute templates with no memory limits. Mass-executing templates in a short period causes OOM and crashes the Grafana service. The endpoint requires very low privileges and is exploitable with anonymous access enabled.

An unauthenticated attacker can repeatedly call Grafana's OAuth login route with unique values, causing unbounded memory growth that can eventually exhaust memory and crash the Grafana instance (denial of service).

A user with Editor permissions can craft a dashboard whose table (TableNG) panel contains a malicious field name that executes as a script in the browser of any user who views the dashboard (stored cross-site scripting).

Several Grafana API endpoints, some of them unauthenticated, do not limit the size of the request body before processing it. An attacker can send very large payloads that force excessive memory allocation, potentially exhausting memory and causing a denial of service.

The public dashboard deletion endpoint does not enforce organization isolation, allowing an Org Admin in one organization to delete public dashboards belonging to a different organization by supplying the target dashboard's identifiers.

A vulnerability in the Geomap panel in Grafana allows a user with Editor permissions to inject a malicious script into the attribution field of an XYZ tile layer via a template variable. The script executes in the browser of any user viewing the affected dashboard (stored cross-site scripting).

A vulnerability in SQL Expressions allows an authenticated attacker to read arbitrary files from the Grafana server's filesystem. Only instances with the sqlExpressions feature toggle enabled are vulnerable.

A cross-tenant isolation vulnerability was found in Grafana's Correlations feature affecting legacy correlation records. Due to a backward compatibility condition allowing org_id = 0 records to be returned across organizations, a user with datasource management privileges could read and permanently delete legacy correlation data belonging to another organization. This issue affects correlations created prior to Grafana 10.2 and is fixed in >=11.6.11, >=12.0.9, >=12.1.6, and >=12.2.4.

In Grafana's alerting system, users with edit permissions for contact points (e.g., 'alert.notifications:write' or 'alert.notifications.receivers:test' granted via the 'Contact Point Writer' role) can modify contact points created by others and change the endpoint URL to a controlled server. By invoking the test functionality, they can capture and extract redacted secure settings, such as authentication credentials for third-party services (e.g., Slack tokens), leading to unauthorized access and potential compromise of external integrations.

A testdata data-source can be used to trigger out-of-memory crashes in Grafana.

A resample query can lead to out-of-memory crashes in Grafana.

A vulnerability in public dashboards and direct data-sources exposes passwords of all direct data-sources, even if not used in dashboards. Passwords of proxied data-sources are not exposed.

A TOCTOU vulnerability allows recently deleted-then-recreated data sources to be re-deleted without proper permissions.

The dashboard permissions API does not verify the target dashboard scope and only checks the dashboards.permissions:* action. As a result, a user with permission management rights on one dashboard can read and modify permissions on other dashboards, leading to an organization-internal privilege escalation.

The vulnerability in Grafana causes every uncached /avatar/:hash request to spawn a goroutine that refreshes the Gravatar image. If the refresh sits in the worker queue longer than three seconds, the handler times out and stops listening for the result, so the goroutine blocks forever trying to send on an unbuffered channel. Sustained traffic with random hashes keeps tripping this timeout, causing goroutine count to grow linearly, eventually exhausting memory and crashing Grafana on some systems.