CVE-2026-33343
Authorization Bypass via Nested Transactions in etcd Key-Value Store
Publication date: 2026-03-26
Last updated on: 2026-03-26
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| etcd | etcd | to 3.4.42 (exc) |
| etcd | etcd | From 3.5.0 (inc) to 3.5.28 (exc) |
| etcd | etcd | From 3.6.0 (inc) to 3.6.9 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability before upgrading to patched versions (3.4.42, 3.5.28, and 3.6.9), you should reduce exposure by treating the affected RPCs as unauthenticated in practice.
- Restrict network access to etcd server ports so that only trusted components can connect.
- Require strong client identity at the transport layer, such as mutual TLS (mTLS) with tightly scoped client certificate distribution.
Can you explain this vulnerability to me?
CVE-2026-33343 is a vulnerability in the etcd distributed key-value store affecting versions up to 3.4.41, 3.5.27, and 3.6.8.
It allows an authenticated user who has Role-Based Access Control (RBAC) restricted permissions on specific key ranges to bypass all key-level authorization checks by using nested transactions.
This bypass enables such users to access the entire etcd data store, ignoring all key range restrictions.
Typical Kubernetes deployments are not affected because Kubernetes does not rely on etcd’s built-in authentication and authorization; instead, it uses the API server for these functions.
The issue has been patched in etcd versions 3.4.42, 3.5.28, and 3.6.9.
How can this vulnerability impact me? :
This vulnerability allows any authenticated user with direct access to etcd to bypass key-level authorization restrictions and access the entire etcd data store.
However, the vulnerability has a low severity rating with a CVSS v3.1 base score of 0.0, indicating no impact on confidentiality, integrity, or availability.
Typical Kubernetes deployments are not affected because they do not rely on etcd’s built-in authentication and authorization.
If upgrading is not immediately possible, mitigation involves restricting network access to etcd server ports to trusted components only and requiring strong client identity at the transport layer, such as mutual TLS (mTLS) with tightly scoped client certificate distribution.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows an authenticated user with restricted RBAC permissions to bypass key-level authorization and access the entire etcd data store. This could potentially expose sensitive data if an attacker gains direct access to etcd.
However, the CVSS score is 0.0, indicating no impact on confidentiality, integrity, or availability, which suggests that the vulnerability itself does not directly compromise data security in a way that would violate compliance requirements.
Typical Kubernetes deployments are not affected because they do not rely on etcd’s built-in authentication and authorization, instead using the API server for these functions.
Mitigations include restricting network access to etcd server ports and enforcing strong client identity, which are important controls to maintain compliance with standards like GDPR and HIPAA that require protection of sensitive data.
Overall, while the vulnerability could increase risk if exploited, proper mitigations and typical deployment architectures reduce the likelihood of compliance violations.