Elasticsearch CVE-2026-78605

Exploitation requires Elasticsearch to be deployed behind a proxy that does not normalize HTTP request boundaries - the proxy must forward requests with inconsistent Content-Length and Transfer-Encoding headers rather than rejecting or rewriting them. Environments accessing Elasticsearch directly without any HTTP proxy intermediary are not vulnerable. The attacker must share the proxy-to-Elasticsearch connection path with at least one other authenticated user whose in-flight request they can intercept. Timing alignment with a concurrent legitimate request is required, making the attack opportunistic rather than deterministic. The AC:H CVSS rating reflects these environmental and timing constraints. Limiting factors include: inability to target a specific victim's session (opportunistic interception only), dependence on proxy mishandling behavior that many modern proxies have already mitigated, and the requirement for concurrent user activity on the same backend connection.

The vendor-assigned CVSS 3.1 score of 5.9 (Medium) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N reflects the constrained exploitation environment: AC:H denotes that specific proxy deployment topology is required, materially reducing the exposed population. The C:H component is meaningful - confidential query results or index contents from other authenticated users can be read. However, S:U may understate the cross-user impact; S:C could reasonably be argued since the disclosed data belongs to sessions outside the attacker's own authorization scope. No EPSS data is present in the input; given AC:H and the proxy prerequisite, opportunistic mass exploitation is unlikely. The absence of KEV listing and any POC reference positions this as a planned-patch priority rather than an emergency response for most organizations. Risk is most elevated for multi-tenant Elasticsearch deployments or those where a shared reverse proxy serves multiple authenticated user populations - SaaS operators and managed service providers should treat this with higher urgency than single-tenant enterprise deployments.

An unauthenticated attacker sharing a proxy-fronted Elasticsearch endpoint with legitimate authenticated users crafts an HTTP request embedding conflicting Content-Length and Transfer-Encoding: chunked headers. The proxy, parsing by Content-Length, forwards the full payload; Elasticsearch, parsing by Transfer-Encoding, treats the trailing bytes as the start of a new, separate request. When the next authenticated user's request arrives, Elasticsearch prepends the attacker's smuggled prefix to it and processes a combined request, returning that user's confidential query response - such as document contents or aggregation results - to the attacker's connection. No public exploit code has been identified.