EUVD-2026-87796
GHSA-65c4-jxc9-pv9x
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain low-privilege cluster credentials
-
DeliverySend crafted resource-heavy request
-
ExploitTrigger excessive memory/CPU allocation
-
ExecutionExhaust node resources
-
ImpactDenial of service for all cluster users
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 valid low-privilege authenticated access to the Elasticsearch cluster (PR:L) - such as a low-tier user account, service account, or API key - reachable over the network (AV:N). The description does not name the specific endpoint, query type, or configuration that triggers the excessive allocation, so the exact triggering feature must be confirmed against the ESA-2026-176 advisory. Exploitation is limited by the authentication requirement (not exploitable by fully unauthenticated attackers) and produces availability impact only, with no data disclosure or modification; no user interaction is needed once authenticated. |
| Impact | The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) describes a network-reachable, low-complexity, authenticated (PR:L) denial-of-service with availability-only impact and no scope change - a coherent and credible profile for an uncontrolled resource-consumption (CWE-400 / CAPEC-130 Excessive Allocation) bug in Elasticsearch. The 6.5 base score is driven entirely by A:H; there is no confidentiality or integrity exposure, so this is a service-stability issue rather than a data-breach or code-execution one. No EPSS probability, CISA KEV listing, or public POC was provided, so there is no signal of active or imminent exploitation - the framework signals do not conflict, they are simply absent. The PR:L requirement is the most important mitigating factor: an attacker needs at least valid low-privilege credentials/API access to the cluster, which meaningfully narrows the threat to authenticated tenants, internal users, or compromised API keys rather than the open internet. Net assessment: a real but moderate operational-risk issue - patch-worthy given Elasticsearch's broad footprint and the ease of triggering resource exhaustion once authenticated, but not an emergency in the absence of exploitation evidence and given the authentication gate. |
| Exploit ScenarioDerived | An attacker holding low-privilege Elasticsearch credentials or a valid API key sends crafted request(s) that cause the node to allocate excessive resources (memory/heap or CPU), exhausting cluster capacity and rendering the search/indexing service unavailable to legitimate users. No public exploit code was identified in the provided data, and the CVSS complexity is low (AC:L), so a working request would be simple to reproduce once authenticated. |
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-privilege authenticated user to exhaust cluster resources through excessive allocation, degrading availability down to a full outage while leaving data confidentiality and integrity intact (CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). The flaw is an uncontrolled resource consumption bug (CWE-400 / CAPEC-130 Excessive Allocation), and the CPE record lists elastic:elasticsearch without version constraints, so every unpatched Elasticsearch deployment is presumed affected pending the vendor advisory ESA-2026-176. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; exploitation requires valid low-privilege credentials (a low-tier user, service account, or API key), which limits the population of attackers able to trigger it. The specific endpoint, query type, or configuration that produces the excessive allocation is not named in the available data describing the flaw and must be confirmed against the Elastic advisory.
RemediationAI
The primary fix is to upgrade to the patched Elasticsearch releases associated with the advisory URL for this issue - 8.19.22 on the 8.x line, and 9.4.7 or 9.5.4 on the 9.x lines - after confirming against Elastic security advisory ESA-2026-176 (https://discuss.elastic.co/t/elasticsearch-8-19-22-9-4-7-9-5-4-security-update-esa-2026-176/390682) exactly which builds are corrected, since the reference does not fully enumerate the vulnerable range. If an immediate upgrade is not possible, apply layered compensating controls that target the authenticated resource-consumption path: enforce least privilege so that no account, service principal, or API key holds more cluster access than its function requires, and remove or tightly scope credentials that are unused, since PR:L means any valid low-privilege identity is sufficient to trigger the bug; restrict network exposure of the HTTP and transport ports so that only trusted clients and application hosts can reach the cluster, remembering that this reduces attack surface but does not stop a malicious insider or a compromised credential; and apply per-client rate limiting, request-size caps, and concurrency limits at a reverse proxy or load balancer in front of Elasticsearch, accepting that overly tight limits can throttle legitimate bulk indexing and search workloads. Operationally, tighten JVM heap monitoring, circuit-breaker thresholds, and thread-pool and queue rejection logging so that an allocation spike is detected and shed before it becomes cluster-wide unavailability, and keep shard allocation and node capacity headroom so a single misbehaving request cannot starve the whole cluster. Note that patch availability per the vendor advisory is the only fully effective remedy: the advisory's specific triggering endpoint or query pattern is not disclosed in the data provided, so compensating controls cannot be tuned to a known signature and should be treated as risk reduction rather than elimination until the upgrade is applied.
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
Elasticsearch is a distributed, JVM-based search and analytics engine that exposes its entire functionality through an HTTP/JSON REST API, with authentication and authorization typically enforced by the X-Pack security layer via basic credentials, tokens, or API keys. CWE-400 (Uncontrolled Resource Consumption) covers cases where a program fails to bound or properly release a resource - here mapped to CAPEC-130 (Excessive Allocation), meaning an attacker can drive the server to allocate more memory, threads, file handles, connections, or queue capacity than the deployment is sized for. In a JVM service such as Elasticsearch the practical consequences are heap exhaustion, aggressive garbage-collection pauses, thread-pool or circuit-breaker saturation, and cluster-wide unresponsiveness, since a resource-starved coordinating node can stall shard operations for the whole cluster. The CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H confirms this is reachable over the network with low attack complexity, requires the attacker to hold some authenticated privilege (PR:L - low-tier account, service credential, or API key), needs no user interaction, does not cross a security scope boundary, and yields high availability impact with no confidentiality or integrity impact. Because the affected CPE string uses a wildcard version, the flaw is treated as present across the Elasticsearch product line up to the fixed releases rather than in one narrow build, and the root cause class suggests the fix hardens or caps resource allocation on the affected code path rather than correcting a memory-safety or injection error.
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 and low-complexity but requires authenticated low-privilege access (PR:L); availability-only impact (A:H) 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