GPU VulnDB

Database/Container, Kubernetes & orchestration

etcd: revoked client certificates still authenticate on the gRPC listener when HTTP and gRPC are split

CVSS 8.1CVE-2026-59818Container, Kubernetes & orchestrationcurated

Impact

When etcd is run with --listen-client-http-urls to separate the HTTP and gRPC client endpoints, the certificate revocation list given in --client-crl-file is not applied to the gRPC listener. A client certificate that an operator has already revoked - a decommissioned apiserver, a leaked or rotated cluster credential - keeps full access to the key-value store over gRPC. For a Kubernetes control plane that means read and write access to every object in the cluster, including the secrets backing GPU tenants, so revocation no longer contains a credential compromise. Fixed in 3.5.32 and 3.6.13.

Who can reach it

Anyone who can reach the etcd gRPC client port holding a client certificate issued by the configured CA, including one that has been revoked. Normally that port is reachable only from the control-plane network.

What to do

Upgrade etcd to 3.5.32 or 3.6.13 and perform a rolling restart of the members - a daemon restart per control-plane node, no node drain. As an interim mitigation, stop splitting the listeners (drop --listen-client-http-urls) so the CRL is enforced, or re-issue the client CA so revoked certificates no longer chain to a trusted root.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.