CVE-2026-59818: etcd Auth Bypass Vulnerability

CVE-2026-59818 Overview

CVE-2026-59818 is a certificate validation vulnerability [CWE-295] in etcd, the distributed key-value store used by Kubernetes and other distributed systems. When etcd is configured with --listen-client-http-urls to separate HTTP and gRPC client endpoints onto different listeners, the --client-crl-file Certificate Revocation List (CRL) is not enforced on the gRPC listener. A client presenting a previously revoked certificate can still authenticate successfully over gRPC, bypassing the intended revocation control. The issue is fixed in etcd versions 3.5.32 and 3.6.13.

Critical Impact
Authenticated clients with revoked TLS certificates retain full gRPC access to etcd, undermining certificate revocation as a control for lost, stolen, or decommissioned client credentials.

Affected Products

etcd versions prior to 3.5.32 (3.5.x branch)
etcd versions prior to 3.6.13 (3.6.x branch)
Deployments using --listen-client-http-urls to split HTTP and gRPC listeners with --client-crl-file

Discovery Timeline

2026-07-08 - CVE-2026-59818 published to NVD
2026-07-09 - Last updated in NVD database

Technical Details for CVE-2026-59818

Vulnerability Analysis

The flaw stems from how etcd wires up TLS configuration when operators split HTTP and gRPC traffic onto separate listeners. In this deployment mode, the gRPC stack owns the TLS handshake through grpc.Creds, and CRL enforcement was never attached to that code path. The checkCRL logic was only applied to the HTTP listener, so revocation status was silently ignored for any client connecting over gRPC. Because gRPC is the primary API surface for etcd clients, including etcdctl and the Kubernetes API server, this effectively neutralizes certificate revocation for the majority of real traffic.

Root Cause

The root cause is a missing CRL verification hook on the gRPC TLS configuration in server/embed/serve.go. When onlyGRPC mode is active, the server creates a tls.Config for gRPC without registering a VerifyPeerCertificate or VerifyConnection callback that consults the CRL file. Wrapping the listener with a second TLS listener would cause a double-TLS failure, so the fix injects CRL checking directly into the tls.Config before gRPC clones it at server creation time.

Attack Vector

Exploitation requires an attacker to possess a client certificate that etcd previously trusted and that an administrator has since revoked. The attacker connects to the gRPC client endpoint over the network and completes the TLS handshake normally. Because the CRL is not consulted, authentication succeeds and the attacker inherits whatever role the certificate is bound to in etcd's RBAC, potentially including read and write access to cluster state.

// Patch: client/pkg/transport/listener_tls.go
// ConfigureCRLVerification appends a VerifyConnection hook to cfg that
// rejects any peer certificate whose serial number appears in the CRL file
// configured on info. It is a no-op when CRLFile is empty. Any existing
// VerifyConnection hook is called first and its error short-circuits.
func (info TLSInfo) ConfigureCRLVerification(cfg *tls.Config) {
	if len(info.CRLFile) == 0 {
		return
	}
	crlFile := info.CRLFile
	prev := cfg.VerifyConnection
	cfg.VerifyConnection = func(cs tls.ConnectionState) error {
		if prev != nil {
			if err := prev(cs); err != nil {
				return err
			}
		}
		if len(cs.PeerCertificates) == 0 {
			return nil
		}
		return checkCRL(crlFile, cs.PeerCertificates)
	}
}

// Patch: server/embed/serve.go
// In gRPC-only mode the gRPC stack owns the TLS handshake (via grpc.Creds).
// Wrapping sctx.l with a second TLS listener would cause a double-TLS failure,
// so inject CRL checking into the TLS config before the gRPC server is created
// (gRPC clones the config at creation time).
if onlyGRPC {
	tlsinfo.ConfigureCRLVerification(tlscfg)
}

Source: etcd commit 8221ae82

Detection Methods for CVE-2026-59818

Indicators of Compromise

Successful gRPC authentication events in etcd audit logs associated with certificate serial numbers listed in the configured CRL file.
Client connections to the gRPC listener from hosts whose certificates should be revoked, such as decommissioned nodes or rotated service accounts.
Unexpected etcd API activity (reads or writes on sensitive keys) originating from identities tied to previously revoked certificates.

Detection Strategies

Correlate the CRL file contents against certificate serial numbers observed in etcd TLS handshake logs to identify revoked clients that authenticated successfully.
Enable etcd request logging and monitor for gRPC calls made under identities that should no longer have access.
Inventory etcd deployments and flag any cluster running a version older than 3.5.32 or 3.6.13 with both --listen-client-http-urls and --client-crl-file set.

Monitoring Recommendations

Ship etcd server logs and TLS peer certificate metadata to a centralized log platform for correlation with CRL updates and certificate lifecycle events.
Alert on any authenticated gRPC session whose peer certificate serial matches an entry in the current CRL.
Track use of --listen-client-http-urls across the fleet as a configuration risk signal until all clusters are patched.

How to Mitigate CVE-2026-59818

Immediate Actions Required

Upgrade etcd to version 3.5.32 or 3.6.13, matching the branch currently deployed, on every cluster member.
Rotate and re-issue client certificates for any identity whose prior certificate was revoked while the vulnerable configuration was in use, and treat those revocations as potentially bypassed.
Audit etcd RBAC bindings and reduce privileges of certificate-bound users to the minimum required, limiting blast radius if revocation is bypassed.

Patch Information

The fix is available in etcd v3.5.32 and etcd v3.6.13. Technical details are documented in GitHub Security Advisory GHSA-3wh4-j44w-pg92, with the primary code changes landing in pull request #22007, #22021, and #22025.

Workarounds

Stop using --listen-client-http-urls to split HTTP and gRPC onto separate listeners until the patch is applied, so CRL enforcement remains on the combined listener.
Where possible, revoke access at the etcd RBAC layer (disable or delete the user tied to the certificate) instead of relying solely on the CRL file.
Restrict network reachability to the etcd gRPC client port with firewall rules or service mesh policies so that only known, current clients can reach it.

bash

# Verify installed etcd version and upgrade path
etcd --version

# Example: pin patched versions in a Kubernetes control-plane manifest
# image: registry.k8s.io/etcd:3.5.32-0
# image: registry.k8s.io/etcd:3.6.13-0

# Temporary workaround: run without split HTTP/gRPC listeners
# Remove --listen-client-http-urls and keep CRL enforcement on the
# unified client listener until upgrade is complete.
etcd \
  --cert-file=/etc/etcd/pki/server.crt \
  --key-file=/etc/etcd/pki/server.key \
  --trusted-ca-file=/etc/etcd/pki/ca.crt \
  --client-cert-auth=true \
  --client-crl-file=/etc/etcd/pki/client.crl \
  --listen-client-urls=https://0.0.0.0:2379