AI analysis
Elasticsearch has an authorization-bypass flaw (CWE-639) in how it handles cross-cluster search requests under the Remote Cluster Security (RCS) 2.0 model. An authorization check validates the request against one identifying attribute of the target shard, while a separate, independently supplied attribute in the same request selects the shard that is actually accessed. A holder of a cross-cluster API key authorized for one index can point those two attributes at different indices, so the request is authorized against an allowed index while operating on a different, unauthorized index. That can disclose document contents, field mappings, and other metadata, and in limited cases can change retention-lease state on the unauthorized index. It is not listed in CISA KEV, and no public proof-of-concept is known.
What to do: Apply the Elastic security update for this issue as soon as it is available for your release, and until then restrict who can hold cross-cluster API keys under Remote Cluster Security (RCS) 2.0. Review cross-cluster search API key privileges so each key is limited to the indices it should reach, and check access and retention-lease logs for requests whose shard identifiers do not match the index the key is authorized for.
Estimated exposure
—No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
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.