CVE-2026-73499 in etcd
Summary
by MITRE • 08/12/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/12/2026
The vulnerability in etcd affects distributed systems that rely on the key-value store for critical data management operations. This security flaw exists in versions prior to 3.5.33, 3.6.14, and 3.7.1 where improper access control implementation allows authenticated users with read permissions on a single specific key to potentially observe watch events for all keys greater than or equal to their permitted key. The issue stems from the Watch gRPC API's handling of clientv3.WithFromKey() functionality which enables users to monitor key ranges rather than individual keys. When a user with READ permission on a particular key utilizes this feature, the system processes the request incorrectly due to a flawed permission checking sequence.
The technical flaw manifests in the server-side implementation within server/etcdserver/api/v3rpc/watch.go where the open-ended RangeEnd sentinel value gets rewritten before the RBAC permission check occurs in server/auth/range_perm_cache.go. Specifically, the function isRangeOpPermitted processes requests without properly accounting for the range semantics of watch operations, causing legitimate watch requests for a specific key to be misinterpreted as broader range operations. This results in the system treating what should be an exact-key watch as a potentially expanded range operation that bypasses proper authorization boundaries. The vulnerability exploits the timing gap between request processing and permission validation, allowing unauthorized data exposure through the watch mechanism.
The operational impact of this vulnerability is significant for distributed systems using etcd with authentication enabled, as it creates a privilege escalation path where users can gain access to information beyond their explicitly granted permissions. Attackers with read access to a single key can effectively monitor all keys in lexicographical order that come after their permitted key, potentially exposing sensitive data that should remain confidential. This affects systems where etcd serves as the coordination layer for distributed applications, including container orchestration platforms like kubernetes, service discovery mechanisms, and configuration management systems. The scope of impact is limited to clusters with authentication enabled, but within those environments, the vulnerability can expose substantial amounts of data through watch operations that should be restricted to authorized key ranges.
This issue aligns with CWE-284 Access Control Bypass and follows ATT&CK technique T1078 Valid Accounts for privilege escalation. The fix implemented in versions 3.5.33, 3.6.14, and 3.7.1 addresses the core problem by ensuring proper order of operations between request processing and permission validation. The solution corrects the sequence so that range end boundaries are properly evaluated before RBAC checks occur, preventing the misinterpretation of watch requests as broader access patterns. Organizations should implement immediate upgrades to these patched versions while maintaining comprehensive monitoring of watch operations and access logs to detect potential exploitation attempts. Additional security measures include implementing more granular RBAC policies, regular auditing of watch operations, and network segmentation to limit exposure of etcd clusters to unauthorized users.