Anthony Tam

Calico's Application Layer Policy (disabled by default), which enforces HTTP rules through Dikastes, fails to perform URL path normalization. As a result, HTTP requests using path-traversal segments, encoded slashes, or repeated slashes are not correctly evaluated by Prefix path rules. Dikastes authorizes the request under the permitted prefix while the downstream workload or a fronting proxy normalizes the path and serves the restricted endpoint. An attacker with network access and no special RBAC can potentially reach HTTP endpoints the policy was intended to restrict.

Calico's apiserver wraps tier-scoped resources so that every operation runs through AuthorizeTierOperation, but the Delete override on NetworkPolicy, GlobalNetworkPolicy, and their staged variants is not invoked for DeleteCollection requests. A user holding the deletecollection verb or wildcard verbs on tier-scoped policy resources can bulk-delete policies in tiers they otherwise have no rights on, breaking the tier authorization boundary.

When Calico's shared debug server is enabled (disabled by default), the Calico kube-controllers and Goldmane components bind their Go pprof debug listener to 0.0.0.0 without authentication. Any pod with network reachability to the listener can retrieve the process heap, goroutine stacks (including function arguments), and command-line arguments. Depending on the process's in-memory state, the heap may contain sensitive material. The debug listener is opt-in but is unsafe when enabled because it offers no authentication and no safe localhost-only binding option.

**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 (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** 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.