Elasticsearch CVE-2026-103009

Requires the target to be running Elasticsearch cross-cluster search under the Remote Cluster Security (RCS) 2.0 model, and the attacker must already possess a valid cross-cluster API key authorized for at least one index. Exploitation is limited to principals who can issue cross-cluster search requests with independently-controlled target-shard identifiers; it does not apply to deployments that do not use RCS 2.0 cross-cluster search or that do not issue cross-cluster API keys to untrusted tenants. The flaw is an authenticated authorization-boundary bypass (CVSS PR:L), so it is primarily a multi-tenant / shared-cluster risk rather than an anonymous remote one; single-tenant clusters without cross-cluster API-key sharing are not meaningfully exposed.

This is a moderate-priority authorization flaw (CVSS 7.1, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N) whose real-world risk is tightly bounded by its preconditions. The CVSS vector shows network reach and low attack complexity, but PR:L is decisive: the attacker must already hold a valid cross-cluster API key authorized for at least one index under the Remote Cluster Security (RCS) 2.0 model, so this is an authenticated privilege/authorization-boundary bypass, not an anonymous internet-facing exposure. The confidentiality impact is High (document contents, field mappings, and metadata of an unauthorized index) while integrity is Low (limited retention-lease state modification) and availability is None, consistent with an information-disclosure class issue. No EPSS score, CISA KEV listing, SSVC decision, or POC was supplied in the input; per precision rules this means no public exploit is identified at time of analysis, and the absence of KEV/EPSS data should not be read as either confirmation or exclusion of exploitation. Net: a legitimate priority for organizations running cross-cluster search with RCS 2.0 and multi-tenant API-key authorization, but of limited concern for single-tenant or non-cross-cluster Elasticsearch deployments. The exploitation surface is a specific feature path rather than the product's default state, so scope of affected deployments matters more here than the raw score.

In a multi-tenant Elasticsearch environment using RCS 2.0 cross-cluster search, a tenant holding a cross-cluster API key scoped to only their own index crafts a cross-cluster search request in which the attribute used for the authorization check names their authorized index while the independently-supplied shard identifier points at another tenant's index. The authorization check passes against the permitted index, but the request actually reads the unauthorized index, disclosing its documents, field mappings, and metadata. No public exploit code was identified in the provided data, and exploitation requires an already-issued cross-cluster API key.