O Kubernetes vai atualizar registros de três CVEs (2020-8561, 2020-8562, 2021-25740) que incorretamente listavam versões corrigidas. Na verdade, são riscos arquiteturais sem patch de código — exigem mitigação por configuração (verbosidade restrita, DNS caching, RBAC). Scanners passarão a detectá-las a partir de 1º de junho de 2026. Administradores devem revisar suas defesas.
Por que a correção desses registros é necessária?
O projeto Kubernetes sempre dependeu da transparência para capacitar administradores e pesquisadores de segurança. Uma forma importante disso é a publicação de registros CVE na base Common Vulnerabilities and Exposures. Durante o trabalho recente de geração de arquivos Open Source Vulnerabilities (OSV) oficiais, foram identificadas discrepâncias: registros de algumas vulnerabilidades antigas e não corrigidas indicavam, incorretamente, a existência de uma versão corrigida.
O Kubernetes Security Response Committee (SRC) corrigirá esses registros em 1º de junho de 2026. Isso pode fazer com que scanners de vulnerabilidade passem a identificar esses problemas onde antes não eram detectados — gerando um volume inesperado de alertas. Para ajudar na transição, este artigo detalha as três CVEs afetadas: CVE-2020-8561, CVE-2020-8562 e CVE-2021-25740.
Quais vulnerabilidades estão sendo corrigidas nos registros?
As três vulnerabilidades são riscos arquiteturais conhecidos, sem correção de código possível sem quebrar funcionalidades fundamentais do Kubernetes. Veja a análise técnica de cada uma:
CVE-2020-8561: Redirecionamento de webhook no kube-apiserver
Severidade: Média (4.1)
O kube-apiserver segue redirecionamentos HTTP ao se comunicar com admission webhooks. Um ator capaz de configurar um AdmissionWebhookConfiguration pode direcionar requisições da API para redes internas privadas. A correção exigiria quebrar o comportamento padrão de clientes HTTP, do qual muitas integrações legítimas dependem.
Mitigação: Configure o kube-apiserver com nível de log menor que 10 (--v < 10) e desabilite profiling dinâmico (--profiling=false).
CVE-2020-8562: Bypass de proxy via DNS TOCTOU
Severidade: Baixa (3.1)
Uma condição de corrida (Time-of-Check to Time-of-Use) no proxy do API server permite ignorar restrições de IP. O sistema faz uma verificação DNS para validar um IP, mas depois realiza uma segunda resolução para a conexão real — que um atacante pode manipular. Corrigir exigiria fixar IPs resolvidos de forma que quebraria ambientes com split-horizon DNS ou IPs dinâmicos.
Mitigação: Use um servidor DNS local como dnsmasq para o API server, configurando min-cache-ttl para garantir respostas consistentes entre a verificação e a conexão.
CVE-2021-25740: Encaminhamento entre namespaces via Endpoints
Severidade: Baixa (3.1)
A falha de design nos objetos Endpoints e EndpointSlice permite que usuários especifiquem manualmente IPs, que podem apontar um LoadBalancer ou Ingress para backends em outros namespaces. Corrigir quebraria a API de Endpoints, usada por muitas ferramentas de rede e operadores.
Mitigação: Restrinja acesso de escrita a Endpoints (legado) e EndpointSlices. Desde o Kubernetes 1.22, as ClusterRoles edit e admin não incluem mais essas permissões por padrão — mas em clusters atualizados de versões anteriores, é necessário auditar e reconciliar manualmente com kubectl auth reconcile.
Quais ações os administradores devem tomar?
O projeto Kubernetes recomenda uma abordagem de "seguro por configuração" para gerenciar esses riscos persistentes. A tabela a seguir resume as ações necessárias:
| Vulnerabilidade | Ação | Severidade | Comando / Configuração |
|---|---|---|---|
| CVE-2020-8561 | Restringir verbosidade de log | 4.1 (Média) | --v < 10 e --profiling=false |
| CVE-2020-8562 | Garantir consistência DNS | 3.1 (Baixa) | Implantar dnsmasq ou cache similar nos nós do plano de controle |
| CVE-2021-25740 | Endurecer RBAC | 3.1 (Baixa) | kubectl auth reconcile para remover permissões de escrita em Endpoints de roles amplas |
Nota importante: A ação para CVE-2021-25740 se aplica quando seu cluster usa RBAC (padrão em clusters criados com ferramentas padrão). Teste todas as configurações em ambiente não produtivo antes de aplicar em produção.
Conclusão: maturidade através da transparência
O esforço de reconciliar esses registros é um sinal de maturidade do ecossistema de segurança. Ao abandonar a mentalidade de "apenas corrigir" e documentar com precisão as dívidas arquiteturais, o Kubernetes oferece dados de alta fidelidade para que a comunidade proteja suas infraestruturas cloud native.
Agradecemos aos pesquisadores de segurança — QiQi Xu, Javier Provecho e outros — que identificaram esses riscos, e aos contribuidores do SIG Security Tooling que continuam refinando os feeds oficiais. Agradecimento especial a Rory McCune por compartilhar informações sobre essas CVEs em seus posts.
Perguntas Frequentes
-
Por que esses CVEs nunca serão corrigidos no código do Kubernetes?
As três vulnerabilidades resultam de trade-offs de design arquitetural. Corrigi-las exigiria quebrar comportamentos padrão de HTTP client, DNS dinâmico ou a API de Endpoints — funcionalidades essenciais para muitas integrações legítimas. O projeto escolheu documentá-las como riscos conhecidos com mitigações administrativas. -
Como a correção dos registros CVE afeta minha organização?
A partir de 1º de junho de 2026, os registros passarão a indicar que todas as versões são afetadas. Scanners de vulnerabilidade que antes ignoravam esses CVEs (por acreditarem em versões corrigidas inexistentes) começarão a reportá-los. Isso pode gerar alertas inesperados, exigindo ações de mitigação baseadas em configuração. -
Quais mitigações devo aplicar para o CVE-2020-8561?
Para o CVE-2020-8561 (webhook redirect), configure o kube-apiserver com nível de log menor que 10 (--v < 10) e desabilite profiling dinâmico (--profiling=false). Isso impede que um ator com acesso a AdmissionWebhookConfiguration redirecione requisições para redes internas. -
O CVE-2021-25740 afeta todos os clusters?
Sim, afeta todas as versões. A mitigação principal é restringir permissões de escrita em Endpoints e EndpointSlices. Em clusters criados com Kubernetes 1.22+, as ClusterRoles edit e admin já não incluem essas permissões. Para clusters atualizados de versões anteriores, audite e remova manualmente o acesso usando kubectl auth reconcile. -
Preciso usar um servidor DNS local para o CVE-2020-8562?
Sim, a recomendação é implantar um cache DNS como dnsmasq nos nós do plano de controle, configurando min-cache-ttl para garantir respostas consistentes entre a verificação de IP e a conexão real. Isso mitiga a condição de corrida TOCTOU que permite bypass das restrições de IP.
Artigo originalmente publicado por Pushkar Joglekar e Tabitha Sable em Kubernetes Blog.
