CVE-2026-21728: Tempo query limit results in unbounded memory allocation
Tempo queries with large limits can cause large memory allocations which can impact the availability of the service, depending on its deployment strategy.
Mitigation can be done by setting max_result_limit in the search config, e.g. to 262144 (2^18).
Security readout for executives and security teams
Plain-English summary
CVE-2026-21728 is an availability risk in Grafana Tempo. Large query limits can trigger very large memory allocations, potentially degrading or taking down the service depending on deployment design.
Executive priority
Treat as high priority where Tempo supports production observability or incident response. The main business risk is service disruption, not data theft based on the provided sources.
Technical view
The source describes unbounded memory allocation from Tempo queries using large limits. CVSS 3.1 is 7.5 with network, low-complexity, unauthenticated availability impact and no confidentiality or integrity impact.
Likely exposure
Organizations running Grafana Tempo v1.3.0 are the identified affected group. Exposure is higher where Tempo query access is reachable and search limits are not capped.
Exploitation context
The bundle does not show CISA KEV listing or cited active exploitation. The CVSS vector indicates remote, unauthenticated, low-complexity availability impact, but no exploit activity is evidenced here.
Researcher notes
Evidence is strongest for resource exhaustion in Tempo v1.3.0 with large query limits. The bundle names a configuration mitigation, but does not provide complete affected-version ranges or exploit observations.
Mitigation direction
Set search max_result_limit as advised, for example 262144.
Check Grafana’s advisory for version-specific remediation guidance.
Review Red Hat errata if using Red Hat-packaged Tempo components.
Restrict unnecessary network access to Tempo query interfaces.
Monitor memory pressure and OOM events around query activity.
Validation and detection
Inventory Tempo deployments and confirm whether v1.3.0 is present.
Inspect Tempo search configuration for max_result_limit.
Verify query interfaces are not unnecessarily internet-exposed.
Review logs and metrics for large-limit queries and memory exhaustion.
Track Grafana and Red Hat advisory updates for fixed package details.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-400: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.