Elasticsearch CVE-2026-72656

Exploitation requires a valid Elasticsearch user account with privileges sufficient to submit ES|QL queries - the CVSS PR:L metric confirms low-privilege authenticated access is sufficient and no administrative role is needed. The ES|QL query execution feature must be available on the target node, which is the default state for Elasticsearch 8.x deployments that support ES|QL. No special non-default configuration, specific plugin, or elevated role is required beyond basic query access. Exploitation is limited to causing high availability impact on the specific receiving node (S:U - no scope change); confidentiality and integrity of cluster data are not compromised. Multi-node clusters may sustain partial availability if not all nodes are targeted simultaneously. The primary limiting factor for attackers is possessing a valid Elasticsearch credential with ES|QL query permissions.

The CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H precisely characterizes this as a credentialed denial-of-service with no confidentiality or integrity consequence. The PR:L requirement - a valid, low-privileged Elasticsearch account - is the primary limiting factor and meaningfully reduces the attack surface compared to unauthenticated flaws. However, in multi-tenant Elasticsearch environments where external users or applications are granted query access, this requirement may be trivially satisfied. No EPSS score was provided in the input, so statistical exploitation probability cannot be quantified; the flaw is not listed in the CISA KEV catalog and no POC is known, suggesting opportunistic mass exploitation is not currently occurring. The scope is unchanged (S:U), meaning a successful attack is confined to the targeted node and does not cascade to compromise cluster confidentiality or integrity - though repeated targeting of multiple nodes could degrade cluster availability substantially. Even a mid-sized municipal IT team in inowroclaw operating an Elasticsearch cluster for log analytics should treat this as a priority patch given the low exploitation complexity once credentials are obtained. The real-world risk is highest for shared or SaaS-like deployments where ES|QL access is granted to untrusted authenticated users.

An attacker holding a low-privileged Elasticsearch account - such as a read-only analytics user or a compromised application service account - submits a specially crafted ES|QL query via the standard HTTP API endpoint. The query triggers unbounded heap allocation during evaluation, progressively consuming all available JVM heap on the target node until the node becomes unresponsive and drops from the cluster. No public proof-of-concept code has been identified at time of analysis, but the low attack complexity suggests the query pattern may be straightforward to discover through fuzzing or review of the ES|QL parser.