<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 04:57:28 +0000</lastBuildDate>
    <item>
      <title>BIT-etcd-2026-73499 — etcd: Watch API authorization bypass via open-ended range requests</title>
      <link>https://db.gcve.eu/vuln/bit-etcd-2026-73499</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: etcd&lt;/p&gt;
&lt;p&gt;etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.5.33, 3.6.14, and 3.7.1, a user granted READ permission on a single exact key can use the Watch gRPC API with clientv3.WithFromKey() to receive watch events for every key lexicographically greater than or equal to the permitted key. In server/etcdserver/api/v3rpc/watch.go, the open-ended RangeEnd sentinel is rewritten before the RBAC permission check in server/auth/range_perm_cache.go function isRangeOpPermitted, causing the request to be treated as an exact-key watch. Range/Get and DeleteRange requests are not affected, and the issue affects only clusters with authentication enabled. This issue is fixed in versions 3.5.33, 3.6.14, and 3.7.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: etcd&lt;/p&gt;
&lt;p&gt;etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.5.33, 3.6.14, and 3.7.1, a user granted READ permission on a single exact key can use the Watch gRPC API with clientv3.WithFromKey() to receive watch events for every key lexicographically greater than or equal to the permitted key. In server/etcdserver/api/v3rpc/watch.go, the open-ended RangeEnd sentinel is rewritten before the RBAC permission check in server/auth/range_perm_cache.go function isRangeOpPermitted, causing the request to be treated as an exact-key watch. Range/Get and DeleteRange requests are not affected, and the issue affects only clusters with authentication enabled. This issue is fixed in versions 3.5.33, 3.6.14, and 3.7.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/bit-etcd-2026-73499</guid>
    </item>
    <item>
      <title>fkie_cve-2026-73499</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-73499</link>
      <description>&lt;p&gt;etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.5.33, 3.6.14, and 3.7.1, a user granted READ permission on a single exact key can use the Watch gRPC API with clientv3.WithFromKey() to receive watch events for every key lexicographically greater than or equal to the permitted key. In server/etcdserver/api/v3rpc/watch.go, the open-ended RangeEnd sentinel is rewritten before the RBAC permission check in server/auth/range_perm_cache.go function isRangeOpPermitted, causing the request to be treated as an exact-key watch. Range/Get and DeleteRange requests are not affected, and the issue affects only clusters with authentication enabled. This issue is fixed in versions 3.5.33, 3.6.14, and 3.7.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.5.33, 3.6.14, and 3.7.1, a user granted READ permission on a single exact key can use the Watch gRPC API with clientv3.WithFromKey() to receive watch events for every key lexicographically greater than or equal to the permitted key. In server/etcdserver/api/v3rpc/watch.go, the open-ended RangeEnd sentinel is rewritten before the RBAC permission check in server/auth/range_perm_cache.go function isRangeOpPermitted, causing the request to be treated as an exact-key watch. Range/Get and DeleteRange requests are not affected, and the issue affects only clusters with authentication enabled. This issue is fixed in versions 3.5.33, 3.6.14, and 3.7.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-73499</guid>
    </item>
    <item>
      <title>GHSA-xg4h-6gfc-h4m8 — etcd: Watch API authorization bypass via open-ended range requests</title>
      <link>https://db.gcve.eu/vuln/ghsa-xg4h-6gfc-h4m8</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: go.etcd.io/etcd/v3&lt;/p&gt;
&lt;p&gt;### Impact
_What kind of vulnerability is it? Who is impacted?_&lt;/p&gt;
&lt;p&gt;A user granted READ permission on a single, exact key can use the Watch gRPC API with `clientv3.WithFromKey()` (an open-ended, &amp;#34;from this key to the end of the keyspace&amp;#34; watch) to receive watch events for every key lexicographically greater than or equal to their permitted key — not just the one key they were granted.&lt;/p&gt;
&lt;p&gt;This is an authorization bypass in etcd&amp;#39;s RBAC enforcement for the Watch API; Range/Get and DeleteRange requests are not affected. It only affects clusters with authentication enabled — clusters running without auth already allow unrestricted read access.&lt;/p&gt;
&lt;p&gt;### Patches
_Has the problem been patched? What versions should users upgrade to?_&lt;/p&gt;
&lt;p&gt;This vulnerability is patched in the following versions:&lt;/p&gt;
&lt;p&gt;- etcd 3.7.1
- etcd 3.6.14
- etcd 3.5.33&lt;/p&gt;
&lt;p&gt;### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_&lt;/p&gt;
&lt;p&gt;If upgrading is not immediately possible, the following mitigations reduce exposure:&lt;/p&gt;
&lt;p&gt;- Audit READ grants. Any READ grant — even on one key — can be leveraged via Watch to read everything after it. Review who holds READ permissions and revoke/tighten any you wouldn&amp;#39;t trust with full read access.
- Restrict network access. Limit which hosts can reach etcd&amp;#39;s client (gRPC) port via firewall rules or network policy, reducing who can attempt exploitation.&lt;/p&gt;
&lt;p&gt;### Reporter&lt;/p&gt;
&lt;p&gt;- Luis Toro ([@lobuhi](https://github.com/lobuhi) on Github)
- Anthropic  and Adam Korczynski ([@Ada…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: go.etcd.io/etcd/v3&lt;/p&gt;
&lt;p&gt;### Impact
_What kind of vulnerability is it? Who is impacted?_&lt;/p&gt;
&lt;p&gt;A user granted READ permission on a single, exact key can use the Watch gRPC API with `clientv3.WithFromKey()` (an open-ended, &amp;#34;from this key to the end of the keyspace&amp;#34; watch) to receive watch events for every key lexicographically greater than or equal to their permitted key — not just the one key they were granted.&lt;/p&gt;
&lt;p&gt;This is an authorization bypass in etcd&amp;#39;s RBAC enforcement for the Watch API; Range/Get and DeleteRange requests are not affected. It only affects clusters with authentication enabled — clusters running without auth already allow unrestricted read access.&lt;/p&gt;
&lt;p&gt;### Patches
_Has the problem been patched? What versions should users upgrade to?_&lt;/p&gt;
&lt;p&gt;This vulnerability is patched in the following versions:&lt;/p&gt;
&lt;p&gt;- etcd 3.7.1
- etcd 3.6.14
- etcd 3.5.33&lt;/p&gt;
&lt;p&gt;### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_&lt;/p&gt;
&lt;p&gt;If upgrading is not immediately possible, the following mitigations reduce exposure:&lt;/p&gt;
&lt;p&gt;- Audit READ grants. Any READ grant — even on one key — can be leveraged via Watch to read everything after it. Review who holds READ permissions and revoke/tighten any you wouldn&amp;#39;t trust with full read access.
- Restrict network access. Limit which hosts can reach etcd&amp;#39;s client (gRPC) port via firewall rules or network policy, reducing who can attempt exploitation.&lt;/p&gt;
&lt;p&gt;### Reporter&lt;/p&gt;
&lt;p&gt;- Luis Toro ([@lobuhi](https://github.com/lobuhi) on Github)
- Anthropic  and Adam Korczynski ([@Ada…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-xg4h-6gfc-h4m8</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-73499 — etcd: Watch API authorization bypass via open-ended range requests</title>
      <link>https://db.gcve.eu/vuln/msrc_cve-2026-73499</link>
      <description>msrc_CVE-2026-73499</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/msrc_cve-2026-73499</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-73499</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-73499</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: etcd, Ubuntu:Pro:18.04:LTS: etcd, Ubuntu:Pro:20.04:LTS: etcd, Ubuntu:Pro:22.04:LTS: etcd, Ubuntu:Pro:24.04:LTS: etcd, Ubuntu:Pro:26.04:LTS: etcd&lt;/p&gt;
&lt;p&gt;etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.5.33, 3.6.14, and 3.7.1, a user granted READ permission on a single exact key can use the Watch gRPC API with clientv3.WithFromKey() to receive watch events for every key lexicographically greater than or equal to the permitted key. In server/etcdserver/api/v3rpc/watch.go, the open-ended RangeEnd sentinel is rewritten before the RBAC permission check in server/auth/range_perm_cache.go function isRangeOpPermitted, causing the request to be treated as an exact-key watch. Range/Get and DeleteRange requests are not affected, and the issue affects only clusters with authentication enabled. This issue is fixed in versions 3.5.33, 3.6.14, and 3.7.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: etcd, Ubuntu:Pro:18.04:LTS: etcd, Ubuntu:Pro:20.04:LTS: etcd, Ubuntu:Pro:22.04:LTS: etcd, Ubuntu:Pro:24.04:LTS: etcd, Ubuntu:Pro:26.04:LTS: etcd&lt;/p&gt;
&lt;p&gt;etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.5.33, 3.6.14, and 3.7.1, a user granted READ permission on a single exact key can use the Watch gRPC API with clientv3.WithFromKey() to receive watch events for every key lexicographically greater than or equal to the permitted key. In server/etcdserver/api/v3rpc/watch.go, the open-ended RangeEnd sentinel is rewritten before the RBAC permission check in server/auth/range_perm_cache.go function isRangeOpPermitted, causing the request to be treated as an exact-key watch. Range/Get and DeleteRange requests are not affected, and the issue affects only clusters with authentication enabled. This issue is fixed in versions 3.5.33, 3.6.14, and 3.7.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-73499</guid>
    </item>
  </channel>
</rss>
