Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/projectcalico/calico >= 2.0.0, < 3.31.6; < 1.11.0-cni-plugin.0.20260417001138-cd73bc2cea0f
Fixed in
1.11.0-cni-plugin.0.20260417001138-cd73bc2cea0f3.31.6· Vendor fix available
Issue
In Calico, the install-cni init container logs the rendered CNI configuration to standard output. When the configuration template uses the SERVICEACCOUNTTOKEN placeholder (Canal/Flannel-Calico deployments), the installer substitutes the live Kubernetes ServiceAccount bearer token before logging, exposing the token to any authenticated user with pods/log permission in the namespace with calico-node. The token holds patch privileges on pods/status, enabling annotation-based attacks against cluster workloads. The default kubeconfig-based authentication path is not affected. This is a direct regression of TTA-2018-001.
Recommended action: Upgrade to 3.31.6 or 1.11.0-cni-plugin.0.20260417001138-cd73bc2cea0f (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/projectcalico/calico >= 2.0.0, < 3.31.6; < 1.11.0-cni-plugin.0.20260417001138-cd73bc2cea0f
Fixed in
1.11.0-cni-plugin.0.20260417001138-cd73bc2cea0f3.31.6· Vendor fix available
Issue
When Calico is configured with the Azure IPAM plugin, the Calico CNI binary mutates the incoming CNI configuration to attach subnet information before delegating to the IPAM plugin. After mutating, the Azure IPAM helper logs the entire unmarshaled configuration map (stdinData) at INFO level to /var/log/calico/cni/cni.log on every CNI ADD and DEL invocation — once per pod scheduled or terminated on the node. When the cluster is deployed using token-based Kubernetes authentication, this log entry contains the ServiceAccount token, client key, and certificate authority in plaintext. Any principal with read access to /var/log/calico/cni/cni.log on a node can read these logs and extract the credentials, which grant cluster-wide Calico networking admin privileges.
Recommended action: Upgrade to 3.31.6 or 1.11.0-cni-plugin.0.20260417001138-cd73bc2cea0f (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/projectcalico/calico < 3.26.5; >= 3.27.0, < 3.27.3
Fixed in
3.27.33.26.5· Vendor fix available
Issue
In vulnerable versions of Calico (v3.27.2 and below), Calico Enterprise (v3.19.0-1, v3.18.1, v3.17.3 and below), and Calico Cloud (v19.2.0 and below), an attacker who has local access to the Kubernetes node, can escalate their privileges by exploiting a vulnerability in the Calico CNI install binary. The issue arises from an incorrect SUID (Set User ID) bit configuration in the binary, combined with the ability to control the input binary, allowing an attacker to execute an arbitrary binary with elevated privileges.
Recommended action: Upgrade to 3.27.3 or 3.26.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/projectcalico/calico >= 3.26.0, < 3.26.3; <= 3.25.1
Fixed in
3.26.3· Partial vendor fix
Issue
In certain conditions for Calico Typha (v3.26.2, v3.25.1 and below), and Calico Enterprise Typha (v3.17.1, v3.16.3, v3.15.3 and below), a client TLS handshake can block the Calico Typha server indefinitely, resulting in denial of service. 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.
Recommended action: Upgrade to 3.26.3; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Clusters using Calico (version 3.22.1 and below), Calico Enterprise (version 3.12.0 and below), may be vulnerable to route hijacking with the floating IP feature. Due to insufficient validation, a privileged attacker may be able to set a floating IP annotation to a pod even if the feature is not enabled. This may allow the attacker to intercept and reroute traffic to their compromised pod.
Recommended action: Upgrade to 3.22.2, 3.21.5 or 3.20.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
3.10.43.12.23.13.43.9.63.8.93.11.33.14.1· Vendor fix available
Issue
Clusters using Calico (version 3.14.0 and below), Calico Enterprise (version 2.8.2 and below), may be vulnerable to information disclosure if IPv6 is enabled but unused. A compromised pod with sufficient privilege is able to reconfigure the node’s IPv6 interface due to the node accepting route advertisement by default, allowing the attacker to redirect full or partial network traffic from the node to the compromised pod.
Recommended action: Upgrade to 3.14.1, 3.13.4, 3.12.2 or 4 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.