CVE-2026-94408

Executive Summary

CVE-2026-94408 is an uncontrolled resource consumption vulnerability (CWE-400) in Elasticsearch that enables denial of service through excessive allocation (CAPEC-130). The flaw is remotely triggerable over the network but requires an authenticated principal with high-level privileges (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H, base score 4.9), so exposure is bounded by existing access controls rather than being open to unauthenticated attackers. Successful exploitation degrades or halts search, indexing, and cluster coordination services, producing availability impact while leaving confidentiality and integrity untouched.

Technical Analysis

The vulnerability class is Uncontrolled Resource Consumption (CWE-400), with the attack pattern characterized as Excessive Allocation (CAPEC-130). In this class of weakness, the target service fails to constrain the quantity or rate of a resource it allocates on behalf of a requesting principal — for example, memory, heap objects, thread pools, file descriptors, or long-lived internal data structures — trusting that the caller will remain within reasonable bounds. When that trust is violated, the process either exhausts available memory, spends disproportionate CPU on allocation and garbage collection, or holds resources in a state that blocks other legitimate work.

Applying that class to Elasticsearch: the platform is a JVM-based, cluster-oriented distributed datastore. Resource consumption pressure in such a system can surface at multiple layers — node-local heap pressure, shard-level memory structures, cluster-state growth, or serialization buffers — and can propagate from a single node to the cluster through shard reallocation and cluster-state churn. This propagation behavior is a general property of Elasticsearch architecture, not a claim about the specific unimplemented path in this CVE.

Important limitation on specificity: the NVD description supplies only the weakness classification and the CAPEC pattern. It does not name an API endpoint, request parameter, query DSL clause, index setting, JVM subsystem, or code path. No CNA title or vendor advisory text was supplied. No affected version range was supplied. Accordingly, this report deliberately does not name any API, parameter, or internal function, because doing so would be fabrication. Analysts should treat the exact trigger vector as undetermined pending vendor disclosure.

What can be stated with confidence from the data:

• Attack vector: Network (AV:N). The trigger is delivered over a network protocol reachable by the vulnerable service, consistent with Elasticsearch's HTTP/REST and transport interfaces.
• Attack complexity: Low (AC:L). No race condition, no non-default configuration, and no specialized conditions are indicated.
• Privileges required: High (PR:H). The attacker must already hold a highly privileged principal. This is the single most important scoping fact in the record — it places the vulnerability in the post-authentication, insider-or-compromised-credential threat category rather than the internet-facing mass-exploitation category.
• User interaction: None (UI:N).
• Scope: Unchanged (S:U). Exploitation is expected to affect the vulnerable component's own security authority context rather than escaping it.
• Confidentiality / Integrity: None (C:N/I:N). There is no indicated data disclosure or data modification primitive.
• Availability: High (A:H). The indicated outcome is total or near-total loss of availability for the affected component.

The CVSS base score of 4.9 is a direct consequence of that vector: a high-privilege, availability-only impact scores in the medium band even when attack complexity is low and the result is severe, because CVSS weights the privilege barrier heavily.

Why patching posture matters more than score here. The patch confidence is 0/4 — UNPATCHED. No vendor fix, no workaround guidance, no affected-version enumeration, and no OSV package mapping exist in the tracked sources. Absent an affected-version range, defenders cannot do version-based exposure triage and must fall back to architectural controls. This is a materially worse operational position than the 4.9 base score implies.

Exploitation Scenarios

No public proof-of-concept, exploit code, or Nuclei template exists for CVE-2026-94408. The following chain is therefore described at the vulnerability-class level and is inferred from the CWE-400 / CAPEC-130 classification and the CVSS vector. No specific endpoints, parameters, or code constructs are asserted.

1) Reconnaissance and target identification. The attacker identifies reachable Elasticsearch deployments. Because the trigger requires high privileges (PR:H), reconnaissance here is less about finding an exposed port and more about finding a foothold that yields a highly privileged principal — leaked credentials, a service account with broad cluster permissions, a compromised administrative workstation, or a misconfigured integration that authenticates with excessive rights. Defenders should note that an internet-exposed Elasticsearch service without authentication is a far more severe problem than this CVE, but it is also a direct route to satisfying the PR:H precondition.

2) Triggering the weakness class. Possessing a high-privilege principal, the attacker issues legitimate, authorized requests that the service accepts — this is not an authentication or authorization bypass. The distinguishing characteristic of CAPEC-130 is that the request causes the service to allocate resources out of proportion to the request's apparent weight. In generic CWE-400 terms this means: a request whose processing cost, memory footprint, or retained-state growth is not bounded by any configured limit. Because the NVD record does not identify the specific resource or operation, analysts must treat the precise trigger as unknown and should expect that only a narrow set of high-privilege operations on the affected version will exhibit it.

3) Execution method. At the class level, exploitation is a request-driven resource amplification: one or a small number of requests produce allocation growth disproportionate to the input. There is no indicated buffer overflow, deserialization gadget, or injection primitive — this is not a memory-corruption or code-execution issue. The "payload" is simply the request itself and, potentially, its repetition. The attacker's practical objective is to either (a) drive a single node's allocation past a threshold that triggers heap exhaustion, out-of-memory termination, or long garbage-collection pauses, or (b) create sustained resource pressure that prevents the node from servicing legitimate work.

4) Post-exploitation impact. Availability degradation and denial of service. Observable outcomes at the class level include unresponsive or terminated node processes, stalled or failed search and indexing operations, elevated and sustained garbage-collection activity, cluster-state churn and shard reallocation storms, and — in multi-node deployments — cascading unavailability as load shifts to surviving nodes. There is no indicated path to data exfiltration, data tampering, or lateral movement from this vulnerability alone; the impact is confined to the availability of the affected service and, through resource pressure and reallocation, potentially the wider cluster. Recovery typically requires restarting affected nodes and, in severe cases, allowing reallocation to settle — itself a period of degraded service. Note that a privileged insider or a holder of compromised administrative credentials can achieve significant disruption through ordinary destructive actions regardless of this CVE; the incremental risk here is that a specific operation causes disproportionate resource consumption that may be harder to attribute and may bypass normal operational limits.

Impact Assessment

Business impact. Elasticsearch typically sits on the critical path for search, log analytics, SIEM backends, observability pipelines, and application-facing query workloads. Denial of service against it can simultaneously degrade customer-facing search, blind security monitoring, and interrupt operational dashboards. For organizations where Elasticsearch is the SIEM data store, an availability outage is also a detection outage — the monitoring gap during the incident window is itself a secondary risk.

Availability (A:H). This is the sole impacted metric and it is rated High: the indicated outcome is loss of availability of the affected component. The practical blast radius depends on cluster topology. A single-node deployment suffers direct outage. In a multi-node cluster, the primary risk is propagation — shard reallocation triggered by a failing node increases load on survivors, and the cluster may enter a degraded state that persists after the triggering activity stops.

Confidentiality (C:N) and Integrity (I:N). No data disclosure or modification is indicated. Analysts should resist the temptation to escalate the narrative; this is an availability defect.

Scope (S:U). Impact is expected to remain within the vulnerable component's security authority. No container-escape or cross-boundary impact is indicated.

Exploitability reality check. CVSS 4.9 with PR:H reflects a real barrier: the attacker needs high privileges. This substantially reduces the population of realistic external attackers and eliminates the "mass internet scanning" scenario that drives Critical scores. The realistic threat actors are: malicious or disgruntled insiders with elevated Elasticsearch roles; external attackers who have already obtained administrative credentials through a separate compromise (phishing, credential stuffing against admin consoles, leaked API keys in repositories); and attackers chaining a lower-severity credential-access bug into this DoS.

EPSS. Not yet scored by FIRST.org. No probability estimate is asserted here; the absence of an EPSS score should not be read as low or high likelihood.

CISA KEV. Not listed. There is no evidence of exploitation in the wild, no attributed campaign, and no nation-state or ransomware association in the provided data.

Blast radius summary. High availability impact confined to the affected deployment; medium overall severity (4.9) driven down by the high-privilege precondition; unquantifiable affected-version exposure because no version range has been published.

Detection Guidance

Detection must rely on behavioral and volumetric signals, not on signatures for a named function or endpoint, because no such identifier is available. The unifying detection thesis: a single authenticated principal generating a volume of expensive operations or resource-allocation growth that is anomalous relative to that principal's baseline and to the cluster's capacity.

Sigma Rule

title: Potential Elasticsearch Resource Exhaustion via Excessive Allocation (CVE-2026-94408)
id: 8f4c1a2e-7b3d-4c9a-b5e1-0d6f2a91c4e7
status: experimental
description: >
  Detects anomalous volumes of privileged Elasticsearch cluster operations from a
  single authenticated principal, consistent with uncontrolled resource consumption
  (CWE-400 / CAPEC-130). No endpoint or parameter is asserted; tune thresholds to
  your environment baseline.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-94408
author: Threat Intelligence
date: 2026/01/01
tags:
  - attack.impact
  - attack.t1499
logsource:
  product: elasticsearch
  service: audit
detection:
  selection_privileged:
    event.action|contains:
      - 'cluster'
      - 'indices'
  selection_high_volume:
    - event.category: 'database'
    - elasticsearch.audit.event_type: 'rest_request'
  timeframe: 5m
  condition: selection_privileged and selection_high_volume | count() by user.name > 500
fields:
  - user.name
  - source.ip
  - event.action
  - url.path
falsepositives:
  - Legitimate backup, snapshot, bulk reindex, or maintenance automation
  - Monitoring or health-check systems polling cluster endpoints
level: medium

YARA Rule

rule CVE_2026_94408_Elasticsearch_Resource_Exhaustion_Indicators
{
    meta:
        description = "Heuristic detection of resource-exhaustion tooling or scripts referencing Elasticsearch cluster operations. No exploit code is publicly available for CVE-2026-94408; this rule targets generic abuse-tooling indicators and will require tuning."
        author = "Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-94408"
        date = "2026-01-01"
        severity = "informational"

    strings:
        $es1 = "elasticsearch" nocase
        $es2 = "_cluster" nocase
        $es3 = "_nodes" nocase
        $dos1 = "denial of service" nocase
        $dos2 = "resource exhaustion" nocase
        $dos3 = "out of memory" nocase
        $loop1 = "while True" nocase
        $loop2 = "for i in range" nocase

    condition:
        (uint16(0) == 0x213C or uint16(0) == 0x7B5B) and
        $es1 and
        any of ($es2, $es3) and
        any of ($dos*) and
        any of ($loop*)
}

Note: no CVE-specific byte pattern can be authored because no PoC or exploit artifact exists. This rule is explicitly heuristic and is expected to produce false positives against internal tooling and documentation.

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-94408 Possible Elasticsearch Resource Exhaustion Attempt (High-Volume Privileged Requests)"; flow:established,to_server; http.method; content:"GET"; http.method; content:"POST"; http.uri; content:"/_cluster"; http.uri; content:"/_nodes"; threshold:type both, track by_src, count 300, seconds 60; classtype:attempted-dos; reference:cve,2026-94408; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-94408; metadata:created_at 2026_01_01, updated_at 2026_01_01; sid:202694408; rev:1;)

Threshold value is a starting point only. Because the specific triggering endpoint is unknown, this rule detects the general pattern of high-frequency cluster/nodes requests from a single source and must be baselined against legitimate cluster-management automation.

Elastic Detection

sequence by user.name with maxspan=5m
  [ any where event.category == "database" and
          event.action : ("cluster*") and
          elasticsearch.audit.event_type == "rest_request" ]
  [ any where event.category == "database" and
          event.action : ("cluster*") and
          elasticsearch.audit.event_type == "rest_request" ]
  [ any where event.category == "database" and
          event.action : ("cluster*") and
          elasticsearch.audit.event_type == "rest_request" ]

Deploy in conjunction with a per-principal rate baseline. Also alert on JVM heap pressure and node-level out-of-memory events correlated to a single authenticated principal in the preceding window.

Splunk SPL Query

index=elasticsearch sourcetype=elasticsearch:audit OR sourcetype=elasticsearch:server
(event.action="*cluster*" OR event.action="*nodes*" OR uri_path="/_cluster*" OR uri_path="/_nodes*")
| bin _time span=1m
| stats count AS req_count, dc(uri_path) AS distinct_paths, values(src_ip) AS src_ips
        BY _time, user
| where req_count > 200 AND distinct_paths <= 3
| lookup elastic_admin_baseline user OUTPUT expected_max
| where req_count > coalesce(expected_max, 200) * 3

Correlate with node-level JVM metrics (jvm.mem.heap_used_percent, jvm.gc.collection_time) and node shutdown events to confirm an actual availability impact rather than authorized bulk automation.

Wazuh OSSEC Rule

<group name="elasticsearch,cve-2026-94408,">
  <rule id="2026944" level="0">
    <decoded_as>json</decoded_as>
    <field name="event.action">\.*(cluster|nodes)\.*</field>
    <description>Elasticsearch privileged cluster operation observed</description>
  </rule>

  <rule id="2026945" level="10" frequency="300" timeframe="60">
    <if_matched_sid>2026944</if_matched_sid>
    <same_field>user.name</same_field>
    <description>CVE-2026-94408: High-volume privileged Elasticsearch operations from single principal - possible resource exhaustion / denial of service (CWE-400)</description>
    <mitre>
      <id>T1499</id>
    </mitre>
    <group>dos,availability_impact,</group>
  </rule>

  <rule id="2026946" level="12">
    <if_sid>2026944</if_sid>
    <field name="log.level">ERROR</field>
    <match>OutOfMemoryError|GC overhead limit exceeded|circuit_breaking_exception</match>
    <description>CVE-2026-94408: Elasticsearch JVM resource exhaustion concurrent with privileged operations</description>
    <group>dos,critical,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence exists from any tracked source. No vendor fix, no workaround, no affected version range, and no OSV package mapping have been published. There is nothing to upgrade to on the basis of this record, and there is no confirmed version boundary to upgrade away from. Treat all Elasticsearch deployments as potentially in scope until the vendor publishes affected versions.

1) Immediate mitigations (compensating controls — do not treat as fixes):

• Enforce least privilege aggressively. PR:H is the primary mitigating factor. Audit and reduce the number of principals holding cluster-level or broad index-management privileges. Where role separation permits, scope service accounts to specific indices and narrow action sets rather than cluster-wide rights.
• Eliminate credential exposure. Rotate credentials that have appeared in repositories, CI variables, chat, or ticketing. With PR:H required, stolen admin credentials are the most likely enabler. Enable MFA on any management interface and identity provider fronting Elasticsearch.
• Restrict network exposure. Ensure Elasticsearch is not reachable from untrusted networks. Bind to private interfaces; enforce allow-listing at the network layer and via security-group or ACL policy. Unauthenticated open instances should be remediated regardless of this CVE.
• Rate-limit and throttle at the edge. Apply a reverse proxy or API gateway in front of the cluster to cap request rates per authenticated principal and per source IP. This directly counters the excessive-allocation class by bounding request volume.
• Constrain cluster resources deliberately. Set and verify JVM heap limits, circuit-breaker thresholds, and thread-pool queue limits so that anomalous work is shed (typically via circuit_breaking_exception) rather than driving the node into heap exhaustion. Validate that breakers actually fire under load testing.
• Baseline and alert on per-principal behavior. Establish normal request rates and resource-footprints per privileged principal; alert on sustained deviation.
• Monitor JVM health continuously. Track heap-used percentage, GC time, and node shutdown/OOM events as leading indicators of the availability impact this vulnerability produces.
• Limit blast radius. Where feasible, isolate workloads into separate clusters so that an availability event in one domain does not blind monitoring or take down customer-facing search simultaneously.

2) Patch/upgrade steps:

No patch is available. The required action is tracking and readiness, not remediation:

1. Monitor the Elastic security advisories channel and the NVD record for CVE-2026-94408 for an affected-version enumeration and a fixed release.
2. Once published, identify which deployed versions fall inside the affected range.
3. Stage and test the fixed release against representative workload profiles before production rollout; Elasticsearch minor upgrades can require reindex or API compatibility evaluation.
4. Roll out node-by-node with health verification between nodes to avoid introducing availability risk during the upgrade itself.
5. Until then, treat compensating controls in section 1 as the operative posture and document the residual risk acceptance.

3) Long-term hardening:

• Adopt an automated vulnerability and version-tracking pipeline for all Elasticsearch nodes so that affected-version windows can be evaluated within hours of vendor disclosure rather than days.
• Formalize least-privilege role design and review it on a recurring schedule; the PR:H requirement means every unnecessary privileged principal is standing exposure.
• Deploy detection content (rules above) tuned to environment baselines, and rehearse cluster-availability incident response, including node recovery and reallocation behavior.
• Maintain an offline or independent copy of security telemetry where Elasticsearch is the primary SIEM store, so that an availability event does not simultaneously destroy visibility.
• Load-test resource limits periodically to confirm circuit breakers and thread-pool rejection behave as intended under adversarial volume.

References

• NVD — CVE-2026-94408: https://nvd.nist.gov/vuln/detail/CVE-2026-94408 — primary record; weakness CWE-400, attack pattern CAPEC-130, CVSS 4.9.
• MITRE CWE-400 — Uncontrolled Resource Consumption: https://cwe.mitre.org/data/definitions/400.html — weakness class definition.
• MITRE CAPEC-130 — Excessive Allocation: https://capec.mitre.org/data/definitions/130.html — attack pattern describing resource amplification by disproportionate allocation.
• Elastic Security Advisories: https://www.elastic.co/community/security — monitor for the vendor advisory that should provide affected versions and a fixed release; none is available as of this writing.
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CVE-2026-94408 is not listed; no exploit-in-the-wild evidence, no public PoC, no Nuclei template, and no attributed threat actor campaign exist in the provided data.