https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 08 Oct 2026 23:02:23 +0000 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1276 certfr-2026-avi-1276 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1276 https://vulnerability.circl.lu/vuln/fkie_cve-2026-103009 <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&#39;s document contents, field mappings, and other metadata, and in limited cases allows modification of retention-lease state on the unauthorized index.</p> <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&#39;s document contents, field mappings, and other metadata, and in limited cases allows modification of retention-lease state on the unauthorized index.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-103009 https://vulnerability.circl.lu/vuln/ghsa-jh46-59x3-g5qh <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&#39;s document contents, field mappings, and other metadata, and in limited cases allows modification of retention-lease state on the unauthorized index.</p> <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&#39;s document contents, field mappings, and other metadata, and in limited cases allows modification of retention-lease state on the unauthorized index.</p> https://vulnerability.circl.lu/vuln/ghsa-jh46-59x3-g5qh