The flaw allows an authenticated user with limited RBAC permissions to nest etcd transactions and bypass all key‑level authorization checks. By crafting a sequence of transactions, the attacker can retrieve any key in the store, effectively ignoring the defined access restrictions. This results in full disclosure of the etcd data, yielding confidentiality loss and potential system compromise.

The vulnerability is present in etcd‑io's etcd server versions before 3.4.42, 3.5.28, and 3.6.9. Deployment environments that interact directly with etcd using these versions and rely on etcd’s built‑in RBAC are affected. Typical Kubernetes installations, which use the API server for authentication and authorization, are not impacted unless they expose etcd directly to clients.

The issue is scored with a high exploitation potential: any authenticated etcd client can exploit it without additional privileges. The EPSS score is not available and the vulnerability is not listed in KEV, but the practical risk remains high because the attack surface is the etcd RPC interface. If an attacker obtains valid credentials or compromises a user account that can communicate with etcd, they can perform the nested transaction trick to leak all data. Network exposure to the etcd server further increases exploitability, so limiting access and hardening the transport layer are crucial.