CVE-2026-33343 Overview
CVE-2026-33343 is an authorization bypass vulnerability in etcd, a distributed key-value store commonly used for storing configuration data in distributed systems. Prior to versions 3.4.42, 3.5.28, and 3.6.9, an authenticated user with Role-Based Access Control (RBAC) restricted permissions on key ranges can leverage nested transactions to bypass all key-level authorization controls. This vulnerability allows any authenticated user with direct access to etcd to effectively ignore all key range restrictions, gaining unauthorized access to the entire etcd data store.
Critical Impact
Authenticated attackers can bypass RBAC key range restrictions through nested transactions, gaining full read access to all data in the etcd cluster regardless of their assigned permissions.
Affected Products
- etcd versions prior to 3.4.42
- etcd versions prior to 3.5.28
- etcd versions prior to 3.6.9
Discovery Timeline
- 2026-03-26 - CVE CVE-2026-33343 published to NVD
- 2026-03-26 - Last updated in NVD database
Technical Details for CVE-2026-33343
Vulnerability Analysis
This vulnerability is classified as CWE-863 (Incorrect Authorization), indicating a fundamental flaw in how etcd validates authorization for nested transaction operations. The authorization check implementation fails to properly evaluate the scope of key access when transactions are nested within other transactions. While the outer transaction may be properly authorized for a restricted key range, the inner nested transactions can reference keys outside the permitted scope without triggering additional authorization checks.
The impact is particularly concerning for environments that rely on etcd's built-in RBAC to enforce data isolation between tenants or services. An attacker with even minimal authenticated access to etcd can escalate their privileges to access sensitive configuration data, secrets, or other critical information stored in the key-value store.
It's important to note that standard Kubernetes deployments are typically not affected by this vulnerability. Kubernetes does not rely on etcd's built-in authentication and authorization mechanisms; instead, the Kubernetes API server handles authentication and authorization independently, serving as a protective layer in front of etcd.
Root Cause
The root cause lies in insufficient authorization validation during nested transaction processing. When a user submits a transaction request containing nested transactions, etcd's authorization layer validates the outer transaction against the user's RBAC permissions but fails to recursively apply the same authorization checks to operations within nested transactions. This creates an authorization gap that allows inner transaction operations to access keys outside the user's permitted key range.
Attack Vector
The attack is network-based and requires low-privilege authenticated access to the etcd server. An attacker must have valid credentials to authenticate to etcd but only needs minimal RBAC permissions on a limited key range. By crafting a specially structured transaction request with nested transactions targeting keys outside their authorized range, the attacker can read data from any key in the etcd store.
The attack does not require user interaction and can be executed directly against the etcd gRPC or HTTP API endpoints. While the vulnerability primarily enables unauthorized read access (confidentiality impact), it represents a complete bypass of the RBAC authorization model that organizations may be relying upon for data protection.
Detection Methods for CVE-2026-33343
Indicators of Compromise
- Unusual transaction patterns involving nested transactions from low-privilege users
- Access log entries showing data reads from key ranges outside a user's assigned RBAC permissions
- Anomalous query patterns from service accounts that should have restricted key access
- Increased transaction complexity in requests from specific authenticated users
Detection Strategies
- Monitor etcd audit logs for transaction requests containing nested operations
- Implement application-level logging to track data access patterns against expected RBAC boundaries
- Deploy network monitoring to detect unusual traffic patterns to etcd ports (2379, 2380)
- Review authentication logs for accounts making requests to unauthorized key ranges
Monitoring Recommendations
- Enable comprehensive etcd audit logging to capture all transaction operations
- Configure alerts for nested transaction requests from accounts with limited RBAC permissions
- Implement rate limiting and anomaly detection on etcd API endpoints
- Regularly audit RBAC configurations and user access patterns
How to Mitigate CVE-2026-33343
Immediate Actions Required
- Upgrade etcd to patched versions 3.4.42, 3.5.28, or 3.6.9 immediately
- Restrict network access to etcd server ports (2379, 2380) to only trusted components
- Implement mutual TLS (mTLS) with tightly scoped client certificate distribution
- Treat affected RPCs as unauthenticated in practice until patching is complete
Patch Information
etcd has released security patches in versions 3.4.42, 3.5.28, and 3.6.9 that address this authorization bypass vulnerability. Organizations should upgrade to the appropriate patched version based on their current etcd release branch. For detailed information about the fix, refer to the GitHub Security Advisory.
Workarounds
- Restrict network access to etcd server ports so only trusted components can connect
- Require strong client identity at the transport layer using mTLS
- Implement tightly scoped client certificate distribution to limit which services can access etcd
- Consider deploying a proxy layer that performs additional authorization checks before requests reach etcd
# Example: Restrict etcd access using firewall rules (iptables)
# Allow only trusted IP ranges to connect to etcd client port
iptables -A INPUT -p tcp --dport 2379 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 2379 -j DROP
# Allow only trusted IP ranges to connect to etcd peer port
iptables -A INPUT -p tcp --dport 2380 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 2380 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


