EUVD-2026-87795
GHSA-8xp9-rcqv-cqmq
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain low-privileged Elasticsearch credentials
-
DeliverySend crafted resource-intensive request
-
ExploitTrigger excessive allocation (CWE-400)
-
ExecutionExhaust node memory/resources
-
ImpactDenial of service for cluster
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
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 | Requires an authenticated account with at least low privileges on the Elasticsearch cluster (PR:L) reachable over the network; no user interaction is needed. Exploitation involves sending a request that triggers uncontrolled resource allocation, leading to memory/resource exhaustion and denial of service. Limiting factors: valid credentials are required (not fully unauthenticated), so clusters that restrict network exposure and enforce authentication significantly reduce risk; impact is availability-only (no data disclosure or modification). Exact vulnerable versions should be confirmed against Elastic advisory ESA-2026-170 (fixes referenced in 8.19.21, 9.4.6, 9.5.3). |
| Impact | The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 6.5) describes a network-reachable, low-complexity, availability-only denial of service that requires some level of authentication (PR:L). There is no confidentiality or integrity impact - this is a pure resource-exhaustion/DoS issue (CWE-400, Excessive Allocation CAPEC-130). No EPSS score, no CISA KEV listing, and no public exploit code were provided, so exploitation status is: no public exploit identified at time of analysis. The signals are internally consistent (a CWE-400 excessive-allocation flaw naturally maps to A:H with no C/I impact), so there is no high-CVSS-but-misleading discrepancy here; if anything the score is moderate and honest. The key limiting factor is PR:L - an attacker needs at least a low-privileged authenticated account, which meaningfully reduces exposure for clusters that are not internet-exposed with weak/anonymous access. Net assessment: a real but medium-severity availability concern, not an emergency; prioritize patching for clusters exposed to untrusted or lightly-authenticated clients, lower priority for locked-down internal deployments. Note: the referenced Elastic advisory (ESA-2026-170) title lists fixed versions 8.19.21, 9.4.6 and 9.5.3, but the exact affected version ranges were not machine-provided and should be confirmed against the advisory. |
| Exploit ScenarioDerived | A low-privileged authenticated user sends a specially crafted request (e.g., a query or API call that triggers excessive memory/resource allocation) to an Elasticsearch node. The server allocates disproportionate resources handling it, exhausting heap/memory and degrading or crashing the node, causing denial of service for all clients. No public proof-of-concept was identified at the time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 26, 2026
Denial of service in Elasticsearch allows a network-reachable, low-privileged authenticated user (PR:L) to exhaust server resources and take the cluster's availability down by triggering uncontrolled resource allocation; no user interaction is required (AC:L, UI:N) and the impact is availability-only (C:N/I:N/A:H, base score 6.5). Because a valid account with minimal privileges is a prerequisite, clusters that enforce authentication and limit network exposure are materially less exposed, and the attack cannot be launched fully unauthenticated. No public exploit code and no confirmed active exploitation were identified at time of analysis, so the practical risk is concentrated in multi-tenant or broadly reachable clusters where low-privilege access is easy to obtain; Elastic has published fixed versions in 8.19.21, 9.4.6 and 9.5.3 under advisory ESA-2026-170.
RemediationAI
Primary fix: upgrade to a vendor-released patched version - Elasticsearch 8.19.21, 9.4.6 or 9.5.3 as specified in Elastic security advisory ESA-2026-170 (https://discuss.elastic.co/t/elasticsearch-8-19-21-9-4-6-9-5-3-security-update-esa-2026-170/390681); a rolling upgrade following the standard Elasticsearch upgrade order (master-eligible nodes last) minimizes downtime but requires that no unpatched node remains reachable during the window. Where immediate patching is not possible, compensating controls should target the PR:L prerequisite: enforce authentication and turn off anonymous access on the HTTP layer, restrict network reachability of the transport (9300) and HTTP (9200) ports to trusted clients only via firewall or security groups, and apply role-based access control so that only identities that genuinely need query/index privileges hold them - all of which reduce, but do not eliminate, exposure since any remaining low-privilege account can still trigger the resource exhaustion. Operational hardenings that raise the cost of an exhaustion attempt include tightening per-request limits (search/scroll timeouts, max buckets/result windows and bulk size caps), lowering the circuit-breaker thresholds for parent and field-data breakers so queries fail fast instead of consuming the heap, and monitoring JVM heap and thread-pool rejections for anomalies; these are trade-offs because aggressive limits can reject legitimate analytics workloads. Note that no vendor-released patch absence applies here - fixes are published - and no public exploit code or confirmed active exploitation was identified at time of analysis, so prioritization should follow standard patching cadence for an availability-only, authenticated issue rather than emergency response.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause class is CWE-400, Uncontrolled Resource Consumption, mapped to CAPEC-130 (Excessive Allocation). Elasticsearch is a Java-based distributed search and analytics engine whose request-handling layers (REST/HTTP APIs, query execution, aggregation and indexing pipelines) allocate heap, thread pools, file handles and network buffers based on request-driven demand. In this issue, a crafted request from an authenticated account causes the node or cluster to allocate resources without adequate bounding, progressively exhausting a constrained resource such as JVM heap or a thread/queue pool until the node becomes unresponsive or the master is destabilized, degrading cluster availability. The vulnerability is network-vectored (AV:N) with low attack complexity (AC:L) and no user interaction (UI:N), but the CVSS vector explicitly carries PR:L, meaning the attacker must already hold at least a low-privileged account on the cluster; the scope is unchanged (S:U). The CPE entry cpe:2.3:a:elastic:elasticsearch:*:*:*:*:*:*:*:* covers the product family generically rather than pinning a single version, so the affected version set must be confirmed against Elastic's advisory ESA-2026-170 rather than inferred from the CPE string; the referenced fix trains (8.19.21, 9.4.6, 9.5.3) indicate the issue spans the 8.x and 9.x lines.
Know when Elasticsearch 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:L/UI:N/S:U/C:N/I:N/A:H
Network-reachable low-complexity DoS requiring a low-privileged authenticated account (PR:L); availability-only impact with no confidentiality or integrity effect and no scope change.
Primary rating from Vendor (elastic).
CVSS VectorVendor: elastic
DescriptionCVE.org
Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130).
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
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.
More in Elasticsearch
View allThe Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the s
The default configuration in Elasticsearch before 1.2 enables dynamic scripting, which allows remote attackers to execut
Directory traversal vulnerability in Elasticsearch before 1.6.1 allows remote attackers to read arbitrary files via unsp
Directory traversal vulnerability in Elasticsearch before 1.4.5 and 1.5.x before 1.5.2, when a site plugin is enabled, a
A flaw was discovered in Elasticsearch, affecting the _search API that allowed a specially crafted query string to cause
Maliciously crafted on-chain account names processed by Klever-Go prior to 1.7.20 are spliced into Elasticsearch _bulk r
All versions of Elastic Cloud Enterprise has the Elasticsearch “anonymous” user enabled by default in deployed clusters.
A memory disclosure vulnerability was identified in Elasticsearch 7.10.0 to 7.13.3 error reporting. Rated medium severit
Remote code execution in Elasticsearch's machine learning component allows an authenticated user with ML model deploymen
Heap corruption and potential remote code execution in Elasticsearch's native ML inference engine can be triggered by an
The fix for CVE-2020-7009 was found to be incomplete. Rated high severity (CVSS 8.8), this vulnerability is remotely exp
Elasticsearch versions from 6.7.0 before 6.8.8 and 7.0.0 before 7.6.2 contain a privilege escalation flaw if an attacker
Exploit-DB