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.

**Nome do Software Vulnerável e Versões Afetadas** calicoctl (versões afetadas não especificadas) **Descrição** Quando o cliente é invocado com `--log-level=info` ou `--log-level=debug`, ele imprime o conteúdo completo de sua estrutura de configuração de conexão carregada no stderr em uma única linha de log. Esta estrutura contém credenciais sensíveis usadas para se comunicar com o cluster, incluindo o kubeconfig inline (com token de portador), o token de portador da API do Kubernetes, a senha do etcd e o certificado e chave do cliente etcd codificados em PEM inline. Isso permite que qualquer leitor do fluxo stderr, como logs de jobs de CI ou arquivos de gravação de sessão, extraia essas credenciais sem a necessidade de privilégios do Kubernetes. Este problema ocorre apenas quando o log detalhado é explicitamente habilitado, pois o nível de log padrão é panic. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Calico (versões afetadas não especificadas) **Descrição** O contêiner de inicialização `install-cni` registra a configuração CNI renderizada na saída padrão. Em implantações Canal ou Flannel-Calico onde o modelo de configuração usa o marcador ` SERVICEACCOUNT TOKEN `, o instalador substitui o token de portador do ServiceAccount do Kubernetes ativo antes do registro. Isso expõe o token a qualquer usuário autenticado com permissões de `pods/log` no namespace que contém o `calico-node`. O token exposto possui privilégios de patch em `pods/status`, o que pode ser usado para realizar ataques baseados em anotações contra cargas de trabalho do cluster. O caminho de autenticação padrão baseado em kubeconfig não é afetado. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Calico (versões afetadas não especificadas) **Descrição** Quando configurado com o plugin Azure IPAM, o binário Calico CNI modifica a configuração CNI recebida para incluir informações de sub-rede antes de delegá-la ao plugin IPAM. O auxiliar Azure IPAM então registra todo o mapa de configuração descompactado (`stdinData`) no nível INFO em `/var/log/calico/cni/cni.log` a cada invocação CNI ADD e DEL — ocorrendo sempre que um pod é agendado ou encerrado no nó. Quando o cluster é implantado usando autenticação do Kubernetes baseada em token, essa entrada de log contém o token de ServiceAccount, a chave do cliente e a autoridade de certificação em texto simples. Qualquer principal com acesso de leitura ao arquivo de log no nó pode extrair essas credenciais, que concedem privilégios de administrador de rede do Calico em todo o cluster. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do software vulnerável e versões afetadas** Versões 3.27.2 e anteriores do Calico Versões 3.19.0-1, 3.18.1, 3.17.3 e anteriores do Calico Enterprise Versões 19.2.0 e anteriores do Calico Cloud github.com/projectcalico/calico/v3 antes da v3.26.5, da v3.27.0 até a v3.27.3 **Descrição** O problema decorre de uma configuração incorreta do bit SUID (Set User ID) no binário de instalação do Calico CNI, combinada com a capacidade de controlar o binário de entrada, permitindo que um invasor execute um binário arbitrário com privilégios elevados. Um invasor com acesso local ao nó do Kubernetes pode escalar seus privilégios explorando essa vulnerabilidade. **Recomendações** Para as versões 3.27.2 e anteriores do Calico, considere desativar o binário de instalação do Calico CNI até que um patch esteja disponível. Para as versões 3.19.0-1, 3.18.1, 3.17.3 e anteriores do Calico Enterprise, restrinja o acesso ao binário de instalação do Calico CNI para minimizar o risco de exploração. Para as versões 19.2.0 e anteriores do Calico Cloud, evite usar o binário de instalação do Calico CNI até que o problema seja resolvido. Para github.com/projectcalico/calico/v3 antes da v3.26.5 e da v3.27.0 até a v3.27.3, atualize para uma versão que inclua a correção para este problema.

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