CVE-2026-81843 · Runtime
NO FIX YET
Grafana builds one Elasticsearch index name for every time interval in a query, with no upper limit. A user who can query such a data source can send one small query with an extreme time range and make the Grafana server run out of memory until it is terminated.
first public Nov 12, 2026 · 1 source
Check it with your coding agent
It reads this page and tells you if your code or app is affected.
Only Grafana instances with an Elasticsearch data source that uses a time-based index pattern are affected. Data sources with a static index name are not affected. Any user with permission to query such a data source can trigger it, including users holding only the Viewer role in a default configuration, so exposure depends on who can reach the Grafana server.
Not affected if no-elasticsearch-datasource, static-index-name
Who cares elasticsearch, grafana, self-hosted
grafana server -v or the Grafana UI build info, and compare it with the fixed versions below.No fix yet, per the sources.
Grafana is an open-source platform for monitoring and observability.
When an Elasticsearch data source is configured with a time-based index pattern, Grafana generated one index name for every interval in the requested query time range without any upper limit. A user with permission to query the data source, which includes users holding only the Viewer role in a default configuration, could submit a single small query with an extreme time range and cause the server to allocate memory until it was terminated. The allocation occurred before any request was sent to Elasticsearch, so the condition applied whether or not the Elasticsearch cluster was reachable.
Data sources configured with a static index name are not affected.
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
InfraStack checks it against your stack and answers on your report, with the evidence and the fix.