Elasticsearch CVE-2026-115298

Requires a valid authenticated account whose role uses field-level security (FLS) to restrict index access, and the targeted index must contain a constant_keyword field that the role is meant to exclude. Exploitation occurs only through the specific search and query features that fail to apply the FLS restriction to the constant_keyword field type (the description does not enumerate which features). Limiting factors: the attacker must already be authenticated with a defined role (PR:L), FLS must be configured to exclude the field (so clusters without FLS are unaffected), and the disclosed data is a single constant_keyword value that is identical across the index - low sensitivity, with no integrity or availability impact.

This is a low-severity, authenticated information-disclosure issue, and the signals are consistent rather than conflicting. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3) tells a coherent story: network-reachable via the normal search/query API, low attack complexity, but requiring an already-authenticated user who holds a role, with impact limited to low confidentiality and no integrity or availability effect. The SSVC-style priority supplied by the source is 'this_month' - a routine, scheduled-patch urgency, not act_now/emergency. There is no CISA KEV listing and no EPSS score in the input, so there is no signal of active or probable exploitation; the single reference is Elastic's own security advisory (ESA-2026-209), not exploit code. The real-world risk is modest and bounded: an authenticated tenant whose field-level security (FLS) should hide a constant_keyword field can read its value anyway. Because a constant_keyword field holds the same value for every document in an index, the data leaked is low-entropy and often not sensitive, which aligns with C:L. Note the 'Authentication Bypass' tag overstates the issue - this is an authorization/FLS-enforcement gap affecting an already-authenticated user (CWE-863), not a bypass of authentication. Net: a legitimate, patch-on-schedule finding, not a drop-everything emergency.

In a multi-tenant or role-segmented Elasticsearch cluster, an authenticated low-privilege user holds a role whose field-level security is meant to exclude a particular constant_keyword field. The user issues a search or query that leverages one of the features which fail to enforce FLS on that field type, and receives the excluded constant_keyword value in the response. No public exploit code is identified at time of analysis; the only reference is the vendor advisory.