<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-08T21:40:23.710424+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/certfr-2026-avi-1276</id>
    <title>certfr-2026-avi-1276 — De multiples vulnérabilités ont été découvertes dans les produits Elastic. Certaines d'entre elles permettent à un atta…</title>
    <updated>2026-10-08T21:40:23.736121+00:00</updated>
    <content>certfr-2026-avi-1276</content>
    <link href="https://db.gcve.eu/vuln/certfr-2026-avi-1276"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-103009</id>
    <title>fkie_cve-2026-103009</title>
    <updated>2026-10-08T21:40:23.736372+00:00</updated>
    <content type="xhtml">
      <div 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>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-103009"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-jh46-59x3-g5qh</id>
    <title>GHSA-jh46-59x3-g5qh</title>
    <updated>2026-10-08T21:40:23.736517+00:00</updated>
    <content type="xhtml">
      <div 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>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-jh46-59x3-g5qh"/>
  </entry>
</feed>
