Kubernetes

Três vulnerabilidades críticas no runc, o runtime de contêineres que suporta Docker e Kubernetes, foram divulgadas por um pesquisador da SUSE em 5 de novembro de 2025. As falhas, identificadas como CVE-2025-31133, CVE-2025-52565 e CVE-2025-52881, permitem que atacantes contornem o isolamento de contêineres e obtenham acesso root aos sistemas host. Essas vulnerabilidades afetam versões conhecidas do runc e exploram fraquezas nas operações de montagem e nas proteções de arquivos durante a criação de contêineres. Os atacantes podem usar condições de corrida e manipulação de links simbólicos para contornar restrições de segurança, permitindo a escrita em arquivos críticos do sistema, o que pode levar a uma fuga de contêineres. É crucial que organizações que utilizam Docker, Kubernetes ou serviços que dependem do runc atualizem imediatamente para versões corrigidas (1.2.8, 1.3.3 ou 1.4.0-rc.3 e posteriores) para evitar compromissos de segurança. Além disso, recomenda-se a auditoria de ambientes implantados e a implementação de políticas rigorosas de escaneamento de imagens para detectar Dockerfiles maliciosos.

Uma investigação sobre a violação de uma infraestrutura hospedada na Amazon Web Services (AWS) revelou um novo rootkit para GNU/Linux, denominado LinkPro, conforme relatado pela empresa de cibersegurança Synacktiv. O ataque começou com a exploração de um servidor Jenkins exposto, vulnerável à CVE-2024–23897, que permitiu a implantação de uma imagem Docker maliciosa chamada ‘kvlnt/vv’ em vários clusters Kubernetes. Essa imagem continha um sistema baseado em Kali Linux e arquivos que permitiam a instalação de um servidor VPN e um downloader que se comunicava com um servidor de comando e controle (C2).

Uma vulnerabilidade crítica foi identificada no SUSE Rancher Manager, permitindo que atacantes bloqueiem contas administrativas por meio de manipulação de nomes de usuário. Essa falha, resultante de uma validação inadequada no sistema de gerenciamento de usuários, possibilita que usuários mal-intencionados com permissões de atualização alterem nomes de usuários, impedindo o acesso de administradores legítimos. Existem dois vetores principais de ataque: a tomada de conta, onde um usuário pode alterar o nome de outro para ‘admin’, e o bloqueio direto de contas administrativas. A exploração dessa vulnerabilidade pode causar interrupções significativas nas operações de gerenciamento de plataformas, deixando sistemas críticos sem supervisão adequada. A SUSE já disponibilizou correções nas versões v2.12.2, v2.11.6, v2.10.10 e v2.9.12, que implementam validações para impedir a modificação de nomes de usuário após a atribuição inicial. Para organizações que não podem atualizar imediatamente, recomenda-se a implementação de controles de acesso rigorosos. A auditoria regular de permissões e o monitoramento de alterações não autorizadas são essenciais para detectar tentativas de exploração antes que causem danos operacionais.

Uma vulnerabilidade de alta severidade foi descoberta na biblioteca cliente C# do Kubernetes, comprometendo a integridade das comunicações com o servidor API e abrindo espaço para ataques do tipo man-in-the-middle (MiTM). Identificada como CVE-2025-9708, a falha resulta de uma validação inadequada de certificados no modo de Autoridade Certificadora (CA) personalizada. O cliente aceita qualquer certificado assinado pela CA fornecida, sem verificar a cadeia de confiança completa. Isso permite que atacantes apresentem certificados falsificados e interceptem ou manipulem o tráfego sensível do plano de controle. A vulnerabilidade afeta todas as versões do cliente C# do Kubernetes até a versão 17.0.13, especialmente em ambientes que utilizam certificados CA personalizados. Embora a falha tenha um escore CVSS de 6.8, indicando uma severidade média, ela representa um risco significativo em ambientes de desenvolvimento e produção. O projeto Kubernetes já lançou uma correção na versão 17.0.14, e recomenda-se que os usuários atualizem imediatamente. Enquanto isso, uma solução temporária é mover os certificados CA personalizados para o armazenamento de confiança do sistema, embora isso amplie a confiança para todos os processos no host. As equipes devem auditar arquivos kubeconfig e monitorar logs para detectar possíveis explorações.

Pesquisadores de cibersegurança revelaram múltiplas vulnerabilidades críticas no Chaos Mesh, uma plataforma de Engenharia de Caos de código aberto, que podem permitir a tomada de controle de clusters em ambientes Kubernetes. As falhas, coletivamente chamadas de ‘Chaotic Deputy’, incluem a exposição de um servidor de depuração GraphQL sem autenticação, permitindo que atacantes executem comandos arbitrários e causem negação de serviço em todo o cluster. Além disso, três mutações no Chaos Controller Manager são vulneráveis a injeção de comandos do sistema operacional, com pontuações CVSS de até 9.8, indicando um alto nível de severidade. Um atacante com acesso à rede do cluster pode explorar essas vulnerabilidades para executar código remotamente e potencialmente roubar dados sensíveis ou interromper serviços críticos. Após a divulgação responsável em maio de 2025, a equipe do Chaos Mesh lançou uma atualização em agosto para corrigir as falhas. Os usuários são fortemente aconselhados a atualizar suas instalações imediatamente ou restringir o tráfego de rede para o daemon e servidor API do Chaos Mesh.

O cenário de segurança para aplicações nativas da nuvem está passando por uma transformação significativa, impulsionada pela adoção crescente de tecnologias como containers, Kubernetes e serverless. Embora essas inovações acelerem a entrega de software, também ampliam a superfície de ataque, tornando os modelos de segurança tradicionais inadequados. Em 2025, a visibilidade em tempo de execução (runtime visibility) se destaca como uma capacidade essencial para as plataformas de proteção de aplicações nativas da nuvem (CNAPPs). Essa abordagem permite que as equipes de segurança identifiquem e priorizem ameaças reais, evitando a armadilha de falsos positivos. A integração da inteligência artificial (IA) nesse contexto também se mostra promissora, ajudando a correlacionar sinais de diferentes domínios e a acelerar a resposta a incidentes. Além disso, a responsabilidade compartilhada entre equipes de segurança e desenvolvimento é crucial para garantir que as vulnerabilidades sejam tratadas de forma eficaz. A consolidação de ferramentas em uma única plataforma CNAPP é vista como inevitável para reduzir a fragmentação e melhorar a visibilidade do risco na nuvem. À medida que o uso de containers cresce, a segurança em tempo real, a assistência impulsionada por IA e plataformas unificadas se tornam essenciais para proteger as aplicações de forma eficaz.

Um novo ataque cibernético descoberto permite que usuários autenticados do ArgoCD, uma ferramenta popular de entrega contínua para Kubernetes, roubem credenciais do GitHub. O ataque explora a resolução de DNS do Kubernetes, enganando o servidor de repositório do ArgoCD a se conectar a um serviço controlado pelo atacante em vez do verdadeiro GitHub. Ao implantar um serviço malicioso, o atacante cria um registro DNS que redireciona o domínio github.com para um IP interno do cluster. Quando o ArgoCD busca manifestos via HTTPS, o atacante utiliza um certificado personalizado para inspecionar o cabeçalho de autorização e exfiltrar credenciais, incluindo tokens de autenticação e JWTs do GitHub. Para que o ataque seja bem-sucedido, a conta do ArgoCD comprometida deve ter permissões adequadas. O artigo também sugere medidas de mitigação, como aplicar princípios de menor privilégio e monitorar o tráfego interno. Essa vulnerabilidade é uma preocupação crescente, especialmente em um cenário onde a exfiltração de informações é um tema recorrente na cibersegurança.

Uma vulnerabilidade crítica foi identificada na plataforma Argo CD, amplamente utilizada para entrega contínua em ambientes Kubernetes. Essa falha permite que tokens de API com permissões básicas de projeto acessem credenciais sensíveis de repositórios, incluindo nomes de usuário e senhas. A vulnerabilidade, designada como GHSA-786q-9hcg-v9ff, foi revelada pelo pesquisador de segurança Michael Crenshaw e afeta todas as versões do Argo CD a partir da 2.2.0-rc1.

O problema ocorre no endpoint da API de detalhes do projeto (/api/v1/projects/{project}/detailed), onde tokens com permissões padrão podem recuperar credenciais sem a necessidade de acesso explícito a segredos. Isso representa uma séria escalada de privilégios, pois tokens destinados a operações rotineiras de aplicação obtêm acesso não autorizado a dados de autenticação sensíveis. A falha não se limita apenas a permissões de nível de projeto, mas também se estende a qualquer token com permissões de obtenção de projeto, aumentando o impacto potencial em implementações empresariais do Argo CD.

Uma vulnerabilidade crítica foi identificada no sistema de gerenciamento Fleet da SUSE, que expõe dados sensíveis de configuração do Helm devido ao armazenamento não criptografado. O problema está relacionado ao manuseio de informações sensíveis através de recursos BundleDeployment, que são armazenados em formato de texto simples, permitindo que qualquer usuário com permissões de GET ou LIST acesse valores do Helm que contêm credenciais, chaves de API e senhas. Diferente do Helm v3, que utiliza segredos do Kubernetes para proteger esses dados, a implementação do Fleet não adota essas salvaguardas, deixando os valores vulneráveis tanto no nível de armazenamento quanto nas respostas da API. A SUSE já lançou patches que alteram fundamentalmente a forma como o Fleet lida com dados sensíveis, introduzindo capacidades de armazenamento de segredos dedicadas para cada recurso Bundle e BundleDeployment, garantindo criptografia e controles de acesso adequados. Organizações são aconselhadas a revisar suas implementações do Fleet e a implementar políticas de controle de acesso para mitigar os riscos enquanto os patches são aplicados.