Summary

An authenticated organization user who can create or edit alert rules in a folder can query a datasource for which they do not have datasources:query permission. The attacker sets the client-controlled query field queryType to expr while retaining the UID of a real datasource.

The alert-rule authorization path treats the query as a server-side expression and skips datasource permission enforcement, while the evaluator subsequently resolves and executes the query against the real datasource identified by datasourceUid.

Impact

This bypass can expose data accessible through Grafana's configured datasource credentials to a low-privileged user who is not authorized to query that datasource directly. Confidentiality impact is High.

Integrity impact is Low because some datasource backends and configured credentials may permit state-changing queries. No availability impact has been demonstrated.

Attack prerequisites

- Authenticated, low-privileged user in the same Grafana organization - Permission to create or edit alert rules in an accessible folder - No datasources:query permission for the targeted datasource - Knowledge or discovery of the targeted datasource UID - No user interaction required

Technical details / root cause

1. The attacker submits an alert-rule query with queryType: "expr" and the UID of a real datasource. 2. The datasource authorization helper skips permission enforcement when query.QueryType == "expr". 3. queryType is client-controlled and is not validated against the referenced datasource. 4. During evaluation, Grafana selects and loads the actual datasource using DatasourceUID, not the spoofed queryType. 5. The query therefore executes using Grafana's datasource credentials despite the caller lacking datasources:query.

The root cause is inconsistent query classification between authorization and execution: authorization trusts queryType, while execution trusts DatasourceUID.

Affected product / component

- Product: Grafana OSS - Component: Unified Alerting / ngalert - Area: Alert-rule datasource authorization and query evaluation - Confirmed version: Grafana OSS 13.0.1 - Affected version range: not yet assessed

Severity

- CVSS 3.1: 7.1 High - Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N - CWE-863: Incorrect Authorization

Scope is Unchanged because the vulnerable authorization decision and resulting impact remain within Grafana's security authority.

Source

- Researcher: czarflix - Intigriti report: GRAFANALABS-F996ATD7 - Report URL: https://app.intigriti.com/company/submissions/GRAFANALABS-F996ATD7

Related report / duplicate assessment

This is a default-Grafana-OSS reproduction of the root cause previously reported in GRAFANALABS-IAQAFIXI. The earlier submission was archived as Not Applicable because its proof of concept depended on Cloud/Enterprise-specific permission mechanisms, and the researcher was invited to demonstrate the issue under default OSS permissions. This report establishes that missing prerequisite and should be treated as the actionable OSS submission, not dismissed as a duplicate.

VUL-2026-0095 and VUL-2026-0126 concern Enterprise Recorded Queries and have different components, endpoints, and root causes; they are related authorization issues but not duplicates.

Recommended remediation

- Do not exempt a query from datasource authorization based solely on client-controlled queryType. - Resolve the referenced datasource server-side before authorization and apply datasources:query whenever the resolved UID represents a real datasource. - Require expression queries to reference only the canonical server-side expression datasource and reject mismatches such as queryType: "expr" paired with a real datasource UID. - Ensure authorization and evaluation use the same canonical datasource identity and fail closed when fields conflict. - Add regression coverage for an OSS user with folder-level alert-rule edit permission but without datasource query permission, including mismatched queryType and datasourceUid values.

Grafana OSS and Grafana Enterprise did not safely resolve symbolic links when extracting plugin archives. A crafted plugin archive can chain relative symbolic link entries to escape the plugin installation directory, writing arbitrary files and an executable backend binary outside that directory. The dropped executable runs with the privileges of the Grafana server process, resulting in remote code execution.

Plugin archives are extracted before their signature is verified, so a valid plugin signature does not prevent the write. An operator can therefore be affected by installing a plugin that appears legitimate, as well as by installing a plugin from an arbitrary archive using grafana-cli, the GFINSTALLPLUGINS environment variable, or preinstall configuration.

Grafana Enterprise is affected because it includes the same plugin extraction code as Grafana OSS.

Short description of the vulnerability: Grafana did not safely resolve symbolic links when extracting plugin archives. A crafted archive can chain relative symbolic-link entries to escape the plugin installation directory, write arbitrary files, and drop an executable backend binary outside that directory. The dropped executable runs with the privileges of the Grafana server process, which is remote code execution. Plugin archives are extracted before their signature is verified, so a valid signature does not prevent the write, and the payload also passes catalogue validation and signing. An instance can therefore be affected by installing a plugin that appears legitimate, as well as by installing a plugin from an arbitrary archive using grafana-cli, the GFINSTALLPLUGINS environment variable, or preinstall configuration.

Affected versions: Grafana OSS and Grafana Enterprise: 12.0.0 to 12.0.10, 12.1.0 to 12.1.10, 12.2.0 to 12.2.10, 12.3.0 to 12.3.11, 12.4.0 to 12.4.9, 13.0.0 to 13.0.7, 13.1.0 to 13.1.4, and 13.2.0.

Known mitigations:

Update to one of the private builds listed above. There is no configuration that fully mitigates this beforehand: plugin signing does not help, because extraction runs before signature verification, and catalogue review does not help, because the validator flattens the symbolic links and sees a benign plugin. Until you have updated, reduce exposure by not installing plugins from arbitrary archives, limiting installation to a vetted and pinned set of plugins, and keeping pluginadminenabled off where it is not needed.

An Editor can overwrite a dashboard not owned by them to acquire admin on that specific dashboard. The user must have write access to the dashboard to escalate privilege.

When using an IPv6 allow-list for the Auth Proxy feature, it defaults to /32 addresses. Addresses specifying a mask explicitly are not affected; to mitigate easily, add the desired mask (usually /128) to the addresses. Only auth proxy is affected; Okta, SAML, LDAP, etc are unaffected here.

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).

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.

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.

Grafana is an open-source platform for monitoring and observability. Starting with the 8.1 branch and prior to versions 8.5.16, 9.2.10, and 9.3.4, Grafana had a stored XSS vulnerability affecting the core plugin GeoMap. The stored XSS vulnerability was possible because SVG files weren't properly sanitized and allowed arbitrary JavaScript to be executed in the context of the currently authorized user of the Grafana instance.

An attacker needs to have the Editor role in order to change a panel to include either an external URL to a SVG-file containing JavaScript, or use the data: scheme to load an inline SVG-file containing JavaScript. This means that vertical privilege escalation is possible, where a user with Editor role can change to a known password for a user having Admin role if the user with Admin role executes malicious JavaScript viewing a dashboard.

Users may upgrade to version 8.5.16, 9.2.10, or 9.3.4 to receive a fix.

The grafanacubism-panel plugin allows use of cubism.js in Grafana. In 0.1.2 and earlier, the panel's zoom-link handler passes a dashboard-editor-supplied URL directly to window.location.assign() / window.open() with no scheme validation. An attacker with dashboard Editor privileges can set the link to a javascript: URI; when any Viewer drag-zooms on the panel, the payload executes in the Grafana origin.

Grafana is an open-source platform for monitoring and observability. Prior to versions 8.5.16 and 9.2.8, malicious user can create a snapshot and arbitrarily choose the originalUrl parameter by editing the query, thanks to a web proxy. When another user opens the URL of the snapshot, they will be presented with the regular web interface delivered by the trusted Grafana server. The Open original dashboard button no longer points to the to the real original dashboard but to the attacker’s injected URL. This issue is fixed in versions 8.5.16 and 9.2.8.

Grafana is an open-source platform for monitoring and observability. Prior to versions 8.5.16 and 9.2.8, malicious user can create a snapshot and arbitrarily choose the originalUrl parameter by editing the query, thanks to a web proxy. When another user opens the URL of the snapshot, they will be presented with the regular web interface delivered by the trusted Grafana server. The Open original dashboard button no longer points to the to the real original dashboard but to the attacker’s injected URL. This issue is fixed in versions 8.5.16 and 9.2.8.

Grafana is an open-source platform for monitoring and observability. Prior to versions 8.5.16 and 9.2.8, malicious user can create a snapshot and arbitrarily choose the originalUrl parameter by editing the query, thanks to a web proxy. When another user opens the URL of the snapshot, they will be presented with the regular web interface delivered by the trusted Grafana server. The Open original dashboard button no longer points to the to the real original dashboard but to the attacker’s injected URL. This issue is fixed in versions 8.5.16 and 9.2.8.

An authenticated user in Grafana can read SSO client secrets and modify instance-wide SSO settings without the required permissions (missing authorization). This affects Grafana OSS and Enterprise 13.2 installations with the experimental kubernetesSsoSettingsApi feature toggle enabled, which is disabled by default.

Grafana is an open-source platform for monitoring and observability. When datasource query caching is enabled, Grafana caches all headers, including grafanasession. As a result, any user that queries a datasource where the caching is enabled can acquire another user’s session. To mitigate the vulnerability you can disable datasource query caching for all datasources. This issue has been patched in versions 9.2.10 and 9.3.4.

Grafana is an open-source platform for monitoring and observability. When datasource query caching is enabled, Grafana caches all headers, including grafanasession. As a result, any user that queries a datasource where the caching is enabled can acquire another user’s session. To mitigate the vulnerability you can disable datasource query caching for all datasources. This issue has been patched in versions 9.2.10 and 9.3.4.

Grafana is an open-source platform for monitoring and observability. When datasource query caching is enabled, Grafana caches all headers, including grafanasession. As a result, any user that queries a datasource where the caching is enabled can acquire another user’s session. To mitigate the vulnerability you can disable datasource query caching for all datasources. This issue has been patched in versions 9.2.10 and 9.3.4.

A chained attack via SQL Expressions and a Grafana Enterprise plugin can lead to a remote arbitrary code execution impact (RCE). This is enabled by a feature in Grafana (OSS), so all users are always recommended to update to avoid future attack vectors going this path.

Only instances with the sqlExpressions feature toggle enabled are vulnerable.

Only instances in the following version ranges are affected:

- 11.6.0 (inclusive) to 11.6.14 (exclusive): 11.6.14 has the fix. 11.5 and below are not affected. - 12.0.0 (inclusive) to 12.1.10 (exclusive): 12.1.10 has the fix. 12.0 did not receive an update, as it is end-of-life. - 12.2.0 (inclusive) to 12.2.8 (exclusive): 12.2.8 has the fix. - 12.3.0 (inclusive) to 12.3.6 (exclusive): 12.3.6 has the fix. - 12.4.0 (inclusive) to 12.4.2 (exclusive): 12.4.2 has the fix. 13.0.0 and above also have the fix: no v13 release is affected.

A chained attack via SQL Expressions and a Grafana Enterprise plugin can lead to a remote arbitrary code execution impact (RCE). This is enabled by a feature in Grafana (OSS), so all users are always recommended to update to avoid future attack vectors going this path.

Only instances with the sqlExpressions feature toggle enabled are vulnerable.

Only instances in the following version ranges are affected:

- 11.6.0 (inclusive) to 11.6.14 (exclusive): 11.6.14 has the fix. 11.5 and below are not affected. - 12.0.0 (inclusive) to 12.1.10 (exclusive): 12.1.10 has the fix. 12.0 did not receive an update, as it is end-of-life. - 12.2.0 (inclusive) to 12.2.8 (exclusive): 12.2.8 has the fix. - 12.3.0 (inclusive) to 12.3.6 (exclusive): 12.3.6 has the fix. - 12.4.0 (inclusive) to 12.4.2 (exclusive): 12.4.2 has the fix. 13.0.0 and above also have the fix: no v13 release is affected.

Grafana is an open-source platform for monitoring and observability.

Starting with the 8.1 branch, Grafana had a stored XSS vulnerability affecting the core plugin GeoMap.

The stored XSS vulnerability was possible due to map attributions weren't properly sanitized and allowed arbitrary JavaScript to be executed in the context of the currently authorized user of the Grafana instance.

An attacker needs to have the Editor role in order to change a panel to include a map attribution containing JavaScript.

This means that vertical privilege escalation is possible, where a user with Editor role can change to a known password for a user having Admin role if the user with Admin role executes malicious JavaScript viewing a dashboard.

Users may upgrade to version 8.5.21, 9.2.13 and 9.3.8 to receive a fix.

The SQL Expressions experimental feature of Grafana allows for the evaluation of duckdb queries containing user input. These queries are insufficiently sanitized before being passed to duckdb, leading to a command injection and local file inclusion vulnerability. Any user with the VIEWER or higher permission is capable of executing this attack. The duckdb binary must be present in Grafana's $PATH for this attack to function; by default, this binary is not installed in Grafana distributions.

Grafana is an open-source platform for monitoring and observability. In versions prior to 8.5.13, 9.0.9, and 9.1.6, Grafana is subject to Improper Preservation of Permissions resulting in privilege escalation on some folders where Admin is the only used permission. The vulnerability impacts Grafana instances where RBAC was disabled and enabled afterwards, as the migrations which are translating legacy folder permissions to RBAC permissions do not account for the scenario where the only user permission in the folder is Admin, as a result RBAC adds permissions for Editors and Viewers which allow them to edit and view folders accordingly. This issue has been patched in versions 8.5.13, 9.0.9, and 9.1.6. A workaround when the impacted folder/dashboard is known is to remove the additional permissions manually.

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 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.

Only self-managed Grafana instances with Auth Proxy authentication and identity caching enabled (syncttl greater than zero) are affected. The Auth Proxy cache key concatenated the username and forwarded identity attributes without a delimiter, so distinct identities could collide on one key. An authenticated user who shapes their own attributes to collide with a higher-privileged user's, while that user's cache entry is live, is authenticated as that user, up to Administrator (authentication bypass by spoofing).

An Editor can set file-provisioning metadata (the 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.

A user or service account with read-only access to Git Sync (provisioning) connections can modify a connection's configuration through its status subresource (incorrect authorization). On Grafana 12.4 the affected API is only available when the experimental provisioning feature toggle is enabled.

Grafana’s RBAC service ignored the requested folder when checking whether a user was a folder administrator for deleted dashboard listings. A user with dashboard permission-management rights on any folder could therefore be treated as an administrator of every folder.

This could expose deleted dashboard items from folders where the user lacked administrative access. The fix requires permission on the specified folder, an ancestor, or a wildcard scope.

A security vulnerability in the /apis/dashboard.grafana.app/ endpoints allows authenticated users to bypass dashboard and folder permissions. The vulnerability affects all API versions (v0alpha1, v1alpha1, v2alpha1).

Impact:

- Viewers can view all dashboards/folders regardless of permissions

- Editors can view/edit/delete all dashboards/folders regardless of permissions

- Editors can create dashboards in any folder regardless of permissions

- Anonymous users with viewer/editor roles are similarly affected

Organization isolation boundaries remain intact. The vulnerability only affects dashboard access and does not grant access to datasources.

Grafana is an open-source platform for monitoring and observability. In Grafana Enterprise, the Request security feature allows list allows to configure Grafana in a way so that the instance doesn’t call or only calls specific hosts. The vulnerability present starting with version 7.4.0-beta1 and prior to versions 7.5.16 and 8.5.3 allows someone to bypass these security configurations if a malicious datasource (running on an allowed host) returns an HTTP redirect to a forbidden host. The vulnerability only impacts Grafana Enterprise when the Request security allow list is used and there is a possibility to add a custom datasource to Grafana which returns HTTP redirects. In this scenario, Grafana would blindly follow the redirects and potentially give secure information to the clients. Grafana Cloud is not impacted by this vulnerability. Versions 7.5.16 and 8.5.3 contain a patch for this issue. There are currently no known workarounds.