EtcdApplication

CVE-2026-33413

HIGH · 8.8 CVSS v3.1 Published 2026-03-26
Fix available
A fix is available. Upgrade to 3.4.42 / 3.5.28 or later.
See remediation →
94/100
Remediation priority · Urgent
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.42, 3.5.28, and 3.6.9, unauthorized users may bypass authentication or authorization checks and call certain etcd functions in clusters that expose the gRPC API to untrusted or partially trusted clients. In unpatched etcd clusters with etcd auth enabled, unauthorized users are able to call MemberList and learn cluster topology, including member IDs and advertised endpoints; call Alarm, which can be abused for operational disruption or denial of service; use Lease APIs, interfering with TTL-based keys and lease ownership; and/or trigger compaction, permanently removing historical revisions and disrupting watch, audit, and recovery workflows. Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected. Versions 3.4.42, 3.5.28, and 3.6.9 contain a patch. If upgrading is not immediately possible, reduce exposure by treating the affected RPCs as unauthenticated in practice. Restrict network access to etcd server ports so only trusted components can connect and/or require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate distribution.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

etcd versions prior to 3.4.42, 3.5.28, and 3.6.9 have a flaw where the gRPC API bypasses authentication/authorization checks for certain RPCs (MemberList, Alarm, Lease, Compaction). This allows unauthenticated attackers to enumerate cluster topology, cause denial of service, interfere with lease operations, or permanently delete historical revisions.

MitigationUpgrade etcd to version 3.4.42, 3.5.28, or 3.6.9. If immediate upgrade is not possible, restrict network access to etcd ports and/or implement mTLS with tightly scoped certificates to limit exposure.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
EtcdApplication
Affected:< 3.4.42>= 3.5.0, < 3.5.28>= 3.6.0, < 3.6.9

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify the installed etcd version
    Run 'etcd --version' on the etcd server host, or query the version via 'etcdctl version'. Compare the output to the affected ranges: versions < 3.4.42, >= 3.5.0 but < 3.5.28, or >= 3.6.0 but < 3.6.9
    Affected if The installed version matches any of the vulnerable version ranges
  2. Confirm the etcd gRPC port is listening
    Run 'netstat -tlnp | grep -E "2379|2380"' or 'ss -tlnp | grep -E "2379|2380"' to identify if the client port (2379) or peer port (2380) is open and listening
    Affected if The gRPC ports are open and listening on any network interface
  3. Verify if the gRPC port is exposed to untrusted networks
    Review firewall rules, cloud security groups, or network ACLs to determine if port 2379/2380 is accessible from outside the trusted network. Check if the bind address is set to '0.0.0.0' instead of '127.0.0.1' in the etcd configuration
    Affected if The etcd gRPC port is reachable from networks beyond the trusted administrative segment
  4. Determine if authentication is enforced on etcd
    Attempt to connect to etcd without credentials using 'etcdctl --endpoints=http://localhost:2379 member list' or test an unauthenticated gRPC call. Also check the etcd configuration file or startup flags for '--auth-token' or 'auth' settings
    Affected if The gRPC API accepts unauthenticated requests or authentication is not configured

You are affected if the installed etcd version is within the vulnerable ranges AND the gRPC API port is accessible from an untrusted network without proper authentication enforcement.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 3.4.42 / 3.5.28 / 3.6.9 or later
Fixed in 3.4.423.5.283.6.9
Interim mitigation

Upgrade etcd to version 3.4.42, 3.5.28, or 3.6.9. If immediate upgrade is not possible, restrict network access to etcd ports and/or implement mTLS with tightly scoped certificates to limit exposure.

Recommended fix High confidence

Upgrade to etcd version 3.4.42, 3.5.28, or 3.6.9 (3.6.9 recommended for latest features)

  1. 1. Identify the current etcd version running in your cluster using `etcd --version` or checking the etcd pod/container version
  2. 2. Plan for a maintenance window as etcd will need to be restarted/rolled out
  3. 3. For Kubernetes-managed etcd: upgrade the etcd component in the control plane (for kubeadm, this involves updating the etcd manifest at `/etc/kubernetes/manifests/etcd.yaml` and letting kubeadm upgrade the etcd pods)
  4. 4. For standalone etcd: download and install the appropriate fixed version (3.4.42, 3.5.28, or 3.6.9) from the official etcd releases at https://github.com/etcd-io/etcd/releases
  5. 5. After upgrading, verify the etcd cluster is healthy using `etcdctl endpoint health` and check cluster membership with `etcdctl member list`
  6. 6. If upgrading cannot be done immediately, apply mitigation: configure firewall or network policies to restrict access to etcd client ports (2379) and peer ports (2380) to only trusted components, or enable mTLS with client certificates for authentication
Caveat Minor: etcd upgrades within same minor version are generally safe, but always test in staging first; ensure client compatibility with the new version before production rollout

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Etcd Scoped from the published advisory
  • Consultation3.0 h
  • Implementation4.0 h
  • Testing3.0 h
  • Review / QA2.0 h
12.0 hours of engineering $2,130
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,408.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-33413 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-33413 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data