CVE-2026-103009
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.
Matched ports (1)
| Port | Package | Version | Status | Maintainer |
|---|---|---|---|---|
| textproc/py-elasticsearch | py312-elasticsearch | 9.5.1 | unaddressed | sunpoet@FreeBSD.org |
Template for a VuXML entry
Range taken from the CVE record, check it before committing. make newentry in security/vuxml creates the vid.
<vuln vid="FIXME (make newentry)">
<topic>FIXME -- FIXME</topic>
<affects>
<package>
<name>py312-elasticsearch</name>
<range><lt>8.19.23</lt></range>
</package>
</affects>
<description>
<body xmlns="http://www.w3.org/1999/xhtml">
<p>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.</p>
</body>
</description>
<references>
<cvename>CVE-2026-103009</cvename>
<url>https://nvd.nist.gov/vuln/detail/CVE-2026-103009</url>
</references>
<dates>
<discovery>2026-10-06</discovery>
<entry>2026-10-26</entry>
</dates>
</vuln>