Affected: Bitnami: etcd

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.

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.

Affected: Go: go.etcd.io/etcd/v3

### Impact _What kind of vulnerability is it? Who is impacted?_

A user granted READ permission on a single, exact key can use the Watch gRPC API with `clientv3.WithFromKey()` (an open-ended, "from this key to the end of the keyspace" 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.

This is an authorization bypass in etcd'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.

### Patches _Has the problem been patched? What versions should users upgrade to?_

This vulnerability is patched in the following versions:

- etcd 3.7.1 - etcd 3.6.14 - etcd 3.5.33

### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, the following mitigations reduce exposure:

- 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't trust with full read access. - Restrict network access. Limit which hosts can reach etcd's client (gRPC) port via firewall rules or network policy, reducing who can attempt exploitation.

### Reporter

- Luis Toro ([@lobuhi](https://github.com/lobuhi) on Github) - Anthropic and Adam Korczynski ([@Ada…

Affected: 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

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.