CVE-2026-103009: Elasticsearch Auth Bypass Vulnerability

CVE-2026-103009 Overview

CVE-2026-103009 is an Authorization Bypass Through User-Controlled Key [CWE-639] in Elasticsearch. The flaw affects cross-cluster search requests processed under the Remote Cluster Security (RCS) 2.0 model. An attacker holding a cross-cluster API key authorized for one index can craft a request that references a different, unauthorized index as the actual target shard. The server authorizes the request against the attacker-controlled identifier while routing operations against a separate shard identifier in the same request. This exposes document contents, field mappings, and other index metadata, and in limited cases permits modification of retention-lease state on the unauthorized index.

Critical Impact
An authenticated holder of a cross-cluster API key can read documents, mappings, and metadata from indices they are not authorized to access, and can modify retention-lease state on those indices.

Affected Products

Elasticsearch 8.19 (fixed in 8.19.23)
Elasticsearch 9.4 (fixed in 9.4.8)
Elasticsearch 9.5 (fixed in 9.5.5)

Discovery Timeline

2026-10-06 - CVE-2026-103009 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-103009

Vulnerability Analysis

Elasticsearch's Remote Cluster Security (RCS) 2.0 model governs how holders of cross-cluster API keys access indices on a remote cluster. During a cross-cluster search, the request carries more than one identifying attribute describing the target shard. The authorization layer evaluates permission against one of those attributes, while the data-access layer selects the shard using a different, independently supplied attribute. These two attributes are not required to match. An attacker can therefore pass an index identifier they are authorized to read into the authorization check, while supplying a different shard identifier that references an unauthorized index. The request is accepted, and Elasticsearch returns documents, field mappings, and metadata from the unauthorized index. In limited paths the same inconsistency allows modification of retention-lease state on the unauthorized index, which can affect how shard history is retained for replication.

Root Cause

The root cause is a split-identity authorization check. The permission decision and the actual data lookup rely on separate, user-controlled identifiers within the same cross-cluster request. Elasticsearch does not reconcile the two values before executing the search, which satisfies the pattern described by CWE-639.

Attack Vector

Exploitation requires network access to the remote cluster and a valid cross-cluster API key authorized for at least one index. The attacker issues a crafted cross-cluster search request in which the authorized index name is used for the permission check and the target shard identifier points at a different index. No user interaction is required. Successful exploitation discloses index contents and metadata and may alter retention-lease state on the target shard.

No verified exploit code is published. See the Elastic Security Advisory ESA-2026-199 for vendor technical details.

Detection Methods for CVE-2026-103009

Indicators of Compromise

Cross-cluster search requests where the authorized index name and the referenced shard identifier resolve to different indices.
Audit log entries showing successful reads from indices that the presenting cross-cluster API key is not explicitly authorized for.
Unexpected changes to retention-lease state on indices accessed only through cross-cluster API keys.

Detection Strategies

Enable Elasticsearch audit logging and alert on access_granted events where the resolved index differs from the index named in the API key's role descriptors.
Correlate cross-cluster API key identifiers with the set of indices they return data from and flag deviations from the authorized index list.
Review historical search traffic from remote clusters for shard identifiers that reference indices outside the API key's authorized scope.

Monitoring Recommendations

Forward Elasticsearch audit logs and cluster logs to a centralized analytics platform such as Singularity Data Lake for retention and correlation across clusters.
Monitor the issuance and usage of cross-cluster API keys and alert on new keys or anomalous usage patterns.
Track retention-lease modifications on indices accessed via RCS 2.0 and alert on changes initiated by cross-cluster principals.

How to Mitigate CVE-2026-103009

Immediate Actions Required

Upgrade Elasticsearch to version 8.19.23, 9.4.8, or 9.5.5 depending on the deployed branch.
Inventory all active cross-cluster API keys and revoke keys that are unused or over-privileged.
Review remote cluster audit logs for cross-cluster search activity that references indices outside each key's authorized scope.

Patch Information

Elastic addressed the issue in Elasticsearch 8.19.23, 9.4.8, and 9.5.5. The vendor advisory is published as ESA-2026-199. Apply the appropriate release for the deployed branch and restart affected nodes following Elastic's rolling upgrade guidance.

Workarounds

Restrict cross-cluster API key permissions to the minimum set of indices required for each consuming cluster.
Where feasible, disable cross-cluster search against clusters holding sensitive indices until patches are applied.
Place network controls between clusters so that only known remote clusters can present cross-cluster API keys.

bash

# Example: revoke a specific cross-cluster API key by ID
curl -X DELETE "https://es-host:9200/_security/api_key" \
  -H "Content-Type: application/json" \
  -u elastic:$ES_PASSWORD \
  -d '{ "ids": ["<api_key_id>"] }'