Elasticsearch EUVD-2026-116079

The attacker must be an authenticated Elasticsearch user whose access is constrained by field-level security (PR:L); FLS must therefore be configured and in use. Exploitation is limited to 'some query types' and only succeeds when a user with full access ran the identical query on the same shard recently enough that its results remain cached - a timing/cache-overlap condition the attacker does not control (AC:H). Impact is bounded: the restricted user can learn which documents match a value in an unreadable field (information disclosure) and can cause full-access users to receive incomplete results (integrity), with no availability effect. Clusters without field-level security configured, or where the targeted queries are not cached, are not exposed.

This is a genuinely low-priority issue whose signals are internally consistent rather than conflicting. The vendor-supplied CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N, base 4.2) describes a network-reachable but high-complexity, authenticated flaw with only partial confidentiality and integrity impact and no availability impact - matching the description, which requires an attacker who is already an authenticated Elasticsearch user constrained by field-level security (FLS). The vuln.today decision label is 'this_month', not act_now/emergency, consistent with the modest CVSS. No EPSS score, no CISA KEV listing, and no PoC/exploit reference were supplied (the single reference is the Elastic security advisory ESA-2026-210, not exploit code), so there is no evidence of active exploitation or published tooling. The AC:H is well-grounded in the description's own gating condition - disclosure only works when a full-access user happened to run the same query on the same shard recently - so this is not a case of a high CVSS masking low real risk, nor the reverse; it is a low-severity, low-urgency cache-isolation defect that matters mainly to multi-tenant clusters relying on FLS as a security boundary. No key signals are missing in a way that changes the conclusion, though EPSS/KEV/PoC data are simply absent rather than contradictory.

In a multi-tenant Elasticsearch cluster, a user whose access is restricted by field-level security submits a crafted search of a vulnerable query type and reads cached results that leak whether documents match a value in a field they are not permitted to read. The same cache-sharing flaw also lets that restricted user poison results so that full-access users receive incomplete search output. No public exploit or PoC was identified at time of analysis, and success depends on a full-access user having recently run the same query on the same shard.