EUVD-2026-44862
GHSA-65p5-8cm9-qcxx
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach Loki query HTTP API
-
DeliveryCraft query with huge limit
-
ExploitTrigger oversized memory allocation
-
ExecutionRepeat to exhaust host memory
-
ImpactQuerier/ingester degradation or crash (DoS)
Vulnerability Assessment
| Weakness |
CWE
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires network reachability to Loki's HTTP query API and the ability to submit a query with an unusually large result limit; the CVSS models this as unauthenticated (PR:N) with no user interaction, so no credentials or victim action are modeled as required. The primary limiting factor is deployment strategy, which the vendor explicitly calls out: deployments that already enforce per-tenant query limits (e.g. max_entries_limit_per_query), sit behind an authenticating proxy, or run with generous memory headroom and horizontal scaling substantially reduce impact, whereas a single-binary or under-provisioned instance with default/unbounded limits is directly exposed. Realized severity therefore depends on whether query limits and auth are enforced in front of the query endpoint. |
| Impact | The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) scores 7.5 and reflects a network-reachable, low-complexity, unauthenticated availability attack with no confidentiality or integrity impact - a classic resource-exhaustion DoS rather than a code-execution or data-exposure bug. Real-world risk is strongly deployment-dependent: the description itself qualifies impact as depending on 'its deployment strategy,' so a monolithic/single-binary Loki without query limits or memory guardrails is at genuine risk, while a well-provisioned, sharded, per-tenant-limited deployment behind auth/proxy is far more resilient. No EPSS score, KEV listing, or POC is provided, so this is not evidence of active or imminent mass exploitation; the PR:N rating also assumes the query endpoint is reachable without authentication, which many production deployments front with a reverse proxy or gateway - verify tenant/auth exposure before treating PR:N as literal in your environment. |
| Exploit ScenarioDerived | An attacker who can reach the Loki HTTP query API sends a LogQL query specifying a very large limit value, causing the querier to attempt a correspondingly large memory allocation. Repeating or scaling such requests drives memory pressure that degrades or crashes the affected components, denying service to legitimate users; because the CVSS complexity is low and no authentication is modeled, the request requires no special tooling beyond API access. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 16, 2026
Uncontrolled memory allocation in Grafana Loki lets remote unauthenticated users issue queries with excessively large limit values, forcing the service to allocate large amounts of memory and potentially exhausting host resources. The impact is denial of service (CVSS 7.5, A:H only) and varies by deployment topology - a single-binary or under-provisioned deployment is far more exposed than a horizontally scaled microservices setup. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; note the input 'Information Disclosure' tag conflicts with the CVSS impact (C:N/I:N/A:H), which indicates an availability-only issue.
RemediationAI
Consult the Grafana security advisory at https://grafana.com/security/security-advisories/cve-2026-21729 and upgrade to the vendor's fixed release; the exact patched version was not included in the provided data and should be taken directly from that advisory rather than assumed (Patch available per vendor advisory). As compensating controls until patched, cap query result sizes and memory using Loki's per-tenant limits configuration - set or lower max_entries_limit_per_query and related query limits, and configure querier/ingester memory limits (and Kubernetes resource limits) so an oversized query cannot exhaust the node; the trade-off is that legitimate large queries will be rejected. Additionally, require authentication on the query API by fronting Loki with an authenticating reverse proxy or API gateway and restrict network access to the query/HTTP endpoints to trusted clients only, accepting the operational overhead of managing that access layer.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Grafana Loki is a horizontally scalable, multi-tenant log aggregation system (the logging counterpart to Prometheus) commonly deployed in Kubernetes and cloud-native environments and queried via LogQL through its HTTP query API. The flaw is an uncontrolled resource consumption problem: query parameters that set large result limits are honored without adequate bounding, so the querier/ingester components allocate memory proportional to the requested limit rather than to a safe ceiling. The affected component is Grafana Loki (CPE cpe:2.3:a:grafana:loki:*), and the root-cause class is CWE-770 (Allocation of Resources Without Limits or Throttling) / CWE-400 (Uncontrolled Resource Consumption), even though the input records CWE as N/A.
Know when Loki gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-reachable query API, low-complexity oversized-limit request, no auth modeled (PR:N), and pure availability impact via memory exhaustion (A:H, C:N, I:N).
Primary rating from Vendor (GRAFANA).
CVSS VectorVendor: GRAFANA
DescriptionCVE.org
Loki queries with large limits can cause large memory allocations which can impact the availability of the service, depending on its deployment strategy.
Executive ViewAI
Grafana Loki is vulnerable to remote denial of service through malicious queries with excessively large parameters, enabling any unauthenticated attacker to exhaust system memory and disable observability infrastructure. Organizations with internet-exposed Loki instances face immediate risk; exploitation requires no credentials and can originate from any network location. Loss of logging visibility directly impairs incident detection, forensics, and security investigation capability.
Rate-limit unauthenticated query endpoints; enforce maximum query limit parameters in request validation; implement per-query memory and CPU resource caps; restrict Loki API access to internal networks only where operationally feasible; deploy load balancing to distribute query load across multiple Loki instances; establish monitoring and alerting on oversized query attempts and per-query memory consumption.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Path traversal in Grafana Loki 2.3.0 through 3.5.8 allows unauthenticated remote attackers to read arbitrary files on th
An issue was discovered in Grafana Loki through 2.2.1. Rated medium severity (CVSS 5.3), this vulnerability is remotely
Exploit-DB