Elasticsearch
Monthly
Authorization bypass in Elasticsearch's Remote Cluster Security (RCS) 2.0 cross-cluster search path lets an authenticated principal holding a cross-cluster API key for one index send a crafted request that is authorized against that permitted index while actually executing against a different, unauthorized index, exposing that index's document contents, field mappings and other metadata, and in limited cases permitting modification of retention-lease state on it. The flaw is an authenticated authorization-boundary bypass (CVSS 7.1, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N), so the real-world risk is concentrated in multi-tenant or shared clusters that issue cross-cluster API keys to less-trusted tenants, while single-tenant clusters without shared cross-cluster keys are not meaningfully exposed. No public exploit code has been identified at time of analysis.
Incorrect authorization in Elasticsearch 8.x and 9.x allows an authenticated, already-privileged user (CVSS PR:H) who has been granted a non-default, delegated role-management privilege to escalate privileges within a cluster. By abusing a role-definition setting that expands the set of indices matched against a delegated index-scoped privilege, the holder can modify their own assigned role and reach indices that should remain restricted, including internal security data, and from there potentially obtain full administrative control of the cluster. Exploitation is only possible when the cluster has the configurable delegated role-management privilege explicitly enabled and granted with a broadly-scoped index pattern; default deployments that never delegate this capability are not affected. No public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited (not in CISA KEV). Vendor-released patches are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4.
Maliciously crafted on-chain account names processed by Klever-Go prior to 1.7.20 are spliced into Elasticsearch _bulk request bodies without JSON escaping, allowing an attacker who can submit a SetAccountName transaction to inject forged bulk actions that create, overwrite, or delete documents in any index the indexer can write to. Because the name is stored in consensus account state, the poisoned value is replayed by new and historical indexers, and no access to the indexing host or the Elasticsearch port is required. Severity is rated 8.4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:L; our independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), exploitation requires an authenticated low-privilege on-chain account plus a deployment that actually runs the Elasticsearch indexer, and the issue is fixed in 1.7.20; no public exploit identified at time of analysis, though the upstream fix ships a regression test that reproduces the advisory's injection construction.
Missing authorization in Elasticsearch's custom inference service allows a low-privileged user holding only inference execution rights to redirect outbound inference traffic to an attacker-controlled endpoint, causing administrator-provisioned credentials to leak to that destination. Affected across the 8.x and 9.x branches (Elasticsearch 8.0.0 through 8.19.18, 9.0.0 through 9.3.7, 9.4.0 through 9.4.3, and 9.5.0), this is a privilege-abuse path where an underprivileged internal user effectively hijacks admin-level secrets without requiring elevated permissions. No public exploit or active exploitation has been identified; EPSS sits at 0.17% and SSVC rates technical impact as partial.
Remote code execution in Elasticsearch's machine learning component allows an authenticated user with ML model deployment privileges to execute arbitrary attacker-controlled logic on the Elasticsearch host node by supplying a crafted trained model artifact. The flaw stems from unsafe deserialization (CWE-502) of model artifact data during the ML inference loading process, granting the attacker a broader OS system-call surface than the ML subsystem is intended to expose. Elastic has released fixed versions 8.19.2, 9.4.5, and 9.5.1 via ESA-2026-114; no public exploit code or CISA KEV listing has been identified at time of analysis.
Heap corruption and potential remote code execution in Elasticsearch's native ML inference engine can be triggered by any user holding the low-privilege ML model upload and deploy permission. By crafting a model that embeds an operation computing a memory address from an attacker-controlled offset, a low-privileged authenticated user can cause the native inference subprocess to read and write outside its allocated heap, reliably crashing that process or, under controlled heap layout conditions, executing arbitrary code within it. No active exploitation or public proof-of-concept has been identified at time of analysis, but the CVSS 8.8 rating, network-accessible vector, and explicit RCE potential in the vendor description place this in the urgent-remediation tier for any organization running Elasticsearch with ML features delegated to non-admin users.
The Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands via a crafted. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
The default configuration in Elasticsearch before 1.2 enables dynamic scripting, which allows remote attackers to execute arbitrary MVEL expressions and Java code via the source parameter to _search. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
Denial of service in Elasticsearch allows an authenticated user (CVSS vector PR:L) who holds read access to a single index to crash a node by defining a scripted runtime field whose script output builds a deeply nested geometry value; because serialization of script-generated geometry lacks the nesting-depth limit applied to text-supplied geometry, recursion exhausts the stack and the node terminates, and on some deployments it does not recover without manual intervention. The issue is availability-only (C:N/I:N/A:H, CVSS 6.5) with no data exposure, and no public exploit code was identified at time of analysis. Fixes are released in Elasticsearch 8.19.23, 9.4.8, and 9.5.5 per ESA-2026-198, so this is a moderate-priority patching item rather than an emergency, but clusters that allow untrusted users to read indices while scripting/runtime fields are enabled should treat it as more urgent.
Denial of service in Elasticsearch allows an authenticated user holding read access to just a single index to terminate a cluster node by submitting a search request whose aggregation definitions are deeply and maliciously nested. Processing the request drives unbounded recursive execution that exhausts the node's resources and crashes the affected process, which does not recover on its own and requires manual intervention to restore service. The flaw is scored CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), is availability-only, and no public exploit code or confirmed active exploitation was identified at time of analysis; the practical barrier is the authenticated read privilege prerequisite rather than remote reachability.
Denial of service in Elasticsearch lets an authenticated user who holds connector management privileges exhaust node heap memory by creating a connector resource with an excessively large description field and then causing that resource to be accessed or read, crashing the affected node. The path is network-reachable but requires PR:L authorization, and the impact is limited to availability with no data confidentiality or integrity loss. No public exploit code has been identified at time of analysis, and Elastic has released fixed versions 8.19.2, 9.0.6, 9.1.4, and 9.2.1 in advisory ESA-2026-195.
Denial of service in Elasticsearch allows authenticated users holding the manage_index_templates cluster privilege to exhaust node heap by registering multiple index-template resources with metadata near the per-resource size limit and then triggering a combined retrieval that materializes all metadata in memory simultaneously. Affected versions include Elasticsearch releases prior to 9.4.7, 9.5.3, and 8.19.23, as addressed in ESA-2026-192. No public exploit code has been identified at time of analysis, and exploitation requires the specified privilege, limiting the attack to trusted operators or compromised privileged accounts.
Denial of service in Elasticsearch 9.x lets an authenticated attacker holding only low-privilege credentials terminate a node by submitting a request that drives uncontrolled recursion and excessive memory allocation, taking down cluster availability. The CVSS 6.5 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) confirms availability-only impact with no data exposure or modification, reachable over the network with no user interaction or non-default configuration - though authentication at a low privilege level is required, so exposure is limited to insiders, compromised credentials, or over-permissive accounts. Exploitation status is no public exploit identified at time of analysis (no CISA KEV listing, EPSS not available), making this a moderate, availability-only risk rather than a top-tier emergency; vendor fixes are published as Elasticsearch 9.4.8 and 9.5.5 in ESA-2026-190.
Denial of service in Elasticsearch stems from catastrophic backtracking in the ES|QL CHUNK function, which accepts user-supplied regular expressions as text-splitting separators without validating their computational complexity or bounding their execution time. An authenticated attacker who holds read access to any text-based index and can invoke CHUNK through ES|QL can submit a crafted pattern that drives exponential regex blowup, consuming excessive CPU on Elasticsearch worker threads and degrading query throughput for other tenants on the affected node, though the cluster does not crash. CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) reflects a bounded availability-only impact, no public exploit code was identified at time of analysis, and patched releases are available as Elasticsearch 8.19.22, 9.4.8, and 9.5.5 per Elastic security update ESA-2026-189.
Unauthorized data stream modification in Elasticsearch allows an authenticated user who holds privileges over only a single resource to alter data streams outside their authorized scope through the Modify Data Streams API, enabling data injection into those streams or degrading their searchability. The flaw is rated CVSS 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) and is confined to integrity and availability - it explicitly does not let the attacker read a data stream they could not already access. Only deployments running 7.17.5-7.17.29, 8.2.2-8.19.18, 9.0.0-9.3.7, or 9.4.0-9.4.3 are affected, and there is no public exploit identified at time of analysis; the vendor security update (ESA-2026-188) points to fixed releases 8.19.19, 9.3.8, and 9.4.4.
Denial of service in Elasticsearch 8.x and 9.x lets an authenticated user with only low privileges crash cluster nodes by submitting a specially crafted query that drives uncontrolled memory growth in the query processing engine, ending in an out-of-memory termination. Because the trigger can be repeated - including through queries embedded in shared resources such as saved searches or stored queries - the result can escalate from a single node restart to persistent cluster unavailability, though there is no data disclosure or modification path. The flaw is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and no public exploit code has been identified at time of analysis.
Remote code execution in Django Haystack's Elasticsearch backend affects versions up to and including 3.3.0, where an attacker-controlled string reaching the result-deserialization path is passed to `eval()` inside `_to_python()` and executed in the Django application process. Exploitation is conditional rather than blanket: it requires the Elasticsearch backend, at least one `SearchField` declared with an `index_fieldname` alias that differs from its logical field name, and the ability to get a malicious payload indexed into that aliased field and returned by a subsequent search - a second-order/stored injection rather than a direct request-driven one. Publicly available exploit code exists (a GHSA advisory with source-level walkthrough was published alongside the fix), and the input CVSS vector marks PR:H, so under that vector exploitation is treated as authenticated; there is no CISA KEV entry indicating confirmed active exploitation. The vulnerability is patched in 3.4.0, and the reporting signals conflict sharply and must be weighed carefully: VulDB's CVSS 4.0 base of 2.0 contrasts with the upstream advisory's CVSS 3.1 base of 8.5, reflecting the gap between the mild vector assumptions and the full RCE impact when the alias configuration is present.
Resource exhaustion in Elasticsearch allows an authenticated high-privilege user to consume excessive node resources, causing denial of service through availability loss (CVSS 4.9). Affected deployments are all Elasticsearch versions before the vendor-fixed releases 8.19.22, 9.4.7, and 9.5.3, as reflected by the CPE wildcard and Elastic Security Advisory ESA-2026-184. Exploitation requires an authenticated account with high privileges (CVSS PR:H) and network access to the cluster API; there is no public exploit identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV). Impact is limited to availability, with no confidentiality or integrity effect, and realistic risk is confined to malicious insiders or attackers who already hold privileged credentials.
Authenticated denial of service in Elasticsearch lets a valid low-privilege account drive the node or cluster into uncontrolled resource consumption through an allocation-heavy request path, degrading or halting availability (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Only users holding at least a low-privileged, network-reachable API account can trigger it - an unauthenticated remote attacker cannot, and there is no confidentiality or integrity impact. Elastic rates this a genuine but modest-severity availability issue rather than a top-tier priority: no public exploit code has been identified at time of analysis, no CISA KEV listing applies, and the advisory does not name the specific endpoint or query construct that acts as the allocation sink. Vendor-released patches exist in Elasticsearch 8.19.22, 9.4.7, and 9.5.4 (ESA-2026-183).
Denial of service in Elasticsearch is possible because of uncontrolled resource consumption (CWE-400) that allows an authenticated user to drive excessive allocation and exhaust cluster resources. Elasticsearch deployments prior to 9.4.7 and 9.5.4 are affected; the issue is remote and low-complexity but requires valid low-privilege credentials or an API key (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and the impact is limited to availability with no data disclosure or modification. There is no public exploit identified at time of analysis and no confirmed active exploitation, and the vendor-scored severity of 6.5 places this as a moderate availability-only issue rather than a top-tier priority.
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.
Authenticated denial of service in Elasticsearch allows a remote attacker holding only low-privilege credentials to drive uncontrolled resource consumption, exhausting node memory and degrading or halting cluster availability (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Impact is confined to availability - there is no confidentiality or integrity loss - and exploitation requires a valid account, API key, or service token, so fully unauthenticated attackers cannot trigger it against a properly secured cluster. No public exploit code or confirmed active exploitation has been identified at time of analysis, and vendor fixes are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4 (ESA-2026-179).
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.
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.
HTTP Request Smuggling in Elasticsearch allows a network attacker to intercept confidential HTTP responses intended for other authenticated users when Elasticsearch is deployed behind certain proxy configurations. The vulnerability (CWE-444, CAPEC-33) arises from inconsistent HTTP request boundary interpretation between the intermediary proxy and Elasticsearch, enabling response queue poisoning that leaks data across user sessions. Vendor-released patches 8.19.20, 9.4.5, and 9.5.1 are available per ESA-2026-141; no public exploit code or CISA KEV listing has been identified at time of analysis.
Denial of service in Elasticsearch allows an authenticated user with elevated cluster privileges to submit a specially crafted API request that causes unbounded memory consumption, potentially crashing the targeted node and disrupting cluster availability. The flaw is classified as CWE-770 (Allocation of Resources Without Limits or Throttling) with CAPEC-130 attack pattern, and is confirmed by Elastic via advisory ESA-2026-47. No public exploit code or CISA KEV listing has been identified at time of analysis; the elevated-privilege requirement (PR:H) meaningfully constrains realistic attackers to insiders or compromised admin accounts.
Denial of service in Elasticsearch's wildcard matching component allows any authenticated user with search access to terminate an affected node by submitting a single crafted query. The recursive wildcard evaluator has no bounds on recursion depth or total match operations; a pattern containing many wildcard groups evaluated against a sufficiently long field name exhausts the JVM thread stack, triggering a StackOverflowError that Elasticsearch treats as unrecoverable, causing immediate node shutdown rather than graceful request failure. No public exploit has been identified at time of analysis, but exploitation requires only low-privilege search access (CVSS PR:L), meaning any application service account or authenticated API user represents a viable threat origin.
Memory exhaustion in Elasticsearch's search highlighting subsystem allows any authenticated read-only user to terminate a node process with a single crafted request. The highlighting API accepts an unbounded user-supplied count, and the internal data structure allocated from that count is not tracked by Elasticsearch's circuit breaker system, bypassing the existing OOM safeguards entirely. The defect is non-volumetric - one small request is sufficient - and degrades cluster routing and health beyond the targeted node. No public exploit has been identified at time of analysis, though the low attack complexity and minimal privilege requirement make this a realistic internal threat.
Uncontrolled recursion in Elasticsearch's custom analysis definition processing allows an authenticated low-privileged user to crash an individual cluster node with a single request. By submitting a malformed index creation request whose custom analyzer, tokenizer, or filter components reference each other without termination, the resolution logic enters unbounded recursion, exhausts the JVM thread stack, and terminates the targeted node. No public exploit has been identified at time of analysis, but the attack requires only index creation privileges - a permission commonly granted to application service accounts - making the practical barrier lower than the authentication prerequisite might suggest.
Uncontrolled recursion in Elasticsearch's search request processing allows an authenticated user with only read-level privileges on a single index to crash any cluster node by submitting a specially crafted query containing pathologically nested structures. The absence of a recursion depth limit causes thread stack exhaustion during deserialization of the nested payload, triggering an unhandled stack overflow that terminates the affected node. No public exploit code has been identified at time of analysis, and CISA KEV does not list this CVE, but the low privilege bar (read-only access) makes the attack surface broad in multi-tenant or exposed deployments.
Elasticsearch exposes an authenticated denial-of-service path where a user holding only read privileges on a single index can crash an entire cluster node with one small, crafted search request. Rooted in CWE-789 (Memory Allocation with Excessive Size Value) and matching CAPEC-130 (Excessive Allocation), the flaw causes the JVM heap to be exhausted, terminating the affected node and disrupting all workloads on it. No CISA KEV listing and no public exploit code have been identified at time of analysis, but the low attack complexity makes this a credible threat in multi-tenant or broadly-credentialed Elasticsearch deployments.
ES|QL query processing in Elasticsearch allows an authenticated low-privileged user to exhaust heap memory on any receiving cluster node by submitting a specially crafted query, rendering that node unavailable. The CVSS 6.5 score (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects remote, low-complexity exploitation requiring only a valid account, with high availability impact but no data exposure. Elastic has released fixes in versions 8.18.0 and 9.0.0 per advisory ESA-2026-111; no public exploit or active exploitation has been identified at time of analysis.
Denial of service in Elasticsearch allows any authenticated user holding only read-only index privileges to crash a cluster node by submitting a single crafted search request. The intervals query type does not enforce Elasticsearch's configurable input-length restriction, so a deeply nested pattern drives unbounded recursion that exhausts the JVM thread stack and terminates the node process. No public exploit or CISA KEV listing exists at time of analysis; however, the low complexity and minimal privilege bar make this a credible internal threat, and Elastic has released fixes in versions 8.19.20 and 9.4.5 per ESA-2026-81.
Memory exhaustion in Elasticsearch allows any authenticated user with only read privileges to crash an Elasticsearch node with a single small crafted API request. The root cause is missing validation of a user-controlled size value that is passed directly to an internal memory reservation routine, enabling uncontrolled heap allocation that terminates the node process and degrades cluster health. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, but the non-volumetric nature - one request is sufficient regardless of heap configuration - significantly lowers the bar for disruption by low-privileged insiders or compromised service accounts.
Denial of service in Elasticsearch allows any low-privileged authenticated user to crash an affected cluster node with a single crafted HTTP request. The root flaw is a validate-after-deserialize ordering error: Elasticsearch decodes and deserializes an opaque identifier before confirming the cluster issued it, and an attacker-controlled size value embedded in the forged identifier drives an uncapped heap allocation (CWE-789) that exhausts available memory and fatally terminates the node process. No public exploit code has been identified at time of analysis, and this CVE is not listed in the CISA KEV catalog.
Stack exhaustion in Elasticsearch allows any low-privileged authenticated user to crash an Elasticsearch node with a single crafted request. Affected are all Elasticsearch versions across the 8.x and 9.x release lines, with Elastic releasing fixed versions 8.19.20, 9.4.5, and 9.5.1 under ESA-2026-78. No public exploit code or CISA KEV listing is confirmed at time of analysis, but the low attack complexity and minimal privilege requirement make this a straightforward denial-of-service vector for any credentialed user.
Elasticsearch's indexing pipeline contains an algorithmic complexity flaw (CWE-407) that allows any low-privileged authenticated user with document indexing rights to submit a single crafted document that occupies a worker thread in the bounded indexing thread pool for a disproportionate duration, degrading indexing availability on the affected node. Affected versions span both the 8.x and 9.x release lines, with fixes available in 8.19.20 and 9.4.5 per ESA-2026-77. No public exploit has been identified at time of analysis, and no active exploitation is confirmed.
Denial of service in Elasticsearch allows an authenticated user with only read privileges to crash a cluster node by submitting a crafted search request. Processing the malicious input triggers unbounded memory allocation in a specific internal component, bypassing existing memory accounting controls and causing a fatal out-of-memory condition that terminates the affected node process. No public exploit code has been identified at time of analysis, but the low privilege requirement (read-only access) significantly broadens the potential attacker pool in multi-tenant or SaaS deployments.
Node process termination in Elasticsearch via the ingest simulate pipeline API allows low-privilege authenticated users to crash individual cluster nodes by submitting a crafted request that induces uncontrolled recursion. The vulnerability affects multiple Elasticsearch version lines, with Elastic releasing fixes in versions 8.19.1, 9.3.8, and 9.4.4 per advisory ESA-2026-75. No public exploit code or CISA KEV active-exploitation listing has been identified at time of analysis, but the low attack complexity and broad enterprise footprint of Elasticsearch make this a meaningful availability risk, particularly in multi-tenant or shared-cluster deployments.
ES|QL engine denial of service in Elasticsearch allows any authenticated network user to trigger exponential CPU consumption by submitting a specially crafted query, exhausting query worker thread pool resources and rendering ES|QL unavailable until the node is manually restarted. Affected versions span two major release trains: Elasticsearch 8.0.0-8.19.18 and the full 9.x series through 9.4.3. No public exploit code has been identified at time of analysis and CISA KEV confirmation is absent; however, Elastic's security team has released patches across all three affected branches (ESA-2026-74).
Uncontrolled recursion in Elasticsearch's query evaluation component allows a low-privileged authenticated user with read-level index access to crash an affected node by submitting a specially crafted search request. All three active release lines are affected: 8.19.x through 8.19.18, 9.3.x through 9.3.7, and 9.4.x through 9.4.3. The impact ranges from complete service outage in single-node deployments to sustained availability degradation and repeated node restarts in multi-node clusters. No public exploit code or active exploitation has been identified at time of analysis; Elastic has released patched versions 8.19.19, 9.3.8, and 9.4.4.
Node process termination in Elasticsearch allows a low-privileged authenticated user to crash any reachable cluster node with a single malformed search request. The vulnerability stems from a reachable assertion in the query parsing layer triggered by a null value in a specific query clause; because Elasticsearch treats assertion failures as fatal, the node process exits immediately. Single-node deployments lose service entirely; in clustered environments, each targeted node reduces available search capacity. No public exploit has been identified at time of analysis, and Elastic has released patched versions 8.19.19, 9.3.8, and 9.4.4 per advisory ESA-2026-64.
Heap exhaustion in Elasticsearch allows authenticated users holding search privileges to crash individual data nodes by submitting specially crafted search requests, degrading or taking down the cluster and requiring manual administrator intervention to restore service. Affected versions span the 8.x and 9.x release lines per vendor advisory ESA-2026-60, with fixes available in 8.19.15, 9.2.9, and 9.3.4 as inferred from the advisory URL. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog, but the low authentication barrier makes it a meaningful risk for multi-tenant or shared Elasticsearch deployments.
Denial of service in Elasticsearch allows a low-privileged authenticated user to crash an Elasticsearch node by submitting a specially crafted EQL sequence query against an index they control, triggering uncontrolled memory consumption (CWE-400, CAPEC-130). Affected across all tracked versions per CPE wildcard, with Elastic releasing fixes in versions 8.19.18, 9.3.7, and 9.4.4 per advisory ESA-2026-57. No public exploit code or CISA KEV listing has been identified at time of analysis, but the low attack complexity and broad Elasticsearch deployment footprint make this a credible internal threat in multi-tenant or shared cluster environments.
Incorrect Authorization (CWE-863) in Elasticsearch's ingest simulation feature allows authenticated users with limited index privileges to bypass per-index access controls and trigger ingest pipeline execution on indices they are not authorized to access directly. Pipeline output - potentially containing enriched or processed sensitive data - is returned to the requestor, and index mapping metadata for restricted indices can also be retrieved through the same mechanism. No public exploit code has been identified at time of analysis; vendor-released fixes are available in versions 8.19.18, 9.3.7, and 9.4.4.
Elasticsearch's machine learning API contains an unbounded resource allocation flaw that allows an authenticated user with elevated privileges to crash an affected node by submitting a specially crafted ML request over the network. The absence of throttling or quota enforcement on ML request memory consumption (CWE-770) means the node's JVM heap can be exhausted, rendering it unavailable without any confidentiality or integrity exposure. No public exploit code has been identified at the time of analysis, and this vulnerability does not appear in the CISA KEV catalog.
Denial of service in Elasticsearch allows any authenticated user to crash an affected cluster node by submitting a specially crafted query that triggers uncontrolled recursion during query processing. Excessive resource consumption during request handling can render the targeted node unavailable, disrupting search and indexing operations for all dependent applications. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog; however, the low privilege requirement makes it accessible to any user with query access.
Sustained CPU exhaustion in Elasticsearch allows an authenticated low-privilege user to render an affected node unresponsive by submitting a specially crafted bulk request to the _bulk API endpoint. The root cause is CWE-400 (Uncontrolled Resource Consumption), whereby the bulk request processing path fails to bound CPU allocation per request, aligning with CAPEC-130 (Excessive Allocation). No public exploit identified at time of analysis, and no KEV listing exists; however, the low attack complexity and standard network accessibility of the bulk API make this a credible insider or compromised-credential threat in production environments.
Packetbeat's PostgreSQL protocol parser improperly validates array indices, allowing authenticated attackers on the same network to crash the monitoring service by sending malicious packets. An attacker exploiting this denial-of-service vulnerability can terminate the Packetbeat process, disrupting monitoring capabilities on systems with PostgreSQL protocol monitoring enabled. No patch is currently available.
A low-privileged authenticated user can cause a persistent denial of service in Elasticsearch by submitting oversized user settings data, leading to an out-of-memory crash. The flaw is rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) and affects versions prior to 8.19.9, 9.1.9, and 9.2.3. No public exploit code has been identified, and EPSS is low at 0.32% (23rd percentile).
Authentication bypass in the Elasticsearch PKI realm lets a remote, unauthenticated attacker who presents a specially crafted X.509 client certificate - signed by a Certificate Authority the cluster already trusts - be resolved to another user's identity, granting that user's read and write privileges (CVSS 3.1:7.4, C:H/I:H/A:N). Exploitation is gated by two prerequisites: the PKI realm must be explicitly enabled and configured for client-certificate authentication (it is not a default mode), and the attacker must hold a certificate issued by a CA in the cluster's trusted set, so realistic exposure is limited to deployments whose trusted CA issues certificates beyond a small high-trust population. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; Elastic has published a fix in the ESA-2025-27 advisory covering Elasticsearch 8.19.8, 9.1.8, and 9.2.2.
Field Masking rules in Search Guard 3.1.1 and earlier can be bypassed as an inference oracle: although masked IP-address fields are redacted in the _source of returned documents, queries submitted against those fields still return matching hits, letting a low-privileged authenticated user reconstruct the redacted IP values incrementally. The flaw is confined to installations that apply Field Masking (FM) to IP-type fields; deployments using Field Level Security (FLS) on those same fields are not affected, which is also the vendor's documented workaround. Risk is moderate rather than critical: exploitation requires valid low-privilege search access to an index containing such masked fields, works only where FM rather than FLS is configured, and is a slow enumeration technique rather than a wholesale data dump, with EPSS at 0.27% (18th percentile), no CISA KEV listing, and no public exploit code identified at time of analysis.
Information disclosure in Elasticsearch audit logs allows an authenticated low-privilege attacker with adjacent network access and read access to the audit log to obtain sensitive data when audit logging is enabled and configured to log reindex API requests. The issue is non-default (auditing must be explicitly turned on), requires high attack complexity per our assessment, and affects confidentiality only with no integrity or availability impact. No public exploit identified at time of analysis, and EPSS is low at 0.25% (15th percentile); the NVD base score is 5.7 but our assessment suggests a modest-priority issue rather than a high-severity emergency.
Uncontrolled Resource Consumption in Elasticsearch while evaluating specifically crafted search templates with Mustache functions can lead to Denial of Service by causing the Elasticsearch node to. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity.
An issue was discovered in Elasticsearch, where a large recursion using the Well-KnownText formatted string with nested GeometryCollection objects could cause a stackoverflow. Rated medium severity (CVSS 4.9), this vulnerability is remotely exploitable, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
A flaw was discovered in Elasticsearch, where a large recursion using the innerForbidCircularReferences function of the PatternBank class could cause the Elasticsearch node to crash. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
An allocation of resources without limits or throttling in Elasticsearch can lead to an OutOfMemoryError exception resulting in a crash via a specially crafted query using an SQL function. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
An issue was discovered where improper authorization controls affected certain queries that could allow a malicious actor to circumvent Document Level Security in Elasticsearch and get access to. Rated medium severity (CVSS 6.0), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
It was discovered by Elastic engineering that when elasticsearch-certutil CLI tool is used with the csr option in order to create a new Certificate Signing Requests, the associated private key that. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
A flaw was discovered in Elasticsearch, affecting document ingestion when an index template contains a dynamic field mapping of “passthrough” type. Rated medium severity (CVSS 4.9), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
It was identified that if a cross-cluster API key. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity.
An uncaught exception in Elasticsearch >= 8.4.0 and < 8.11.1 occurs when an encrypted PDF is passed to an attachment processor through the REST API. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Incorrect Authorization issue exists in the API key based security model for Remote Cluster Security, which is currently in Beta, in Elasticsearch 8.10.0 and before 8.13.0. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
A flaw was discovered in Elasticsearch, where processing a document in a deeply nested pipeline on an ingest node could cause the Elasticsearch node to crash. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue was identified that allowed the unsafe deserialization of java objects from hadoop or spark configuration properties that could have been modified by authenticated users. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. No vendor patch available.
It was identified that malformed scripts used in the script processor of an Ingest Pipeline could cause an Elasticsearch node to crash when calling the Simulate Pipeline API. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
A flaw was discovered in Elasticsearch, affecting the _search API that allowed a specially crafted query string to cause a Stack Overflow and ultimately a Denial of Service. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue has been identified with how Elasticsearch handled incoming requests on the HTTP layer. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Elasticsearch generally filters out sensitive information and credentials before logging to the audit log. Rated medium severity (CVSS 4.4), this vulnerability is low attack complexity. No vendor patch available.
A Denial of Service flaw was discovered in Elasticsearch. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
A flaw was discovered in Elasticsearch 7.17.0’s upgrade assistant, in which upgrading from version 6.x to 7.x would disable the in-built protections on the security index, allowing authenticated. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Elasticsearch before 7.14.0 did not apply document and field level security to searchable snapshots. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In Elasticsearch versions before 7.13.3 and 6.8.17 an uncontrolled recursion vulnerability that could lead to a denial of service attack was identified in the Elasticsearch Grok parser. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity.
All versions of Elastic Cloud Enterprise has the Elasticsearch “anonymous” user enabled by default in deployed clusters. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
A memory disclosure vulnerability was identified in Elasticsearch 7.10.0 to 7.13.3 error reporting. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
In Elasticsearch versions before 7.11.2 and 6.8.15 a document disclosure flaw was found when Document or Field Level Security is used. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Elasticsearch versions before 7.11.2 and 6.8.15 contain a document disclosure flaw was found in the Elasticsearch suggester and profile API when Document and Field Level Security are enabled. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
A document disclosure flaw was found in Elasticsearch versions after 7.6.0 and before 7.11.0 when Document or Field Level Security is used. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. This Exposure of Sensitive Information vulnerability could allow attackers to access sensitive data that should not be disclosed.
Elasticsearch versions 7.7.0 to 7.10.1 contain an information disclosure flaw in the async search API. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable. This Insufficiently Protected Credentials vulnerability could allow attackers to obtain user credentials due to weak protection mechanisms.
Elasticsearch versions before 6.8.13 and 7.9.2 contain a document disclosure flaw when Document or Field Level Security is used. Rated low severity (CVSS 3.1), this vulnerability is remotely exploitable. No vendor patch available.
In Elasticsearch before 7.9.0 and 6.8.12 a field disclosure flaw was found when running a scrolling search with Field Level Security. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In Kibana versions before 6.8.11 and 7.8.1 the region map visualization in contains a stored XSS flaw. Rated medium severity (CVSS 6.7), this vulnerability is remotely exploitable. No vendor patch available.
Kibana versions before 6.8.11 and 7.8.1 contain a denial of service (DoS) flaw in Timelion. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable.
The fix for CVE-2020-7009 was found to be incomplete. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
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 is able to create API keys. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Elasticsearch versions 7.0.0-7.3.2 and 6.7.0-6.8.3 contain a username disclosure flaw was found in the API Key service. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
CF CLI version prior to v6.45.0 (bosh release version 1.16.0) writes the client id and secret to its config file when the user authenticates with --client-credentials flag. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. No vendor patch available.
A race condition flaw was found in the response headers Elasticsearch versions before 7.2.1 and 6.8.2 returns to a request. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
A permission issue was found in Elasticsearch versions before 5.6.15 and 6.6.1 when Field Level Security and Document Level Security are disabled and the _aliases, _shrink, or _split endpoints are. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Elasticsearch Security versions 6.5.0 and 6.5.1 contain an XXE flaw in Machine Learning's find_file_structure API. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Authorization bypass in Elasticsearch's Remote Cluster Security (RCS) 2.0 cross-cluster search path lets an authenticated principal holding a cross-cluster API key for one index send a crafted request that is authorized against that permitted index while actually executing against a different, unauthorized index, exposing that index's document contents, field mappings and other metadata, and in limited cases permitting modification of retention-lease state on it. The flaw is an authenticated authorization-boundary bypass (CVSS 7.1, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N), so the real-world risk is concentrated in multi-tenant or shared clusters that issue cross-cluster API keys to less-trusted tenants, while single-tenant clusters without shared cross-cluster keys are not meaningfully exposed. No public exploit code has been identified at time of analysis.
Incorrect authorization in Elasticsearch 8.x and 9.x allows an authenticated, already-privileged user (CVSS PR:H) who has been granted a non-default, delegated role-management privilege to escalate privileges within a cluster. By abusing a role-definition setting that expands the set of indices matched against a delegated index-scoped privilege, the holder can modify their own assigned role and reach indices that should remain restricted, including internal security data, and from there potentially obtain full administrative control of the cluster. Exploitation is only possible when the cluster has the configurable delegated role-management privilege explicitly enabled and granted with a broadly-scoped index pattern; default deployments that never delegate this capability are not affected. No public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited (not in CISA KEV). Vendor-released patches are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4.
Maliciously crafted on-chain account names processed by Klever-Go prior to 1.7.20 are spliced into Elasticsearch _bulk request bodies without JSON escaping, allowing an attacker who can submit a SetAccountName transaction to inject forged bulk actions that create, overwrite, or delete documents in any index the indexer can write to. Because the name is stored in consensus account state, the poisoned value is replayed by new and historical indexers, and no access to the indexing host or the Elasticsearch port is required. Severity is rated 8.4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:L; our independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), exploitation requires an authenticated low-privilege on-chain account plus a deployment that actually runs the Elasticsearch indexer, and the issue is fixed in 1.7.20; no public exploit identified at time of analysis, though the upstream fix ships a regression test that reproduces the advisory's injection construction.
Missing authorization in Elasticsearch's custom inference service allows a low-privileged user holding only inference execution rights to redirect outbound inference traffic to an attacker-controlled endpoint, causing administrator-provisioned credentials to leak to that destination. Affected across the 8.x and 9.x branches (Elasticsearch 8.0.0 through 8.19.18, 9.0.0 through 9.3.7, 9.4.0 through 9.4.3, and 9.5.0), this is a privilege-abuse path where an underprivileged internal user effectively hijacks admin-level secrets without requiring elevated permissions. No public exploit or active exploitation has been identified; EPSS sits at 0.17% and SSVC rates technical impact as partial.
Remote code execution in Elasticsearch's machine learning component allows an authenticated user with ML model deployment privileges to execute arbitrary attacker-controlled logic on the Elasticsearch host node by supplying a crafted trained model artifact. The flaw stems from unsafe deserialization (CWE-502) of model artifact data during the ML inference loading process, granting the attacker a broader OS system-call surface than the ML subsystem is intended to expose. Elastic has released fixed versions 8.19.2, 9.4.5, and 9.5.1 via ESA-2026-114; no public exploit code or CISA KEV listing has been identified at time of analysis.
Heap corruption and potential remote code execution in Elasticsearch's native ML inference engine can be triggered by any user holding the low-privilege ML model upload and deploy permission. By crafting a model that embeds an operation computing a memory address from an attacker-controlled offset, a low-privileged authenticated user can cause the native inference subprocess to read and write outside its allocated heap, reliably crashing that process or, under controlled heap layout conditions, executing arbitrary code within it. No active exploitation or public proof-of-concept has been identified at time of analysis, but the CVSS 8.8 rating, network-accessible vector, and explicit RCE potential in the vendor description place this in the urgent-remediation tier for any organization running Elasticsearch with ML features delegated to non-admin users.
The Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands via a crafted. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
The default configuration in Elasticsearch before 1.2 enables dynamic scripting, which allows remote attackers to execute arbitrary MVEL expressions and Java code via the source parameter to _search. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
Denial of service in Elasticsearch allows an authenticated user (CVSS vector PR:L) who holds read access to a single index to crash a node by defining a scripted runtime field whose script output builds a deeply nested geometry value; because serialization of script-generated geometry lacks the nesting-depth limit applied to text-supplied geometry, recursion exhausts the stack and the node terminates, and on some deployments it does not recover without manual intervention. The issue is availability-only (C:N/I:N/A:H, CVSS 6.5) with no data exposure, and no public exploit code was identified at time of analysis. Fixes are released in Elasticsearch 8.19.23, 9.4.8, and 9.5.5 per ESA-2026-198, so this is a moderate-priority patching item rather than an emergency, but clusters that allow untrusted users to read indices while scripting/runtime fields are enabled should treat it as more urgent.
Denial of service in Elasticsearch allows an authenticated user holding read access to just a single index to terminate a cluster node by submitting a search request whose aggregation definitions are deeply and maliciously nested. Processing the request drives unbounded recursive execution that exhausts the node's resources and crashes the affected process, which does not recover on its own and requires manual intervention to restore service. The flaw is scored CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), is availability-only, and no public exploit code or confirmed active exploitation was identified at time of analysis; the practical barrier is the authenticated read privilege prerequisite rather than remote reachability.
Denial of service in Elasticsearch lets an authenticated user who holds connector management privileges exhaust node heap memory by creating a connector resource with an excessively large description field and then causing that resource to be accessed or read, crashing the affected node. The path is network-reachable but requires PR:L authorization, and the impact is limited to availability with no data confidentiality or integrity loss. No public exploit code has been identified at time of analysis, and Elastic has released fixed versions 8.19.2, 9.0.6, 9.1.4, and 9.2.1 in advisory ESA-2026-195.
Denial of service in Elasticsearch allows authenticated users holding the manage_index_templates cluster privilege to exhaust node heap by registering multiple index-template resources with metadata near the per-resource size limit and then triggering a combined retrieval that materializes all metadata in memory simultaneously. Affected versions include Elasticsearch releases prior to 9.4.7, 9.5.3, and 8.19.23, as addressed in ESA-2026-192. No public exploit code has been identified at time of analysis, and exploitation requires the specified privilege, limiting the attack to trusted operators or compromised privileged accounts.
Denial of service in Elasticsearch 9.x lets an authenticated attacker holding only low-privilege credentials terminate a node by submitting a request that drives uncontrolled recursion and excessive memory allocation, taking down cluster availability. The CVSS 6.5 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) confirms availability-only impact with no data exposure or modification, reachable over the network with no user interaction or non-default configuration - though authentication at a low privilege level is required, so exposure is limited to insiders, compromised credentials, or over-permissive accounts. Exploitation status is no public exploit identified at time of analysis (no CISA KEV listing, EPSS not available), making this a moderate, availability-only risk rather than a top-tier emergency; vendor fixes are published as Elasticsearch 9.4.8 and 9.5.5 in ESA-2026-190.
Denial of service in Elasticsearch stems from catastrophic backtracking in the ES|QL CHUNK function, which accepts user-supplied regular expressions as text-splitting separators without validating their computational complexity or bounding their execution time. An authenticated attacker who holds read access to any text-based index and can invoke CHUNK through ES|QL can submit a crafted pattern that drives exponential regex blowup, consuming excessive CPU on Elasticsearch worker threads and degrading query throughput for other tenants on the affected node, though the cluster does not crash. CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) reflects a bounded availability-only impact, no public exploit code was identified at time of analysis, and patched releases are available as Elasticsearch 8.19.22, 9.4.8, and 9.5.5 per Elastic security update ESA-2026-189.
Unauthorized data stream modification in Elasticsearch allows an authenticated user who holds privileges over only a single resource to alter data streams outside their authorized scope through the Modify Data Streams API, enabling data injection into those streams or degrading their searchability. The flaw is rated CVSS 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) and is confined to integrity and availability - it explicitly does not let the attacker read a data stream they could not already access. Only deployments running 7.17.5-7.17.29, 8.2.2-8.19.18, 9.0.0-9.3.7, or 9.4.0-9.4.3 are affected, and there is no public exploit identified at time of analysis; the vendor security update (ESA-2026-188) points to fixed releases 8.19.19, 9.3.8, and 9.4.4.
Denial of service in Elasticsearch 8.x and 9.x lets an authenticated user with only low privileges crash cluster nodes by submitting a specially crafted query that drives uncontrolled memory growth in the query processing engine, ending in an out-of-memory termination. Because the trigger can be repeated - including through queries embedded in shared resources such as saved searches or stored queries - the result can escalate from a single node restart to persistent cluster unavailability, though there is no data disclosure or modification path. The flaw is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and no public exploit code has been identified at time of analysis.
Remote code execution in Django Haystack's Elasticsearch backend affects versions up to and including 3.3.0, where an attacker-controlled string reaching the result-deserialization path is passed to `eval()` inside `_to_python()` and executed in the Django application process. Exploitation is conditional rather than blanket: it requires the Elasticsearch backend, at least one `SearchField` declared with an `index_fieldname` alias that differs from its logical field name, and the ability to get a malicious payload indexed into that aliased field and returned by a subsequent search - a second-order/stored injection rather than a direct request-driven one. Publicly available exploit code exists (a GHSA advisory with source-level walkthrough was published alongside the fix), and the input CVSS vector marks PR:H, so under that vector exploitation is treated as authenticated; there is no CISA KEV entry indicating confirmed active exploitation. The vulnerability is patched in 3.4.0, and the reporting signals conflict sharply and must be weighed carefully: VulDB's CVSS 4.0 base of 2.0 contrasts with the upstream advisory's CVSS 3.1 base of 8.5, reflecting the gap between the mild vector assumptions and the full RCE impact when the alias configuration is present.
Resource exhaustion in Elasticsearch allows an authenticated high-privilege user to consume excessive node resources, causing denial of service through availability loss (CVSS 4.9). Affected deployments are all Elasticsearch versions before the vendor-fixed releases 8.19.22, 9.4.7, and 9.5.3, as reflected by the CPE wildcard and Elastic Security Advisory ESA-2026-184. Exploitation requires an authenticated account with high privileges (CVSS PR:H) and network access to the cluster API; there is no public exploit identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV). Impact is limited to availability, with no confidentiality or integrity effect, and realistic risk is confined to malicious insiders or attackers who already hold privileged credentials.
Authenticated denial of service in Elasticsearch lets a valid low-privilege account drive the node or cluster into uncontrolled resource consumption through an allocation-heavy request path, degrading or halting availability (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Only users holding at least a low-privileged, network-reachable API account can trigger it - an unauthenticated remote attacker cannot, and there is no confidentiality or integrity impact. Elastic rates this a genuine but modest-severity availability issue rather than a top-tier priority: no public exploit code has been identified at time of analysis, no CISA KEV listing applies, and the advisory does not name the specific endpoint or query construct that acts as the allocation sink. Vendor-released patches exist in Elasticsearch 8.19.22, 9.4.7, and 9.5.4 (ESA-2026-183).
Denial of service in Elasticsearch is possible because of uncontrolled resource consumption (CWE-400) that allows an authenticated user to drive excessive allocation and exhaust cluster resources. Elasticsearch deployments prior to 9.4.7 and 9.5.4 are affected; the issue is remote and low-complexity but requires valid low-privilege credentials or an API key (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and the impact is limited to availability with no data disclosure or modification. There is no public exploit identified at time of analysis and no confirmed active exploitation, and the vendor-scored severity of 6.5 places this as a moderate availability-only issue rather than a top-tier priority.
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.
Authenticated denial of service in Elasticsearch allows a remote attacker holding only low-privilege credentials to drive uncontrolled resource consumption, exhausting node memory and degrading or halting cluster availability (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Impact is confined to availability - there is no confidentiality or integrity loss - and exploitation requires a valid account, API key, or service token, so fully unauthenticated attackers cannot trigger it against a properly secured cluster. No public exploit code or confirmed active exploitation has been identified at time of analysis, and vendor fixes are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4 (ESA-2026-179).
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.
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.
HTTP Request Smuggling in Elasticsearch allows a network attacker to intercept confidential HTTP responses intended for other authenticated users when Elasticsearch is deployed behind certain proxy configurations. The vulnerability (CWE-444, CAPEC-33) arises from inconsistent HTTP request boundary interpretation between the intermediary proxy and Elasticsearch, enabling response queue poisoning that leaks data across user sessions. Vendor-released patches 8.19.20, 9.4.5, and 9.5.1 are available per ESA-2026-141; no public exploit code or CISA KEV listing has been identified at time of analysis.
Denial of service in Elasticsearch allows an authenticated user with elevated cluster privileges to submit a specially crafted API request that causes unbounded memory consumption, potentially crashing the targeted node and disrupting cluster availability. The flaw is classified as CWE-770 (Allocation of Resources Without Limits or Throttling) with CAPEC-130 attack pattern, and is confirmed by Elastic via advisory ESA-2026-47. No public exploit code or CISA KEV listing has been identified at time of analysis; the elevated-privilege requirement (PR:H) meaningfully constrains realistic attackers to insiders or compromised admin accounts.
Denial of service in Elasticsearch's wildcard matching component allows any authenticated user with search access to terminate an affected node by submitting a single crafted query. The recursive wildcard evaluator has no bounds on recursion depth or total match operations; a pattern containing many wildcard groups evaluated against a sufficiently long field name exhausts the JVM thread stack, triggering a StackOverflowError that Elasticsearch treats as unrecoverable, causing immediate node shutdown rather than graceful request failure. No public exploit has been identified at time of analysis, but exploitation requires only low-privilege search access (CVSS PR:L), meaning any application service account or authenticated API user represents a viable threat origin.
Memory exhaustion in Elasticsearch's search highlighting subsystem allows any authenticated read-only user to terminate a node process with a single crafted request. The highlighting API accepts an unbounded user-supplied count, and the internal data structure allocated from that count is not tracked by Elasticsearch's circuit breaker system, bypassing the existing OOM safeguards entirely. The defect is non-volumetric - one small request is sufficient - and degrades cluster routing and health beyond the targeted node. No public exploit has been identified at time of analysis, though the low attack complexity and minimal privilege requirement make this a realistic internal threat.
Uncontrolled recursion in Elasticsearch's custom analysis definition processing allows an authenticated low-privileged user to crash an individual cluster node with a single request. By submitting a malformed index creation request whose custom analyzer, tokenizer, or filter components reference each other without termination, the resolution logic enters unbounded recursion, exhausts the JVM thread stack, and terminates the targeted node. No public exploit has been identified at time of analysis, but the attack requires only index creation privileges - a permission commonly granted to application service accounts - making the practical barrier lower than the authentication prerequisite might suggest.
Uncontrolled recursion in Elasticsearch's search request processing allows an authenticated user with only read-level privileges on a single index to crash any cluster node by submitting a specially crafted query containing pathologically nested structures. The absence of a recursion depth limit causes thread stack exhaustion during deserialization of the nested payload, triggering an unhandled stack overflow that terminates the affected node. No public exploit code has been identified at time of analysis, and CISA KEV does not list this CVE, but the low privilege bar (read-only access) makes the attack surface broad in multi-tenant or exposed deployments.
Elasticsearch exposes an authenticated denial-of-service path where a user holding only read privileges on a single index can crash an entire cluster node with one small, crafted search request. Rooted in CWE-789 (Memory Allocation with Excessive Size Value) and matching CAPEC-130 (Excessive Allocation), the flaw causes the JVM heap to be exhausted, terminating the affected node and disrupting all workloads on it. No CISA KEV listing and no public exploit code have been identified at time of analysis, but the low attack complexity makes this a credible threat in multi-tenant or broadly-credentialed Elasticsearch deployments.
ES|QL query processing in Elasticsearch allows an authenticated low-privileged user to exhaust heap memory on any receiving cluster node by submitting a specially crafted query, rendering that node unavailable. The CVSS 6.5 score (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects remote, low-complexity exploitation requiring only a valid account, with high availability impact but no data exposure. Elastic has released fixes in versions 8.18.0 and 9.0.0 per advisory ESA-2026-111; no public exploit or active exploitation has been identified at time of analysis.
Denial of service in Elasticsearch allows any authenticated user holding only read-only index privileges to crash a cluster node by submitting a single crafted search request. The intervals query type does not enforce Elasticsearch's configurable input-length restriction, so a deeply nested pattern drives unbounded recursion that exhausts the JVM thread stack and terminates the node process. No public exploit or CISA KEV listing exists at time of analysis; however, the low complexity and minimal privilege bar make this a credible internal threat, and Elastic has released fixes in versions 8.19.20 and 9.4.5 per ESA-2026-81.
Memory exhaustion in Elasticsearch allows any authenticated user with only read privileges to crash an Elasticsearch node with a single small crafted API request. The root cause is missing validation of a user-controlled size value that is passed directly to an internal memory reservation routine, enabling uncontrolled heap allocation that terminates the node process and degrades cluster health. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, but the non-volumetric nature - one request is sufficient regardless of heap configuration - significantly lowers the bar for disruption by low-privileged insiders or compromised service accounts.
Denial of service in Elasticsearch allows any low-privileged authenticated user to crash an affected cluster node with a single crafted HTTP request. The root flaw is a validate-after-deserialize ordering error: Elasticsearch decodes and deserializes an opaque identifier before confirming the cluster issued it, and an attacker-controlled size value embedded in the forged identifier drives an uncapped heap allocation (CWE-789) that exhausts available memory and fatally terminates the node process. No public exploit code has been identified at time of analysis, and this CVE is not listed in the CISA KEV catalog.
Stack exhaustion in Elasticsearch allows any low-privileged authenticated user to crash an Elasticsearch node with a single crafted request. Affected are all Elasticsearch versions across the 8.x and 9.x release lines, with Elastic releasing fixed versions 8.19.20, 9.4.5, and 9.5.1 under ESA-2026-78. No public exploit code or CISA KEV listing is confirmed at time of analysis, but the low attack complexity and minimal privilege requirement make this a straightforward denial-of-service vector for any credentialed user.
Elasticsearch's indexing pipeline contains an algorithmic complexity flaw (CWE-407) that allows any low-privileged authenticated user with document indexing rights to submit a single crafted document that occupies a worker thread in the bounded indexing thread pool for a disproportionate duration, degrading indexing availability on the affected node. Affected versions span both the 8.x and 9.x release lines, with fixes available in 8.19.20 and 9.4.5 per ESA-2026-77. No public exploit has been identified at time of analysis, and no active exploitation is confirmed.
Denial of service in Elasticsearch allows an authenticated user with only read privileges to crash a cluster node by submitting a crafted search request. Processing the malicious input triggers unbounded memory allocation in a specific internal component, bypassing existing memory accounting controls and causing a fatal out-of-memory condition that terminates the affected node process. No public exploit code has been identified at time of analysis, but the low privilege requirement (read-only access) significantly broadens the potential attacker pool in multi-tenant or SaaS deployments.
Node process termination in Elasticsearch via the ingest simulate pipeline API allows low-privilege authenticated users to crash individual cluster nodes by submitting a crafted request that induces uncontrolled recursion. The vulnerability affects multiple Elasticsearch version lines, with Elastic releasing fixes in versions 8.19.1, 9.3.8, and 9.4.4 per advisory ESA-2026-75. No public exploit code or CISA KEV active-exploitation listing has been identified at time of analysis, but the low attack complexity and broad enterprise footprint of Elasticsearch make this a meaningful availability risk, particularly in multi-tenant or shared-cluster deployments.
ES|QL engine denial of service in Elasticsearch allows any authenticated network user to trigger exponential CPU consumption by submitting a specially crafted query, exhausting query worker thread pool resources and rendering ES|QL unavailable until the node is manually restarted. Affected versions span two major release trains: Elasticsearch 8.0.0-8.19.18 and the full 9.x series through 9.4.3. No public exploit code has been identified at time of analysis and CISA KEV confirmation is absent; however, Elastic's security team has released patches across all three affected branches (ESA-2026-74).
Uncontrolled recursion in Elasticsearch's query evaluation component allows a low-privileged authenticated user with read-level index access to crash an affected node by submitting a specially crafted search request. All three active release lines are affected: 8.19.x through 8.19.18, 9.3.x through 9.3.7, and 9.4.x through 9.4.3. The impact ranges from complete service outage in single-node deployments to sustained availability degradation and repeated node restarts in multi-node clusters. No public exploit code or active exploitation has been identified at time of analysis; Elastic has released patched versions 8.19.19, 9.3.8, and 9.4.4.
Node process termination in Elasticsearch allows a low-privileged authenticated user to crash any reachable cluster node with a single malformed search request. The vulnerability stems from a reachable assertion in the query parsing layer triggered by a null value in a specific query clause; because Elasticsearch treats assertion failures as fatal, the node process exits immediately. Single-node deployments lose service entirely; in clustered environments, each targeted node reduces available search capacity. No public exploit has been identified at time of analysis, and Elastic has released patched versions 8.19.19, 9.3.8, and 9.4.4 per advisory ESA-2026-64.
Heap exhaustion in Elasticsearch allows authenticated users holding search privileges to crash individual data nodes by submitting specially crafted search requests, degrading or taking down the cluster and requiring manual administrator intervention to restore service. Affected versions span the 8.x and 9.x release lines per vendor advisory ESA-2026-60, with fixes available in 8.19.15, 9.2.9, and 9.3.4 as inferred from the advisory URL. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog, but the low authentication barrier makes it a meaningful risk for multi-tenant or shared Elasticsearch deployments.
Denial of service in Elasticsearch allows a low-privileged authenticated user to crash an Elasticsearch node by submitting a specially crafted EQL sequence query against an index they control, triggering uncontrolled memory consumption (CWE-400, CAPEC-130). Affected across all tracked versions per CPE wildcard, with Elastic releasing fixes in versions 8.19.18, 9.3.7, and 9.4.4 per advisory ESA-2026-57. No public exploit code or CISA KEV listing has been identified at time of analysis, but the low attack complexity and broad Elasticsearch deployment footprint make this a credible internal threat in multi-tenant or shared cluster environments.
Incorrect Authorization (CWE-863) in Elasticsearch's ingest simulation feature allows authenticated users with limited index privileges to bypass per-index access controls and trigger ingest pipeline execution on indices they are not authorized to access directly. Pipeline output - potentially containing enriched or processed sensitive data - is returned to the requestor, and index mapping metadata for restricted indices can also be retrieved through the same mechanism. No public exploit code has been identified at time of analysis; vendor-released fixes are available in versions 8.19.18, 9.3.7, and 9.4.4.
Elasticsearch's machine learning API contains an unbounded resource allocation flaw that allows an authenticated user with elevated privileges to crash an affected node by submitting a specially crafted ML request over the network. The absence of throttling or quota enforcement on ML request memory consumption (CWE-770) means the node's JVM heap can be exhausted, rendering it unavailable without any confidentiality or integrity exposure. No public exploit code has been identified at the time of analysis, and this vulnerability does not appear in the CISA KEV catalog.
Denial of service in Elasticsearch allows any authenticated user to crash an affected cluster node by submitting a specially crafted query that triggers uncontrolled recursion during query processing. Excessive resource consumption during request handling can render the targeted node unavailable, disrupting search and indexing operations for all dependent applications. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog; however, the low privilege requirement makes it accessible to any user with query access.
Sustained CPU exhaustion in Elasticsearch allows an authenticated low-privilege user to render an affected node unresponsive by submitting a specially crafted bulk request to the _bulk API endpoint. The root cause is CWE-400 (Uncontrolled Resource Consumption), whereby the bulk request processing path fails to bound CPU allocation per request, aligning with CAPEC-130 (Excessive Allocation). No public exploit identified at time of analysis, and no KEV listing exists; however, the low attack complexity and standard network accessibility of the bulk API make this a credible insider or compromised-credential threat in production environments.
Packetbeat's PostgreSQL protocol parser improperly validates array indices, allowing authenticated attackers on the same network to crash the monitoring service by sending malicious packets. An attacker exploiting this denial-of-service vulnerability can terminate the Packetbeat process, disrupting monitoring capabilities on systems with PostgreSQL protocol monitoring enabled. No patch is currently available.
A low-privileged authenticated user can cause a persistent denial of service in Elasticsearch by submitting oversized user settings data, leading to an out-of-memory crash. The flaw is rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) and affects versions prior to 8.19.9, 9.1.9, and 9.2.3. No public exploit code has been identified, and EPSS is low at 0.32% (23rd percentile).
Authentication bypass in the Elasticsearch PKI realm lets a remote, unauthenticated attacker who presents a specially crafted X.509 client certificate - signed by a Certificate Authority the cluster already trusts - be resolved to another user's identity, granting that user's read and write privileges (CVSS 3.1:7.4, C:H/I:H/A:N). Exploitation is gated by two prerequisites: the PKI realm must be explicitly enabled and configured for client-certificate authentication (it is not a default mode), and the attacker must hold a certificate issued by a CA in the cluster's trusted set, so realistic exposure is limited to deployments whose trusted CA issues certificates beyond a small high-trust population. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; Elastic has published a fix in the ESA-2025-27 advisory covering Elasticsearch 8.19.8, 9.1.8, and 9.2.2.
Field Masking rules in Search Guard 3.1.1 and earlier can be bypassed as an inference oracle: although masked IP-address fields are redacted in the _source of returned documents, queries submitted against those fields still return matching hits, letting a low-privileged authenticated user reconstruct the redacted IP values incrementally. The flaw is confined to installations that apply Field Masking (FM) to IP-type fields; deployments using Field Level Security (FLS) on those same fields are not affected, which is also the vendor's documented workaround. Risk is moderate rather than critical: exploitation requires valid low-privilege search access to an index containing such masked fields, works only where FM rather than FLS is configured, and is a slow enumeration technique rather than a wholesale data dump, with EPSS at 0.27% (18th percentile), no CISA KEV listing, and no public exploit code identified at time of analysis.
Information disclosure in Elasticsearch audit logs allows an authenticated low-privilege attacker with adjacent network access and read access to the audit log to obtain sensitive data when audit logging is enabled and configured to log reindex API requests. The issue is non-default (auditing must be explicitly turned on), requires high attack complexity per our assessment, and affects confidentiality only with no integrity or availability impact. No public exploit identified at time of analysis, and EPSS is low at 0.25% (15th percentile); the NVD base score is 5.7 but our assessment suggests a modest-priority issue rather than a high-severity emergency.
Uncontrolled Resource Consumption in Elasticsearch while evaluating specifically crafted search templates with Mustache functions can lead to Denial of Service by causing the Elasticsearch node to. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity.
An issue was discovered in Elasticsearch, where a large recursion using the Well-KnownText formatted string with nested GeometryCollection objects could cause a stackoverflow. Rated medium severity (CVSS 4.9), this vulnerability is remotely exploitable, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
A flaw was discovered in Elasticsearch, where a large recursion using the innerForbidCircularReferences function of the PatternBank class could cause the Elasticsearch node to crash. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
An allocation of resources without limits or throttling in Elasticsearch can lead to an OutOfMemoryError exception resulting in a crash via a specially crafted query using an SQL function. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
An issue was discovered where improper authorization controls affected certain queries that could allow a malicious actor to circumvent Document Level Security in Elasticsearch and get access to. Rated medium severity (CVSS 6.0), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
It was discovered by Elastic engineering that when elasticsearch-certutil CLI tool is used with the csr option in order to create a new Certificate Signing Requests, the associated private key that. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
A flaw was discovered in Elasticsearch, affecting document ingestion when an index template contains a dynamic field mapping of “passthrough” type. Rated medium severity (CVSS 4.9), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
It was identified that if a cross-cluster API key. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity.
An uncaught exception in Elasticsearch >= 8.4.0 and < 8.11.1 occurs when an encrypted PDF is passed to an attachment processor through the REST API. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Incorrect Authorization issue exists in the API key based security model for Remote Cluster Security, which is currently in Beta, in Elasticsearch 8.10.0 and before 8.13.0. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
A flaw was discovered in Elasticsearch, where processing a document in a deeply nested pipeline on an ingest node could cause the Elasticsearch node to crash. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue was identified that allowed the unsafe deserialization of java objects from hadoop or spark configuration properties that could have been modified by authenticated users. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. No vendor patch available.
It was identified that malformed scripts used in the script processor of an Ingest Pipeline could cause an Elasticsearch node to crash when calling the Simulate Pipeline API. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
A flaw was discovered in Elasticsearch, affecting the _search API that allowed a specially crafted query string to cause a Stack Overflow and ultimately a Denial of Service. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue has been identified with how Elasticsearch handled incoming requests on the HTTP layer. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Elasticsearch generally filters out sensitive information and credentials before logging to the audit log. Rated medium severity (CVSS 4.4), this vulnerability is low attack complexity. No vendor patch available.
A Denial of Service flaw was discovered in Elasticsearch. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
A flaw was discovered in Elasticsearch 7.17.0’s upgrade assistant, in which upgrading from version 6.x to 7.x would disable the in-built protections on the security index, allowing authenticated. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Elasticsearch before 7.14.0 did not apply document and field level security to searchable snapshots. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In Elasticsearch versions before 7.13.3 and 6.8.17 an uncontrolled recursion vulnerability that could lead to a denial of service attack was identified in the Elasticsearch Grok parser. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity.
All versions of Elastic Cloud Enterprise has the Elasticsearch “anonymous” user enabled by default in deployed clusters. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
A memory disclosure vulnerability was identified in Elasticsearch 7.10.0 to 7.13.3 error reporting. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
In Elasticsearch versions before 7.11.2 and 6.8.15 a document disclosure flaw was found when Document or Field Level Security is used. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Elasticsearch versions before 7.11.2 and 6.8.15 contain a document disclosure flaw was found in the Elasticsearch suggester and profile API when Document and Field Level Security are enabled. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
A document disclosure flaw was found in Elasticsearch versions after 7.6.0 and before 7.11.0 when Document or Field Level Security is used. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. This Exposure of Sensitive Information vulnerability could allow attackers to access sensitive data that should not be disclosed.
Elasticsearch versions 7.7.0 to 7.10.1 contain an information disclosure flaw in the async search API. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable. This Insufficiently Protected Credentials vulnerability could allow attackers to obtain user credentials due to weak protection mechanisms.
Elasticsearch versions before 6.8.13 and 7.9.2 contain a document disclosure flaw when Document or Field Level Security is used. Rated low severity (CVSS 3.1), this vulnerability is remotely exploitable. No vendor patch available.
In Elasticsearch before 7.9.0 and 6.8.12 a field disclosure flaw was found when running a scrolling search with Field Level Security. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
In Kibana versions before 6.8.11 and 7.8.1 the region map visualization in contains a stored XSS flaw. Rated medium severity (CVSS 6.7), this vulnerability is remotely exploitable. No vendor patch available.
Kibana versions before 6.8.11 and 7.8.1 contain a denial of service (DoS) flaw in Timelion. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable.
The fix for CVE-2020-7009 was found to be incomplete. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
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 is able to create API keys. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Elasticsearch versions 7.0.0-7.3.2 and 6.7.0-6.8.3 contain a username disclosure flaw was found in the API Key service. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
CF CLI version prior to v6.45.0 (bosh release version 1.16.0) writes the client id and secret to its config file when the user authenticates with --client-credentials flag. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. No vendor patch available.
A race condition flaw was found in the response headers Elasticsearch versions before 7.2.1 and 6.8.2 returns to a request. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
A permission issue was found in Elasticsearch versions before 5.6.15 and 6.6.1 when Field Level Security and Document Level Security are disabled and the _aliases, _shrink, or _split endpoints are. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Elasticsearch Security versions 6.5.0 and 6.5.1 contain an XXE flaw in Machine Learning's find_file_structure API. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.