Anthony Tam

**Name of the Vulnerable Software and Affected Versions** Calico (affected versions not specified) **Description** The `install-cni` init container logs the rendered CNI configuration to standard output. In Canal or Flannel-Calico deployments where the configuration template uses the ` SERVICEACCOUNT TOKEN ` placeholder, the installer substitutes the live Kubernetes ServiceAccount bearer token before logging. This exposes the token to any authenticated user with `pods/log` permissions in the namespace containing `calico-node`. The exposed token possesses patch privileges on `pods/status`, which can be used to perform annotation-based attacks against cluster workloads. The default kubeconfig-based authentication path is not affected. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Calico (affected versions not specified) **Description** When configured with the Azure IPAM plugin, the Calico CNI binary modifies the incoming CNI configuration to include subnet information before passing it to the IPAM plugin. The Azure IPAM helper then logs the complete unmarshaled configuration map (`stdinData`) at the INFO level to `/var/log/calico/cni/cni.log` during every CNI ADD and DEL invocation, which occurs whenever a pod is scheduled or terminated on a node. In clusters using token-based Kubernetes authentication, these logs contain the ServiceAccount token, client key, and certificate authority in plaintext. An attacker or principal with read access to the log file on a node can extract these credentials to obtain cluster-wide Calico networking admin privileges. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** calicoctl (affected versions not specified) **Description** When the client is invoked with `--log-level=info` or `--log-level=debug`, it prints the full contents of its loaded connection-configuration struct to stderr in a single log line. This struct contains sensitive credentials used to communicate with the cluster, including the inline kubeconfig (with bearer token), Kubernetes API bearer token, etcd password, and inline PEM-encoded etcd client certificate and key. This allows any reader of the stderr stream, such as CI job logs or session-recording archives, to extract these credentials without requiring Kubernetes privileges. This issue only occurs when verbose logging is explicitly enabled, as the default log level is panic. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Calico versions 3.27.2 and below Calico Enterprise versions 3.19.0-1, 3.18.1, 3.17.3 and below Calico Cloud versions 19.2.0 and below github.com/projectcalico/calico/v3 before v3.26.5, from v3.27.0 before v3.27.3 **Description** The issue arises from an incorrect SUID (Set User ID) bit configuration in the Calico CNI install binary, combined with the ability to control the input binary, allowing an attacker to execute an arbitrary binary with elevated privileges. An attacker who has local access to the Kubernetes node can escalate their privileges by exploiting this vulnerability. **Recommendations** For Calico versions 3.27.2 and below, consider disabling the Calico CNI install binary until a patch is available. For Calico Enterprise versions 3.19.0-1, 3.18.1, 3.17.3 and below, restrict access to the Calico CNI install binary to minimize the risk of exploitation. For Calico Cloud versions 19.2.0 and below, avoid using the Calico CNI install binary until the issue is resolved. For github.com/projectcalico/calico/v3 before v3.26.5, from v3.27.0 before v3.27.3, update to a version that includes the fix for this issue.

**Name of the Vulnerable Software and Affected Versions** Calico Typha versions 3.26.2 and below Calico Typha version 3.25.1 Calico Enterprise Typha versions 3.17.1 and below Calico Enterprise Typha version 3.16.3 Calico Enterprise Typha version 3.15.3 **Description** The issue arises when a client TLS handshake can block the Calico Typha server indefinitely, resulting in denial of service. This occurs because the TLS Handshake() call is performed inside the main server handle for loop without any timeout, allowing an unclean TLS handshake to block the main loop indefinitely while other connections will be idle waiting for that handshake to finish. **Recommendations** For Calico Typha versions 3.26.2 and below, consider implementing a timeout for the TLS handshake to prevent indefinite blocking. For Calico Typha version 3.25.1, consider implementing a timeout for the TLS handshake to prevent indefinite blocking. For Calico Enterprise Typha versions 3.17.1 and below, consider implementing a timeout for the TLS handshake to prevent indefinite blocking. For Calico Enterprise Typha version 3.16.3, consider implementing a timeout for the TLS handshake to prevent indefinite blocking. For Calico Enterprise Typha version 3.15.3, consider implementing a timeout for the TLS handshake to prevent indefinite blocking.