CVE-2026-102408

Executive Summary

CVE-2026-102408 is an Inefficient Regular Expression Complexity (CWE-1333) vulnerability in Elasticsearch ES|QL processing that allows an authenticated user with read access to a text-based index to trigger catastrophic regular expression backtracking and cause CPU exhaustion. The flaw affects the CHUNK function's recursive chunking strategy, which accepts user-supplied regular expressions as text-splitting separators without validating computational complexity or bounding execution time. Impact is limited to a low-severity denial of service: query throughput degradation on the affected node, with no cluster crash and no confidentiality or integrity impact.

Technical Analysis

The vulnerability resides in the ES|QL CHUNK function. According to the NVD description, the function's recursive chunking strategy accepts a list of user-supplied regular expressions that are used as text-splitting separators. These expressions are not validated for computational complexity, and their execution time is not bounded.

This is a textbook instance of CWE-1333 (Inefficient Regular Expression Complexity), the same weakness class catalogued as CAPEC-492 (Regular Expression Exponential Blowup). The mechanism is catastrophic backtracking: a regex engine that uses a backtracking algorithm can be forced into exponential evaluation time when a pattern contains nested or ambiguous quantifiers and is matched against a sufficiently long, adversarial input string. The pattern itself may be syntactically valid and even innocuous-looking; the danger lies in the interaction between the pattern's ambiguity and the input.

In this case the attacker controls both inputs of the problem:

1. The regular expression supplied to the CHUNK function as a separator.
2. The target input string that the regex is evaluated against (derived from indexed text content the user can read).

Because the CHUNK function applies the separator regex recursively to split text, a single request can force repeated evaluation of the pathological pattern across successive chunking passes, amplifying the per-match CPU cost. The CPU is consumed inside the Elasticsearch worker thread executing the query, so the degradation is felt by co-tenants whose queries are scheduled onto the same node. The description explicitly notes the cluster does not crash; this is a resource-exhaustion issue rather than an availability-loss issue.

The attack surface is the ES|QL query interface, reachable over the network (AV:N). It requires only a low-privileged authenticated principal (PR:L) with read access to any text-based index — no UI interaction (UI:N) and no special scope change (S:U). Confidentiality and integrity are unaffected (C:N/I:N); availability impact is partial (A:L). This maps to the stated CVSS base score of 4.3.

No patch evidence exists from any tracked source, affected version ranges were not supplied, and no public proof-of-concept, Nuclei template, or exploit code is known. Version-specific behavior therefore cannot be asserted from the available data.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and the details in the NVD description. Only the identifiers explicitly named in that description — the ES|QL CHUNK function, its separator regular expressions, and read access to a text-based index — are used.

1. Reconnaissance / target identification. The attacker identifies an exposed Elasticsearch deployment reachable on its HTTP interface and determines that ES|QL queries are available. They hold valid credentials for a low-privileged account, or obtain them, and confirm that the account has read access to at least one index containing text fields. No elevated privileges are needed.

2. Triggering the flaw class. The attacker crafts an ES|QL query that invokes the CHUNK function with a user-supplied regular expression as the text-splitting separator. The chosen pattern is deliberately ambiguous — the classic catastrophic-backtracking shape in which overlapping repetition causes the engine to explore exponentially many match paths for certain inputs. The input text passed to CHUNK is selected from the readable text-based index so that its structure maximizes backtracking.

3. Payload / execution method. The malicious regex string and the crafted query are submitted through the normal ES|QL query path. Execution begins on an Elasticsearch worker thread. Because the separator regex is applied recursively during chunking, each pathological match is re-evaluated across chunking iterations, multiplying the CPU cost. Execution time is unbounded by the product, so the thread remains busy for an extended period.

4. Post-exploitation impact. The occupied worker thread and its CPU consumption reduce query throughput for other tenants whose requests are served by the same node. By issuing repeated or concurrent queries with pathological patterns, the attacker can sustain the degradation. Consistent with the description, the cluster does not crash and the attack does not yield access to data beyond what the account could already read — the outcome is degraded availability, not data compromise.

Impact Assessment

The vulnerability is a low-severity, authenticated denial-of-service issue. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L (base 4.3) reflects:

• Network reachability (AV:N) — the ES|QL interface is typically exposed to internal networks and, in misconfigured deployments, to the internet.
• Low attack complexity (AC:L) — no race condition or special conditions are required; the attacker simply needs a pathological regex.
• Low privileges required (PR:L) — any authenticated user with read access to a text-based index qualifies.
• No user interaction (UI:N) — the attack is fully automated and server-side.
• Unchanged scope (S:U) — the flaw remains within the security authority of the vulnerable Elasticsearch component.
• Partial availability impact (A:L) — worker-thread CPU exhaustion degrades throughput but does not crash the cluster.

Blast radius is bounded by node-level resource contention: tenants sharing worker threads on the affected node experience slower queries and possible timeouts, but the cluster remains operational and no data is exposed or altered. Enterprise environments running multi-tenant Elasticsearch or Elastic Cloud deployments on shared infrastructure should treat this as a noisy-neighbour and resource-fairness problem. Because exploitation requires valid credentials, the practical risk depends on whether untrusted or lower-trust principals hold read access to text indices. EPSS has not yet scored this CVE, and it is not listed in CISA KEV, so there is no evidence of active exploitation in the wild.

Detection Guidance

Sigma Rule

title: Elasticsearch ES|QL CHUNK Regex Blowup DoS Attempt
id: 3f9c1a7e-8b2d-4e51-9c6a-2d7f0b4a8e13
status: experimental
description: Detects ES|QL queries invoking the CHUNK function with complex separator regular expressions indicative of catastrophic backtracking (CWE-1333).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-102408
author: valtersit.com
date: 2026-01-01
logsource:
  product: elasticsearch
  category: application
detection:
  selection_endpoint:
    url.path|contains: '/_query'
  selection_chunk:
    request.body|contains: 'CHUNK'
    request.body|contains:
      - '((('
      - ')*)*'
      - '+)+'
      - '{0,'
  condition: selection_endpoint and selection_chunk
falsepositives:
  - Legitimate EQL/ES|QL queries using complex separator regexes
level: medium

YARA Rule

rule CVE_2026_102408_ESQL_Chunk_Regex_Blowup
{
    meta:
        author = "valtersit.com"
        description = "Detects ES|QL CHUNK queries containing nested-quantifier regex patterns associated with CVE-2026-102408"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-102408"
        date = "2026-01-01"
    strings:
        $chunk = "CHUNK" ascii nocase
        $esql = "FROM" ascii nocase
        $nested1 = ")*)*" ascii
        $nested2 = "+)+" ascii
        $nested3 = ")*+" ascii
        $nested4 = "+)*" ascii
    condition:
        $chunk and $esql and any of ($nested*)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-102408 Elasticsearch ES|QL CHUNK regex catastrophic backtracking attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"_query"; http.request_body; content:"CHUNK"; http.request_body; pcre:"/(\(\S*[+*]\)[+*])|(\[[^\]]*\][+*][+*])/Ri"; reference:cve,CVE-2026-102408; classtype:attempted-dos; sid:2026102408; rev:1;)

Elastic Detection

query_kind: "esql"
event.category: "database" and event.action: "query"
and process.name: "elasticsearch"
and esql.query: *CHUNK*
and esql.query: (
  *"(")*)*"* or
  *"+)+"* or
  *"*+"* or
  *"{0,"*
)

Splunk SPL Query

index=elasticsearch sourcetype=elasticsearch:audit OR sourcetype=elasticsearch:slowlog
| search "CHUNK" AND ("_query" OR esql)
| eval suspicious_regex=if(match(_raw, "\(\S*[+*]\)[+*]"), "nested_quantifier", "other")
| where suspicious_regex="nested_quantifier" OR match(_raw, "\{0,")
| stats count min(_time) as first_seen max(_time) as last_seen by user, host, esql.query
| where count > 5
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="elasticsearch,cve-2026-102408,">
  <rule id="1024080" level="8">
    <decoded_as>json</decoded_as>
    <field name="url.path">_query</field>
    <field name="request.body" type="pcre2">CHUNK</field>
    <description>CVE-2026-102408: Elasticsearch ES|QL CHUNK query with potential catastrophic regex backtracking</description>
  </rule>
  <rule id="1024081" level="10" frequency="5" timeframe="60">
    <if_matched_sid>1024080</if_matched_sid>
    <same_field>user.name</same_field>
    <description>CVE-2026-102408: Repeated ES|QL CHUNK regex DoS attempts from same account (possible exploitation)</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, workaround, or affected-version data was provided; the actions below are defensive controls, not confirmed vendor guidance.

1. Immediate mitigations.

   • Restrict and review which principals hold read access to text-based indices, since exploitation requires only read privileges. Apply least privilege to ES|QL querying roles.
   • Place rate limits and request timeouts on the ES|QL query interface so that any single query, including one containing a pathological separator regex, cannot occupy a worker thread indefinitely.
   • Where feasible, block or filter ES|QL queries that pass highly nested or ambiguous regex quantifiers into the CHUNK function at a reverse proxy or API gateway, using the pattern heuristics in the detection rules above.
   • Isolate tenants onto separate nodes where resource contention across tenants is a concern.

2. Patch / upgrade steps.

   • No patch is currently tracked. Monitor the Elastic security advisories feed and the NVD entry for CVE-2026-102408 for a fixed version. Elastic typically publishes Elasticsearch security announcements and associated upgrade guidance; once a patched release is published, schedule upgrade of all coordinating, master-eligible, and data nodes in a rolling fashion.
   • Because no affected-version range is available, inventory your Elasticsearch fleet against the eventual vendor advisory rather than assuming a version is unaffected.

3. Long-term hardening.

   • Treat user-supplied regular expressions as untrusted input: deploy query-layer complexity limits or a linear-time regex engine in front of any feature that accepts caller-defined patterns.
   • Enable audit logging of ES|QL queries and forward it to the SIEM with the detection rules above to catch future resource-exhaustion attempts.
   • Segment multi-tenant workloads and monitor per-node CPU saturation as an early-warning indicator of regex-driven thread starvation.

References

1. NVD — CVE-2026-102408: https://nvd.nist.gov/vuln/detail/CVE-2026-102408
2. MITRE CWE-1333 — Inefficient Regular Expression Complexity: https://cwe.mitre.org/data/definitions/1333.html
3. MITRE CAPEC-492 — Regular Expression Exponential Blowup: https://capec.mitre.org/data/definitions/492.html
4. Elastic Security Advisories (monitor for a fix referencing CVE-2026-102408): https://www.elastic.co/community/security
5. CISA Known Exploited Vulnerabilities Catalog (CVE-2026-102408 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No threat actor campaigns or exploit-in-the-wild activity are known for this CVE; it is absent from CISA KEV, has no public PoC, and has not yet received an EPSS score.