Grafana Mimir's Alertmanager rejects tenant-supplied receiver configurations that reference local files, but the check did not cover two HTTP client settings: httpheaders.<name>.files and basicauth.usernamefile. A tenant permitted to upload an Alertmanager configuration could point these fields at any file readable by the Alertmanager process. When a notification was sent, Alertmanager read the file and put its contents in a header of the outgoing request. By directing the receiver at a server they control, the tenant could read files from the Alertmanager host, such as credentials and configuration.

Exploitation requires permission to write the tenant's Alertmanager configuration. Grafana Enterprise Metrics (GEM), which is built on Mimir, is also affected. The issue is fixed in Mimir 3.1.7 and 3.2.2 and in GEM 2.17.20. GEM 2.11 through 2.16 will not receive a fix; users on those versions should upgrade to 2.17.20 or later.

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’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 service account with user-management permissions in one organization can read, modify, disable or delete users belonging to other organizations on the same Grafana instance through the SCIM API (insecure direct object reference). Only Grafana Enterprise instances with SCIM enabled are affected.

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.

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.

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.

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.

Grafana Alloy’s prometheus.operator.servicemonitors component allows a user who can create or modify ServiceMonitor resources in a watched namespace to specify an arbitrary local file through bearerTokenFile. Alloy reads the file and sends its contents as a bearer token to an attacker-controlled scrape endpoint. This may disclose files accessible to the Alloy process, including its projected Kubernetes service account token, potentially granting the attacker Alloy’s Kubernetes permissions. Exploitation requires ServiceMonitor write access and lower privileges than Alloy’s service account.

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

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

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.

This vulnerability only affects Grafana stacks configured with multiple organizations; single-organization deployments are not impacted. In a multi-organization stack, a user who is an Org Admin of a single organization can call GET /api/access-control/users/permissions/search?actionPrefix=dashboards: and receive permission data belonging to other organizations. The disclosed data is limited to dashboard and folder identifiers (UIDs) and per-user permission/scope mappings (which user holds which access on which dashboard). Dashboard contents, panels, query results, datasource credentials, secrets, and personal data are not exposed. This is a limited cross-organization information disclosure affecting multi-org deployments only.

Grafana OnCall through 1.16.11 contains an unauthenticated access vulnerability that allows remote attackers to obtain a valid PluginAuthToken by sending a POST request to the internal plugin install endpoint using hardcoded default stackid and orgid values present in the public source tree. Attackers can leverage the acquired token to authenticate against all internal API endpoints, create arbitrary Admin users via the user-context header bootstrap path, revoke the legitimate plugin token, and redirect OnCall-to-Grafana API calls to an attacker-controlled host by overwriting the organization's grafanaurl and apitoken.

Loki queries with large limits can cause large memory allocations which can impact the availability of the service, depending on its deployment strategy.

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.

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

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.

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.

The public dashboard query endpoint does not limit request body size before processing, allowing unauthenticated attackers to trigger excessive memory allocation by sending arbitrarily large JSON payloads. This can lead to denial of service through memory exhaustion. No valid dashboard access token or authentication is required to exploit this vulnerability.

The Snowflake datasource allows for GET/PUT commands, which can allow any user with access to run queries against the data source to read/write files between the local grafana server and the connected Snowflake host.

A user with Editor permissions can place a malicious script in the attribution field of a Geomap panel's XYZ tile layer via a template variable. The script then executes in the browser of any user who views the affected dashboard (stored cross-site scripting).

A user with Viewer permissions can use specially crafted requests to the Tempo and Loki data source plugins to reach unintended backend endpoints. Depending on the backend configuration this can expose data source credentials, leak internal responses, or trigger administrative actions on the configured backend.

A user with Viewer permissions can use a path traversal in the Loki data source plugin to reach administrative Loki endpoints and read sensitive backend configuration and internal service information.

A TraceQL query in Grafana Tempo with a large exemplars hint value can cause the Tempo instance to allocate an excessive amount of memory, resulting in an out-of-memory crash. This could allow an authenticated user to trigger a denial of service against the Tempo service.

We have released version 5.24.0 of the Grafana Operator. This patch includes a CRITICAL severity security fix for a path traversal/privilege escalation vulnerability in the Grafana Operator.

Summary

The Grafana Operator supports loading dashboards & library panels using the jsonnet data templating language. The jsonnet expression is evaluated in the context of the operator manager pod.

Impact

It is possible for a malicious user who can create Dashboard or LibraryPanel resources for a Grafana instance to obtain the Kubernetes service account token of the Grafana Operator manager.

Affected versions

All Grafana Operator versions <= 5.23

Solutions and mitigations

All installations should be upgraded as soon as possible.

As a workaround, the following ValidatingAdmissionPolicy prevent the creation or modification of jsonnet based resources:

apiVersion: admissionregistration.k8s.io/v1

kind: ValidatingAdmissionPolicy

metadata:

name: "prevent-jsonnet-dashboards"

spec:

failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["grafana.integreatly.org"] apiVersions: ["v1beta1"] operations: ["CREATE", "UPDATE"] resources: ["grafanadashboards", "grafanalibrarypanels"] validations: - expression: "!has(object.spec.jsonnetLib)"

---

apiVersion: admissionregistration.k8s.io/v1

kind: ValidatingAdmissionPolicyBinding

metadata:

name: "prevent-jsonnet-dashboards-clusterwide"

spec:

policyName: "prevent-jsonnet-dashboards" validationActions: [Deny]

Acknowledgement

We would like to thank Artem Cherezov for responsibly disclosing the vulnerability.

Editors could delete any annotation, even those they do not have read access to. The editor user cannot create or read the annotations.