CVE-2026-59818: etcd CRL Bypass in gRPC Listener

Technical summary

When etcd is deployed with --listen-client-http-urls to separate HTTP and gRPC client endpoints, the --client-crl-file configuration parameter does not apply to the gRPC listener. This creates a security gap where the CRL enforcement mechanism, which is intended to invalidate compromised or no-longer-trusted certificates, fails for gRPC connections. An authenticated principal with a revoked certificate can bypass this revocation check and establish authenticated sessions over gRPC. The root cause is incomplete CRL validation logic across listener types in the configuration handling. This is classified under CWE-295 (Improper Certificate Validation).

Business impact

Certificate revocation is a foundational control in zero-trust and defense-in-depth strategies. This bypass undermines the ability to immediately revoke access from compromised certificate material. In production Kubernetes environments where etcd manages cluster state, a revoked certificate that remains functional through gRPC could allow a threat actor to maintain unauthorized cluster access, read sensitive cluster configuration, or modify etcd state without immediate detection. Organizations relying on certificate rotation and revocation as part of their incident response playbook will find this mechanism partially non-functional, extending the window of exposure during key compromise events.

Affected systems

etcd versions prior to 3.5.32 (in the 3.5.x line) and prior to 3.6.13 (in the 3.6.x line) are affected. The vulnerability only manifests when both conditions are met: (1) the instance is configured with --listen-client-http-urls to use separate listeners, and (2) a --client-crl-file is configured to revoke certificates. Deployments using unified HTTP/gRPC listeners or those without CRL-based revocation policies are not affected.

Exploitability

Exploitation requires an attacker to possess or obtain a certificate that is valid for the etcd cluster but has been revoked (removed from the CRL). The attacker must also have network access to the gRPC listener endpoint. The CVSS vector (AV:N/AC:L/PR:H) indicates network accessibility and low attack complexity, but high privilege is assumed as a prerequisite—meaning the attacker must already have had legitimate certificate credentials. This is an insider threat or post-compromise scenario rather than an unauthenticated attack vector. The vulnerability is not currently tracked in CISA's Known Exploited Vulnerabilities catalog.

Remediation

Upgrade to etcd 3.5.32 or later (for 3.5.x users) or 3.6.13 or later (for 3.6.x users). Organizations using other etcd versions should consult vendor advisories for patching timelines. If immediate patching is not possible, consider mitigating controls: deploy etcd behind a firewall or service mesh that enforces certificate validation independently, rotate all certificate material immediately if a certificate compromise is suspected, and audit gRPC access logs for any authentication from principals known to have revoked certificates.

Patch guidance

Patch availability: etcd 3.5.32 and 3.6.13 include fixes for this issue. Test patches in a non-production environment first, as etcd upgrades may require coordination with dependent services. For Kubernetes users, this typically involves updating the etcd image in the control plane and performing a rolling restart of control plane components. Verify cluster stability and quorum status post-upgrade. Check your etcd vendor or distribution (e.g., Kubernetes upstream, commercial distributions) for specific patch timelines and compatibility notes.

Detection guidance

Monitor gRPC access logs for authentication events from clients with certificates that should be revoked. If your etcd deployment logs authentication requests, cross-reference successful gRPC authentications against your current CRL—any matches indicate exploitation attempts or misconfigurations. Network monitoring for unusual gRPC traffic to etcd endpoints from internal systems may also surface suspicious activity. In Kubernetes, audit logs may show unexpected etcd API server access. Enable audit logging if not already active, and alert on any API calls from unexpected principals.

Why prioritize this

Although the CVSS score is MEDIUM (6.5), prioritize this for organizations where (1) etcd uses split listeners with CRL-based revocation, (2) certificate compromise is a realistic threat model, or (3) Kubernetes clusters depend on etcd as the backing store. A revoked certificate that remains functional could allow prolonged unauthorized access to cluster state during an active incident. This is especially critical if your incident response process relies on certificate revocation as a rapid containment measure.

Risk score, explained

The CVSS score of 6.5 (MEDIUM) reflects the requirement for high privilege (PR:H) and the impact scope limited to the etcd component (S:U, no scope escalation). However, the score does not capture the context-dependent severity: in certificate-based zero-trust architectures, breaking revocation is high-impact. The score is appropriate for a baseline risk assessment, but your organization's risk rating should account for the role etcd plays in your infrastructure and the maturity of your certificate management program.

Frequently asked questions