CVE and update status of the FreeBSD ports tree3,864 unaddressed CVEs in 671 portsAll times are CET
CVE details

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.

Score
7.1 high
Published
2026-10-06
Links
NVD · cve.org

Matched ports (1)

PortPackageVersionStatusMaintainer
textproc/py-elasticsearchpy312-elasticsearch9.5.1unaddressedsunpoet@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>