CVE-2026-41185

Technical summary

CVE-2026-41185 is an information disclosure vulnerability in Tigera Calico's CNI plugin when the Azure IPAM backend is configured. The vulnerability chain: (1) Calico's CNI binary receives CNI_STDIN containing the pod network configuration plus the injected Kubernetes API server endpoint and authentication credentials; (2) before delegation to the Azure IPAM plugin, Calico mutates this data to attach subnet metadata; (3) the Azure IPAM helper then unmarshals the entire configuration map and logs it at INFO severity to /var/log/calico/cni/cni.log; (4) if the cluster uses token-based authentication (the default for most Kubernetes distributions), the log entry contains plaintext ServiceAccount token, client certificate, client key, and certificate authority in PEM format. The root cause is insufficient log filtering—credentials should never be logged, or logs should be automatically redacted. The vulnerability manifests as CWE-532 (Insertion of Sensitive Information into Log File). With node-level file access, an attacker can parse logs to extract valid cluster credentials and assume Calico networking admin role.

Business impact

This vulnerability enables credential theft at scale in containerized environments. For organizations running Calico on Azure Kubernetes Service (AKS) or self-managed Kubernetes clusters with token authentication, the exposure is continuous and proportional to pod churn—a busy cluster with hundreds of daily pod lifecycle events generates hundreds of credential-bearing log entries daily. Compromised credentials grant cluster-wide network policy modification rights, allowing an attacker to disable isolation between sensitive workloads, exfiltrate east-west traffic, or launch lateral movement attacks. The exposure is particularly severe because: (1) node-level file access is often achievable via container escape, kubelet compromise, or node SSH access; (2) logs persist indefinitely without automatic rotation or deletion policies in most deployments; (3) the credential's RBAC scope typically includes networking administration, making it valuable for persistence and lateral movement. Incident response complexity increases significantly if logs have been co-mingled in centralized logging systems without redaction.

Affected systems

Tigera Calico is affected when deployed with the Azure IPAM plugin active and Kubernetes configured for token-based authentication. The vulnerability requires a specific architectural configuration: Azure IPAM must be enabled (via cni.plugins.ipam configuration), and the cluster must be using Kubernetes ServiceAccount tokens for API authentication—which encompasses standard Kubernetes distributions including managed AKS, on-premise clusters, and most GKE/EKS deployments using native auth. Calico versions prior to the fix are in scope. The vulnerability manifests at node level, so exposure depends on the number of nodes in the cluster and the frequency of pod lifecycle events per node. A single-node development cluster may produce dozens of leaked credentials per day; a multi-thousand-node production cluster may leak millions of credentials weekly. The logs are written to /var/log/calico/cni/ on each node, so the attack surface encompasses every node where the Calico CNI and Azure IPAM plugin are active.

Exploitability

Exploitability is straightforward given node-level access. An attacker who can read /var/log/calico/cni/cni.log (via container escape, node compromise, or lateral movement from a container with node filesystem mount) can parse the logs using simple string matching or regex to extract JSON-formatted configuration containing credentials. The credentials are not obfuscated—they appear in standard Kubernetes token and certificate formats. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects that exploitation requires a foothold with PR:L (some level of authenticated access), but once inside the cluster or on a node, the confidentiality impact is high. The lack of complexity (AC:L) underscores that no bypasses or special conditions are needed—reading a log file requires only file permissions, which are often overly permissive in containerized environments. The vulnerability is not actively exploited in the wild per available intelligence, but the attack vector is well within reach of standard threat actors with container or node access.

Remediation

Remediation requires a patched version of Tigera Calico that filters sensitive fields (token, client key, CA) from log output before persisting configuration data to disk. The recommended approach is to upgrade to a patched Calico release that implements credential redaction in the Azure IPAM helper logging path. Organizations should: (1) identify all nodes running Calico with Azure IPAM enabled; (2) verify which Calico version is deployed (kubectl get ds -n calico-system calico-node -o jsonpath='{.spec.template.spec.containers[0].image}'); (3) upgrade to the patched version per Tigera's advisory; (4) validate logs no longer contain plaintext credentials by inspecting /var/log/calico/cni/cni.log after an upgrade; (5) audit and rotate all Kubernetes ServiceAccount tokens that may have been exposed in pre-patch logs, as a precautionary measure. Log rotation policies should be tightened to reduce the window of credential exposure on disk.

Patch guidance

Verify the patched Calico version against Tigera's official security advisory. Patching requires a rolling update of the Calico DaemonSet on each node. Use kubectl set image to update the Calico node image in the calico-system namespace. Test patching in a non-production cluster first to confirm log output is properly redacted. After patching, inspect recent log entries to confirm no plaintext credentials are being written. If logs were centralized to a logging backend (ELK, Datadog, Splunk, etc.) before patching, request log purging from those systems as well, or implement data retention policies that delete sensitive CNI logs within 24–48 hours. Consider auditing which principals had access to /var/log/calico/cni/ on each node during the exposure window (from cluster deployment to patch application) to determine if credential theft occurred.

Detection guidance

Detection methods: (1) Scan existing /var/log/calico/cni/cni.log files on all nodes for patterns matching Kubernetes token (eyJhbGc...), certificate headers (-----BEGIN CERTIFICATE-----), or private key markers (-----BEGIN PRIVATE KEY-----) using grep or yara rules; (2) if logs are centralized, search for the same patterns in the Calico CNI log stream; (3) monitor for Calico RBAC token usage spikes—unusual API calls authenticating as ServiceAccount tokens with Calico networking scopes; (4) implement file integrity monitoring on /var/log/calico/cni/ to detect unexpected access or exfiltration attempts. Given that credentials may have already been extracted, prioritize hunting for their usage in API audit logs—look for authentication events using tokens that correspond to extracted credentials, particularly calls to Kubernetes Network Policy or Calico Network Policy APIs.

Why prioritize this

This vulnerability merits priority due to its combination of continuous exposure, high-value credentials, and persistence risk. Although the CVSS score is MEDIUM (6.5), the real-world impact is elevated because: (1) credentials are leaked repeatedly and automatically on every pod lifecycle event, creating a high-frequency leak channel; (2) the stolen credentials grant cluster-wide network admin privileges, enabling lateral movement and traffic manipulation; (3) the exposure window extends from cluster creation until patching, potentially spanning months or years; (4) affected organizations often run Calico on Azure because of its tight AKS integration, and AKS is heavily used in production environments; (5) container escape and node compromise are common follow-ups to credential theft, making this a strong pivot point for multi-stage attacks. Organizations running Calico + Azure IPAM should prioritize patching within 1–2 weeks.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM) is driven by: (1) High confidentiality impact (C:H)—plaintext credentials are disclosed; (2) No integrity or availability impact (I:N, A:N)—logs are read-only from an attacker's perspective; (3) Network attack vector (AV:N) because an attacker must first gain access to a node or container, which is networked; (4) Low attack complexity (AC:L)—no special techniques needed to read a log file; (5) Low privilege requirement (PR:L)—some foothold is needed, but not root; (6) No user interaction (UI:N). The MEDIUM rating underweights the practical risk because CVSS does not account for the continuous/automatic nature of credential logging, the cluster-wide impact of compromised credentials, or the prevalence of Calico + Azure deployments. Organizations should apply a context multiplier and treat this as a HIGH priority for their specific environment if they run the affected configuration.

Frequently asked questions