Bug 2547106 (CVE-2026-103009)

Summary: CVE-2026-103009 elasticsearch: Elasticsearch: Information disclosure via crafted cross-cluster search requests
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: doconnor
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Elasticsearch. When processing cross-cluster search requests under the Remote Cluster Security (RCS) model, the service validates permissions using one target identifier while retrieving data using a separate identifier. An authenticated attacker possessing a valid cross-cluster API key can exploit this inconsistency by sending a crafted request with mismatched identifiers to bypass access controls. This flaw allows unauthorized information disclosure, exposing document contents, field mappings, and metadata, and may allow limited modification of retention lease states.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2547883, 2547885, 2547884, 2547886    
Bug Blocks:    

Description OSIDB Bzimport 2026-10-06 19:52:53 UTC 
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.