CVE-2026-6720: Calicoctl leaks cluster credentials to stderr when verbose logging is enabled

Synopsis

An information-disclosure bug in calicoctl (Tigera Calico, Calico Enterprise, and Calico Cloud) causes the tool to print full cluster credentials to stderr when verbose logging is enabled via --log-level=info or --log-level=debug. The vulnerability is reachable by a low-privileged user who can invoke calicoctl with verbose flags and read the resulting stderr output, whether from CI logs, support transcripts, or local files. Successful exploitation exposes bearer tokens, etcd passwords, and PEM-encoded client certificates and keys, giving an attacker the material needed to authenticate directly to the Kubernetes API or etcd. Patched-image rebuilds at versions 3.21.7, 3.22.3, 3.32.0, and 22.4.0 are available on HarborGuard for affected environments.

HarborGuard Coverage

Exploit Conditions

• Network reachabilityRequired

  The attacker must be able to reach the host or system over the network (or have access to networked log stores such as CI pipelines, support systems, or session archives) to read the credential-bearing stderr output.

• AuthenticationRequired

  A low-privilege account is sufficient; the attacker needs only enough access to invoke calicoctl with verbose flags or to read the stderr stream from a session that did so.

• Victim interactionRequired

  An operator or CI process must explicitly invoke calicoctl with --log-level=info or --log-level=debug for the credentials to be emitted; the default log level (panic) does not trigger the leak.

• Attack complexityDetail

  The CVSS vector includes AT:P (attack requirements present), meaning specific preconditions such as verbose logging being enabled must exist, but once those conditions are met no race condition or memory-layout manipulation is required and the exploit is straightforward.

Blast Radius

• An attacker who reads the leaked stderr output extracts bearer tokens granting direct authenticated access to the Kubernetes API without needing any in-cluster privilege.
• Etcd passwords and inline PEM-encoded client certificates and keys are exposed, allowing the attacker to authenticate directly to the etcd datastore and read or modify all cluster state.
• With access to cluster and etcd credentials, the attacker can create, modify, or delete Kubernetes resources across the cluster, affecting workloads and configuration in the cluster scope (SC:H, SI:H).
• Compromise of etcd or API credentials can affect availability of dependent cluster services (SA:H), enabling the attacker to disrupt cluster operation by altering critical control-plane data.