CVE-2026-6720
calicoctl Credential Exposure via Verbose Logging
Publication date: 2026-05-28
Last updated on: 2026-05-28
Assigner: Tigera, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| tigera | calicoctl | 3.31.6 |
| tigera | calicoctl | 3.32 |
| tigera | calicoctl | 3.33.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-532 | The product writes sensitive information to a log file. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability occurs in the calicoctl tool when it is run with verbose logging levels such as --log-level=info or --log-level=debug. In these modes, calicoctl logs the entire contents of its connection-configuration struct to stderr in a single line. This struct contains sensitive credentials including inline kubeconfig with bearer tokens, Kubernetes API bearer tokens, etcd passwords, and PEM-encoded etcd client certificates and keys.
Because these credentials are printed in logs, anyone who can read the stderr output—such as through CI job logs, session recordings, support ticket transcripts, or local filesystem access—can extract these sensitive credentials without needing any Kubernetes privileges. The default log level is panic, so this exposure only happens when verbose logging is explicitly enabled.
How can this vulnerability impact me? :
The vulnerability can lead to unauthorized disclosure of sensitive credentials used by calicoctl to communicate with the Kubernetes cluster and etcd datastore. Exposure of these credentials can allow attackers or unauthorized users to gain access to the cluster or etcd data, potentially leading to security breaches.
Since the credentials are exposed in logs or stderr output, any user or system with access to these logs can extract tokens, passwords, and certificates without needing Kubernetes privileges, increasing the risk of compromise.