CVE-2026-41184

Technical summary

The install-cni init container in Calico performs template substitution of the __SERVICEACCOUNT_TOKEN__ placeholder with the live bearer token before logging the rendered CNI configuration to stdout. This token possesses patch privileges on the pods/status subresource, enabling annotation-based manipulation of pod metadata. Exploitation requires pods/log permission within the namespace running calico-node, making it accessible to any authenticated cluster user with that permission boundary. The kubeconfig-based authentication path is unaffected because it does not expose the token in rendered output.

Business impact

Unauthorized modification of pod annotations by authenticated users can enable privilege escalation, workload tampering, or lateral movement within the cluster. The blast radius depends on RBAC configuration but is contained to users already holding pods/log permissions. Organizations running Canal or Flannel-Calico deployments face elevated risk of annotation-based attacks against production workloads, potentially compromising application integrity and security posture without visibility into token exfiltration.

Affected systems

Tigera Calico deployments using Canal or Flannel-Calico CNI configuration templates are affected. Standard kubeconfig-based Calico deployments are not vulnerable. The exposure depends on the presence of authenticated users with pods/log permission in namespaces where calico-node operates, typically kube-system or a dedicated calico namespace.

Exploitability

Exploitation requires two preconditions: (1) a Calico deployment using the __SERVICEACCOUNT_TOKEN__ placeholder (Canal/Flannel-Calico), and (2) authenticated access to view pod logs in the calico-node namespace. No network traversal or privilege escalation is needed to extract the token—a simple `kubectl logs` command suffices for an authorized user. Once obtained, the token can be used to patch pod annotations cluster-wide, making this a low-complexity, high-impact path for users already inside the authentication boundary.

Remediation

Upgrade Calico to a patched version that suppresses sensitive token output from the install-cni container logs (verify against the vendor advisory for the specific version). Alternatively, restrict pods/log permissions on the calico-node namespace to only cluster administrators and essential monitoring systems, reducing the number of users who can extract the token. Review RBAC policies to ensure least-privilege access to pod logs in system namespaces.

Patch guidance

Consult the Tigera Calico security advisory and release notes for the specific patched version addressing this regression. Apply the patch to all Canal or Flannel-Calico deployments in your environment. Verify that the install-cni container no longer outputs tokens by inspecting pod logs after upgrade. Test thoroughly in a staging environment to confirm CNI configuration rendering continues to function correctly.

Detection guidance

Monitor install-cni pod logs for presence of bearer token patterns (long alphanumeric strings prefixed with 'eyJ' in base64 format). Audit RBAC assignments for pods/log permissions in calico-node namespaces and identify users holding such access. Query audit logs for suspicious use of retrieved tokens to patch pod/status resources outside normal operational windows. Correlate token extraction with subsequent annotation modifications on pods in target namespaces.

Why prioritize this

Although the CVSS score is moderate (6.5), this vulnerability enables lateral movement and workload tampering for authenticated cluster users, representing a meaningful insider threat in multi-tenant or team-based Kubernetes environments. The regression status and low attack complexity warrant prompt patching to prevent exploitation chains targeting pod integrity.

Risk score, explained

CVSS 6.5 (Medium) reflects a network-accessible vulnerability requiring low privileges and no user interaction, with high confidentiality impact (token disclosure) but no direct integrity or availability impact in the initial exposure. However, the downstream annotation-based attacks enabled by the token increase practical severity; prioritization should account for your cluster's RBAC posture and the sensitivity of workloads in affected namespaces.

Frequently asked questions