| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A user with query access to an Azure Monitor data source in Grafana can cause server-side requests to an attacker-controlled endpoint that disclose the data source's Azure access token (server-side request forgery). |
| A user with the Viewer role in Grafana can crash the server by submitting a crafted server-side math expression (uncontrolled recursion). A user with permission to provision alert rules can make the outage persist across restarts. |
| A user with read access to Grafana's server logs, or to a log store they are shipped to, can recover the OAuth and OIDC access, refresh and ID tokens of users who sign in through the Generic OAuth, Google or GitLab providers. Grafana writes these tokens to its logs unredacted when an access or ID token is not a valid JWT, when the ID token is missing (at debug level) or is not a string (exposure of sensitive information in log files). The exposure is bounded by the scopes granted to the configured OAuth client. |
| A user with permission to edit contact points but not their protected fields can change protected settings, such as a contact point's destination URL, by switching an integration to a legacy schema version, which can expose stored credentials and redirect alert notifications (incorrect authorization). |
| 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. |
| Grafana's data source proxy did not apply role-based access control to write requests forwarded to Loki data sources. A user holding only the Viewer role on an affected Grafana instance could send POST, PUT and DELETE requests through the proxy to the Loki rules API (/loki/api/v1/rules), allowing them to create, modify and delete Loki alerting rules. Because those rules are stored by Loki rather than by Grafana, the change took effect for every user of that Loki data source, not only for the Viewer who made the request.
Exploitation requires an authenticated Viewer account on the Grafana instance and a configured Loki data source; no other privileges are needed. Both Grafana OSS and Grafana Enterprise are affected. The defect is in Grafana's data source proxy; Loki itself is not vulnerable and does not need to be patched. |
| 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. |
| 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. |
| 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. |
| 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 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. |
| 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 GF_INSTALL_PLUGINS environment variable, or
preinstall configuration.
Grafana Enterprise is affected because it includes the same plugin extraction code as
Grafana OSS. |
| A stored cross-site scripting vulnerability in the Geomap panel's MapLibre base layer allows a user with the Editor role to execute arbitrary JavaScript in another user's session by hosting a malicious style configuration, enabling escalation to Org Admin. |
| Only self-managed Grafana instances with Auth Proxy authentication and identity caching enabled (sync_ttl 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). |
| When SAML IdP-initiated login is enabled in Grafana Enterprise, the SAML library skips validation of the InResponseTo field on all SAML responses, including SP-initiated logins. This removes anti-replay protection, allowing an attacker who obtains a valid signed SAML assertion to replay it and gain a session as the victim user. Only instances with the allow_idp_initiated SAML setting enabled are affected; this setting is off by default and Grafana OSS is not affected. |
| 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). |
| 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. |
| 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. |
