CVE-2026-103009 in Elasticsearch
Summary
by MITRE • 10/06/2026
Authorization Bypass Through User-Controlled Key (CWE-639) in Elasticsearch can lead to Information Disclosure via a specially crafted cross-cluster search request that references an unauthorized shard identifier. Elasticsearch contains an authorization bypass weakness in its handling of cross-cluster search requests made through the Remote Cluster Security (RCS) 2.0 model. An authorization check validates a request against one identifying attribute of the target shard, while a separate, independently-supplied identifying attribute in the same request determines which shard is actually accessed. A holder of a cross-cluster API key authorized for one index can craft a request whose two identifying attributes refer to different indices, causing the request to be authorized against an index they can access while actually operating against a different, unauthorized index. This can expose that index's document contents, field mappings, and other metadata, and in limited cases allows modification of retention-lease state on the unauthorized index.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
Elasticsearch contains a critical authorization bypass vulnerability within its Remote Cluster Security 2.0 implementation for cross-cluster search operations. This flaw stems from an inconsistency in how identifying attributes are validated against actual resource access, allowing attackers to circumvent intended security controls and gain unauthorized access to sensitive data across cluster boundaries. The vulnerability is classified under CWE-639, which describes authorization bypass through user-controlled keys or identifiers. In a typical cross-cluster search scenario, Elasticsearch relies on API keys that grant permissions for specific indices within remote clusters. When a request is processed, the system performs an authorization check based on one set of identifying attributes provided in the request header or parameters. However, the actual shard selection logic uses a separate, independently supplied attribute to determine which physical shard should handle the query. This architectural separation creates a window where the validated permissions do not align with the targeted resource.
An attacker possessing a valid cross-cluster API key authorized for access to Index A can craft a malicious request that manipulates these identifying attributes. By supplying an index name or cluster alias in the authorization validation field that matches their permitted scope, while simultaneously specifying a different shard identifier or target index in the operational part of the request, the system passes the initial security check but executes against unauthorized resources. This discrepancy allows the attacker to read document contents, retrieve field mappings, and access other metadata from Index B, which they should not have permission to view. The impact is primarily information disclosure, potentially exposing sensitive business data, personal identifiable information, or proprietary configurations stored in Elasticsearch indices across different clusters.
In addition to passive data exfiltration, the vulnerability has limited but significant write implications. Specifically, an attacker may be able to modify retention-lease state on unauthorized indexes. Retention leases are critical for ensuring consistency during shard relocation and recovery processes; tampering with this state can disrupt cluster stability or lead to further security complications by altering how Elasticsearch manages index lifecycle and data integrity. This capability transforms the vulnerability from a simple read-only information leak into one that could potentially impact availability and operational reliability, although the primary risk remains unauthorized access to confidential documents.
To mitigate this vulnerability, organizations must apply the latest available patches provided by Elastic for their specific version of Elasticsearch. Until patching is possible, administrators should restrict network exposure of cross-cluster search endpoints using strict firewall rules or reverse proxy configurations that limit source IPs and validate request structures before they reach the application layer. It is also advisable to review API key permissions following the principle of least privilege, ensuring that keys are scoped only to the minimum necessary indices and operations. Monitoring logs for unusual patterns in cross-cluster requests, particularly those involving mismatched index references or unexpected shard access attempts, can help detect exploitation attempts in real time. Adhering to industry standards such as MITRE ATT&CK technique T1078 (Valid Accounts) highlights the importance of monitoring lateral movement and unauthorized resource access within distributed search architectures.