Technical write-up · Grafana
Paused shared dashboard access tokens still expose data source configuration
Analysis of Grafana CVE-2026-81841, the boundary between a paused share and current data-source configuration, and the released authorization correction.
What should a paused share still reveal?
A person holding a previously valid Grafana shared-dashboard link could continue receiving current data-source configuration after its owner paused the share. The starting capability was the link itself: no Grafana account or stolen account session was required. My research question was whether pausing applied consistently to the information available through that link, including information used to prepare the page.
Grafana’s September 29 advisory describes this missing authorization and rates CVE-2026-81841 Medium 5.3 under CVSS 3.1. The locally demonstrated result was narrower than the advisory’s full impact: live metadata for a referenced data source remained visible, while dashboard viewing and queries were denied.
The observations below come from my original assessment, including two controlled local runs of Grafana OSS 13.2.0 with InfluxDB 2.7.12 and a functioning, supported proxy-mode data source. I reviewed those preserved results and the public correction for this article; no new reproduction or patched-release runtime test was performed.
Possessing a link and retaining permission
A shared link provides access within a particular sharing state. Pausing changes that state, so recognizing a token that once worked is insufficient to authorize current information disclosure. The authorization decision must also account for whether sharing remains enabled.
The public advisory identifies inconsistent enforcement between pausing the dashboard and supplying frontend initialization data. This matters because preventing the main dashboard from rendering does not necessarily prevent related configuration from reaching the browser. A paused-page response may need ordinary presentation information, but that does not establish permission to disclose current data-source configuration. Vendor explanation.
The research therefore focused on the information actually returned. Resolving an organization for page presentation, or receiving a successful response, would not by itself establish the claimed confidentiality failure.
Distinguishing live disclosure from a cached page
The two original 13.2.0 runs agreed on these controls. They summarize historical observations, not a procedure for reproducing the issue.
| Recorded comparison | Observation | Interpretation |
|---|---|---|
| Enabled share | Dashboard viewing, queries, and referenced data-source metadata were available. | The configured share and data source worked before pausing. |
| Same share while paused | Viewing and queries were denied; referenced metadata remained available. | The pause boundary was enforced inconsistently. |
| Token never issued for a share | Organization-specific data-source metadata was absent. | The exposed information was associated with the previously valid share. |
| Configuration changed after pausing | The paused share revealed the updated metadata while viewing and queries remained denied. | The disclosure reflected current state rather than a saved pre-pause page. |
The last comparison was particularly important. Information already received before pausing cannot be recalled from a visitor’s browser. Here, however, the returned information reflected changes made afterward. That separates continued access to current configuration from retention of previously public content. The unused-token control also distinguished the result from generic page initialization data.
The observed limit and the vendor’s broader assessment
In the supported proxy-mode assessment, the exposed material was data-source metadata. The records do not demonstrate disclosure of backend addresses or credentials, query access after pausing, writes, account takeover, or code execution. They also do not establish persistence after deleting or recreating a share. Earlier broader assumptions were narrowed accordingly.
Grafana’s published assessment additionally includes stored credentials for data sources using browser access. That is the vendor’s stated impact for that configuration; it is not a credential-disclosure result from my proxy-mode runs. Grafana also explicitly states that deleting the shared dashboard revokes its token. Public impact and lifecycle distinction.
Requiring the current sharing state
Grafana lists 12.4.12, 13.0.10, 13.1.7, and 13.2.3 as fixed releases. The vendor advisory and CVE record provide the published version guidance; my local assessment does not independently establish the first affected release or every affected branch.
In the inspected 13.2.3 release, GetOrgIdByAccessToken in pkg/services/publicdashboards/internal/database/database.go includes this condition:
sql := "SELECT org_id FROM dashboard_public WHERE access_token=? AND is_enabled=true"
The lookup requires both a matching token and an enabled share. The accompanying middleware also stops before assigning organization context when the lookup fails or returns no valid organization. These are focused parts of the published correction. Released lookup, released context guard.
This source review supports the authorization change in 13.2.3. Independent runtime verification of the patched releases has not been recorded. For regression coverage, I would require the following outcomes; these are proposed, unexecuted checks.
| Proposed case | Required behavior |
|---|---|
| Enabled share | Preserve intended shared viewing and queries. |
| Paused share, including subsequent configuration changes | Withhold current data-source configuration and continue denying viewing and queries. |
| Unknown or deleted share | Do not disclose organization-specific configuration. |
| Supported proxy and browser-access configurations | Apply the current sharing state consistently to disclosed configuration. |