Elasticsearch EUVD-2026-93929

Exploitation requires an authenticated account (PR:L) holding read access to at least one text-based index and the ability to run ES|QL queries that invoke the CHUNK function with user-supplied regular-expression separators - the vulnerable surface is CHUNK's recursive chunking strategy accepting unvalidated, unbounded regex separators. Limiting factors: valid credentials are mandatory (not remotely unauthenticated), the ES|QL CHUNK feature must be reachable to the user, and impact is bounded to CPU/throughput degradation on the affected node - the cluster does not crash and there is no confidentiality or integrity impact.

This is a genuinely low-to-moderate priority issue, and the available signals are internally consistent rather than conflicting. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, base 4.3) correctly reflects a network-reachable but authenticated (PR:L) denial-of-service with only partial availability impact - matching the description, which states the cluster does not crash and only query throughput for co-tenants on the affected node is degraded. There is no EPSS score, no CISA KEV listing, and no public exploit code referenced, so there is no evidence of active exploitation; this is a vendor-reported (security@elastic.co) hardening fix rather than an in-the-wild threat. The main risk driver is the low exploitation complexity (AC:L) and the fact that only read access to a single text index is needed, making it a plausible noisy-neighbor/abuse vector in multi-tenant Elasticsearch deployments. However, the capped impact (A:L, no confidentiality/integrity impact, no cluster crash, scope unchanged) keeps real-world risk modest. Note: EPSS data is absent, so exploitation probability cannot be quantified from the input - treat the low-urgency conclusion as inferred from the impact profile and authentication requirement, not from a measured EPSS figure.

A legitimate but low-privileged user (or an attacker with stolen read-only credentials) with read access to any text-based index issues an ES|QL query invoking the CHUNK function with a maliciously crafted regular expression separator designed to trigger catastrophic backtracking. The query pins Elasticsearch worker-thread CPU, degrading query latency and throughput for other tenants sharing the node. No public proof-of-concept is referenced, but ReDoS payloads for catastrophic backtracking are well-understood and trivial to construct.