Bug 2515005 (CVE-2026-73499)

Summary:	CVE-2026-73499 go.etcd.io/etcd: etcd: Information disclosure via Watch API authorization bypass
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	amctagga, anjoseph, aoconnor, bniver, dschmidt, eglynn, flucifre, gmeno, gparvin, groman, jjoyce, jlanda, jprabhak, jpretori, jschluet, kshier, lhh, mbenjamin, mburns, mgarciac, mhackett, rhaigner, simaishi, sostapov, stcannon, teagle, vereddy, wtam, yguenane
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in etcd, a distributed key-value store. A user with READ permission on a single key can bypass authorization checks in the Watch gRPC API by using open-ended range requests. This allows them to receive watch events for keys beyond their authorized scope, leading to information disclosure. This issue affects clusters with authentication enabled.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-12 21:41:21 UTC

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.