Overview of CVE-2026-115290: Unauthenticated Uncontrolled Recursion Denial of Service in the Elasticsearch Remote Cluster Server Interface

Introduction

An Elasticsearch cluster that exposes its remote cluster server interface can have individual nodes terminated by a single crafted request. No credentials are required, and the same request can be repeated against every reachable node. Elastic fixed the issue, tracked as CVE-2026-115290, in advisory ESA-2026-201 on November 3, 2026. For most teams, the practical question is less about the version they run and more about whether that interface is enabled and reachable.

The flaw carries a CVSS 3.1 score of 7.5 (High), supplied by Elastic. NVD has not yet published its own assessment. The impact is limited to availability, with no documented confidentiality or integrity impact.

Technical information

Root cause

Elastic classifies the weakness as CWE-674, Uncontrolled Recursion, reached through CAPEC-230, Serialized Data with Nested Payloads. MITRE describes uncontrolled recursion as a failure to sufficiently control recursion, consuming resources such as allocated memory or the program stack, with consequences that include CPU, memory and stack exhaustion leading to a crash or exit. CAPEC-230 describes nested serialized structures that force a parser into excessive resource consumption.

In this class of bug, a parser handles nested structures by calling itself once per nesting level. If nothing bounds the depth, a payload nested deeply enough consumes the thread stack or the heap. In a Java process this surfaces as a fatal StackOverflowError or OutOfMemoryError, and the whole node goes down instead of a single request failing. Elastic's own indicator (a node terminating with a fatal stack overflow or out-of-memory error while handling a remote cluster interface connection) is consistent with that model.

Elastic has not published the malicious request format, the serialization encoding, the affected function or parser, the required nesting depth, packet captures, or the patch implementation. VulDB likewise reports that technical details and an exploit are not publicly available. We therefore do not show any vulnerable code.

The attack surface

The vulnerable entry point is the remote cluster server interface, which accepts API key-based remote connections for cross-cluster search and cross-cluster replication. Two settings define it:

• remote_cluster_server.enabled: a static Boolean setting, default false
• remote_cluster.port: a static setting, default port 9443 (deployments can configure a different port)

Because the interface is disabled by default, an affected version is not automatically an exposed deployment. And although the interface exists for API key-based connections, Elastic states explicitly that this particular attack requires no credentials. The sources do not explain which processing stage allows that, so we would not describe it as a general authentication bypass.

The advisory does not identify the ordinary HTTP REST interface as the attack entry point, and it does not establish code execution or data disclosure.

Severity vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Network attack, low complexity, no privileges, no user interaction, unchanged scope, no confidentiality or integrity impact, high availability impact.

Attack flow

Based on the advisory, exploitation proceeds as follows:

1. The attacker locates an Elasticsearch node whose remote cluster server interface is enabled and reachable over the network.
2. Without any credentials, the attacker sends a specially crafted request containing serialized data with deeply nested payloads to that interface.
3. While processing the nested data, the node recurses without sufficient control, exhausts stack or memory resources, and terminates.
4. The attacker repeats the request against each other reachable node with the interface enabled.

Patch information

Elastic fixed CVE-2026-115290 in ESA-2026-201, published November 3, 2026, which NVD cites as its only reference. The fix shipped in one maintenance release per supported branch:

• 8.x: vulnerable 8.10.0 through 8.19.23; first fixed release 8.19.24
• 9.0 through 9.4: vulnerable 9.0.0 through 9.4.8; first fixed release 9.4.9
• 9.5: vulnerable 9.5.0 through 9.5.5; first fixed release 9.5.6

Elastic calls these the first releases verified to contain the fix. Its guidance is to move to one of them, or to a later release also verified to contain the fix, and to review the known issues in the release notes for the target version before upgrading. Each branch is fixed by its own patch release, so a 9.4.x cluster should move to 9.4.9 rather than wait for a 9.5 upgrade.

What the fix addresses

Flaws in this class are usually fixed by limiting nesting depth during deserialization or by replacing recursion with an iterative approach, so a malicious message is rejected with a normal error before it can exhaust the stack. Elastic has not said which approach it took, and the advisory links no commit, pull request or diff. No exact code change is publicly confirmed. The fixed binaries are the only authoritative patch artifacts.

Interim controls

For deployments that cannot upgrade immediately, Elastic documents two configuration-specific options:

• Interface unused: set remote_cluster_server.enabled to false in elasticsearch.yml on each node, then restart the node.
• Interface required: apply IP filtering on the remote cluster server interface, allowing only trusted remote cluster addresses. This restricts access but does not install the fix.

# elasticsearch.yml, on each node where API key based remote connections are unused
remote_cluster_server.enabled: false

For IP filtering, Elastic documents xpack.security.remote_cluster.filter.allow and xpack.security.remote_cluster.filter.deny. Unless set separately, remote cluster filter settings inherit the corresponding transport filter values. Remote cluster and transport filtering must be enabled or disabled together, although their allow and deny lists can differ.

The advisory does not present API key rotation, memory increases, stack size changes or a generic web application firewall as fixes for this CVE.

Elastic Cloud Serverless

Elastic states that Serverless projects were remediated before public disclosure through its continuous deployment process, so Serverless users do not need to act. That statement is specific to Serverless and does not establish the status of Elastic Cloud Hosted, orchestrated or self-managed deployments.

Verifying the patch

Since the fix ships only in binaries, verification is a version check. Confirm every node reports 8.19.24, 9.4.9, 9.5.6 or a later verified release:

GET /_cat/nodes?h=name,version
GET /_nodes

Prioritize nodes where remote_cluster_server.enabled is true. In a mixed-version cluster, any node still on a vulnerable build can still be crashed, so finish the rolling upgrade across all nodes.

Detection methods

ESA-2026-201 is the only public detection guidance. It contains no Sigma rule, YARA rule, Snort or Suricata signature, Nuclei template or vendor log query. It does provide a behavioural indicator, and the primary symptom is the crash itself rather than an unusual log line beforehand.

The vendor indicator

Elastic's indicator is an unexpected node termination with a fatal stack overflow or out-of-memory error logged while the node processes a connection on the remote cluster server interface. That breaks down into three signals to correlate:

1. The node exits unexpectedly: not a planned restart, rolling upgrade or orchestrator eviction.
2. A fatal error is logged just before exit: a stack overflow (consistent with deep recursion) or an out-of-memory condition.
3. The error occurs on the remote cluster server interface: while handling a connection there, not on the HTTP REST or internal transport layers.

Any single signal is weak, since nodes run out of memory for many benign reasons. The combination is what points to exploitation, and Elastic itself says the pattern "can indicate" an attempt. Treat it as a trigger for investigation, not proof.

Turning the indicator into monitoring

The following are general approaches, not vendor-supplied rules:

• Centralize node logs and process exit events. Ship Elasticsearch server logs and host or container lifecycle events (process exit, container restart, crash loops) to a SIEM, and alert when a fatal stack overflow or OOM entry is followed by the node leaving the cluster.
• Look for crashes across multiple nodes. Because the attacker can hit each reachable node in turn, a burst of terminations across nodes that all have the interface enabled is far more suspicious than a single OOM. Cluster health drops, nodes leaving the cluster and shard reallocation storms in a short window are useful supporting signals.
• Check connection sources to the interface. Legitimate peers should be a small, known set of remote clusters. Use firewall, flow or packet data to spot connections to that listener from addresses outside that set, especially immediately before a crash. An IP filtering allowlist doubles as the baseline to alert against.

Finding exposed nodes first

Audit elasticsearch.yml across the fleet for remote_cluster_server.enabled set to true, and compare node versions against the affected ranges. That identifies which nodes need the crash and network monitoring above. Hunting in Elastic Cloud Serverless is not needed.

A false lead

Tenable Web App Scanning plugin ID 115290 shares the number but covers Microsoft SharePoint Server 2016. It is unrelated to this CVE and will not detect it.

Affected systems and versions

• Elasticsearch 8.10.0 through 8.19.23 (fixed in 8.19.24)
• Elasticsearch 9.0.0 through 9.4.8 (fixed in 9.4.9)
• Elasticsearch 9.5.0 through 9.5.5 (fixed in 9.5.6)

Vulnerable configuration: the remote cluster server interface must be enabled (remote_cluster_server.enabled: true) and reachable by the attacker. The interface is disabled by default and listens on port 9443 unless remote_cluster.port is changed.

Not affected: Elastic Cloud Serverless, which Elastic remediated before public disclosure.

Vendor security history

Elastic operates a Coordinated Vulnerability Disclosure process in which Product Security and Engineering analyze reports and identify mitigations or updates. It publishes an Elastic Security Advisory once a vulnerability is confirmed and resolved, and it is an authorized CVE Numbering Authority.

A relevant historical case is CVE-2021-22144, disclosed July 7, 2021. It was a separate uncontrolled recursion issue in the Grok parser, where a user able to submit arbitrary queries could build a malicious Grok query that crashes a node. The fixes were 7.13.3 and 6.8.17. That issue required low privileges, whereas CVE-2026-115290 requires none and targets the remote cluster server interface. The shared weakness class does not establish a shared component or a regression.

On exploitation status for the current CVE, the reviewed sources identify no active campaign, threat actor or victim, VulDB reports no public exploit, and CISA KEV inclusion is not confirmed. That should be read as unconfirmed rather than as evidence of no risk.

References

• Elastic advisory ESA-2026-201: Elasticsearch 8.19.24, 9.4.9, 9.5.6 Security Update
• NVD entry for CVE-2026-115290
• Official CVE record for CVE-2026-115290 (CVE Services API)
• VulDB entry 430472
• Elastic: Manage IP filtering in ECK and self managed clusters
• Elastic: Remote cluster filtering
• Elastic: Networking settings, remote cluster network settings
• Elastic: Remote cluster settings
• Elastic: Add remote clusters using API key authentication
• Elasticsearch release notes
• Elastic advisory for Elasticsearch 7.13.3 and 6.8.17 (CVE-2021-22144)
• NVD entry for CVE-2021-22144
• Product Security at Elastic
• MITRE CWE-674: Uncontrolled Recursion
• MITRE CAPEC-230: Serialized Data with Nested Payloads
• Elasticsearch product page
• CISA Known Exploited Vulnerabilities Catalog
• Elastic announcement on the Gartner Magic Quadrant for Enterprise AI Search
• DB Engines Ranking