Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain low-privilege Elasticsearch credentials
-
ExploitSend crafted request triggering excessive allocation
-
ExecutionExhaust node memory/CPU resources
-
ImpactCluster denial of service
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 authenticated access to the Elasticsearch API - the CVSS PR:L metric confirms low-privilege credentials (or an improperly exposed/authenticated API endpoint) are needed; it is not exploitable by fully unauthenticated remote attackers. Once authenticated, the attacker sends a crafted request causing uncontrolled resource consumption (excessive allocation, CWE-400/CAPEC-130). Limiting factors: authentication is mandatory, impact is availability-only (no data disclosure or modification), and scope is unchanged (single cluster/node). Real-world exposure is highest in multi-tenant clusters or deployments where the Elasticsearch HTTP API is reachable by many users; properly network-segmented, single-tenant clusters face lower practical risk. |
| Impact | The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 6.5) describes an authenticated, network-reachable, low-complexity denial-of-service with availability-only impact and no confidentiality or integrity loss - a self-contained crash/resource-exhaustion, not code execution or data theft. The PR:L requirement is the single most important limiter: an attacker needs valid (even low-privilege) Elasticsearch credentials or API access, which meaningfully narrows the exposed population to internal users, tenants, or environments where the API is improperly exposed. No EPSS score, no CISA KEV listing, and no public proof-of-concept were provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The signals are internally consistent (medium severity, availability-only, authenticated), so this is a genuine but bounded availability risk rather than a high-urgency critical flaw - patch on a normal cycle unless the cluster is multi-tenant or its API is broadly accessible. Note the reference is only a vendor discussion-forum advisory (ESA-2026-180); exact affected-version boundaries and the precise triggering request are not detailed in the supplied data and should be verified against Elastic's advisory. |
| Exploit ScenarioDerived | An attacker holding low-privilege but valid Elasticsearch API credentials sends a specially crafted request that triggers excessive memory/resource allocation (CAPEC-130), exhausting heap or CPU and rendering the node or cluster unresponsive to legitimate queries. Because the vector is network-based with low complexity, the request can be repeated to sustain the outage. No public exploit code is identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 26, 2026
Authenticated denial of service in Elasticsearch lets a low-privilege user with network reachability to the cluster API exhaust node or cluster resources through a crafted request that triggers uncontrolled allocation (CWE-400 / CAPEC-130), driving availability-only degradation rather than data theft or code execution. The vendor-assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 6.5) confirms the attacker must first hold valid low-privilege credentials (or reach an improperly exposed/authenticated API endpoint), that no user interaction is needed, and that confidentiality and integrity are unaffected while scope remains unchanged to the single affected deployment. Practical exposure is greatest in multi-tenant clusters or environments where the Elasticsearch HTTP API is broadly reachable; properly segmented single-tenant clusters face lower risk, and no public exploit code or confirmed active exploitation was identified at time of analysis.
RemediationAI
Upgrade to the patched Elasticsearch builds named in Elastic security update ESA-2026-180, which covers the 8.19.x, 9.4.x and 9.5.x release lines (see the advisory at https://discuss.elastic.co/t/elasticsearch-8-19-22-9-4-7-9-5-4-security-update-esa-2026-180/390684 for the precise version numbers and install instructions); this is a vendor-released patch per the referenced advisory. Where an immediate upgrade cannot be scheduled, compensating controls should target the mandatory PR:L prerequisite: enforce authentication on the HTTP API (never expose port 9200 unauthenticated), and remove or restrict low-privilege accounts and API keys that do not need broad search, scroll, or bulk access, accepting that this may break legitimate automation using shared credentials. Blocking or IP-allowlisting the Elasticsearch HTTP endpoint so only trusted application subnets can reach it prevents exploitation by roaming tenants but will cut off legitimate clients outside that range. Operator-level safeguards such as lowering search/scroll limits, tightening circuit-breaker thresholds, capping thread-pool queue sizes, and alerting on heap pressure or rejected-request metrics can reduce the blast radius of an abusive request but will also reject some legitimate heavy queries and require capacity tuning. Note that these are mitigations only; none removes the underlying defect, and availability-only impact means post-incident validation should focus on node restarts and resource telemetry rather than indicators of data exfiltration.
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 flaw is an instance of Uncontrolled Resource Consumption (CWE-400), mapped to CAPEC-130 (Excessive Allocation), inside Elasticsearch's request-handling path. Elasticsearch is a Java-based distributed search and analytics engine that exposes a REST/HTTP API on port 9200 (and transport on 9300), with resource governance typically handled through JVM heap sizing, circuit breakers, thread-pool queues, and search/scroll/bulk request limits. In this class of defect, a request crafted by an authenticated caller can cause the node to allocate memory, threads, file handles, or queue slots beyond intended bounds faster than they are released, so the JVM heap or thread pools saturate or the node becomes unresponsive until it is restarted or the workload is shed. The CPE entry cpe:2.3:a:elastic:elasticsearch:*:*:*:*:*:*:*:* uses wildcard versioning, meaning the vendor advisory rather than the CPE string determines the exact vulnerable version ranges; the reference to Elastic's ESA-2026-180 security update implies the affected code spans multiple maintained release lines. Because the vector carries PR:L and C:N/I:N, the root cause is not memory corruption, injection, or a privilege boundary bypass but a missing or insufficient input/resource bound that a legitimate authenticated API surface exposes.
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 API reachable with low-privilege credentials (PR:L), low complexity, no user interaction; availability-only resource-exhaustion DoS with no confidentiality or integrity impact and no scope change.
Primary rating from Vendor (elastic).
CVSS VectorVendor: elastic
DescriptionCVE.org
Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead denial of service via Excessive Allocation (CAPEC-130)
Threat Intelligence Overview
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
EUVD-2026-87798
GHSA-w22c-qxrr-qv8r
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB