Introdução e contexto da pesquisa
A segurança de ambientes containerizados tornou-se uma prioridade absoluta para equipes de segurança da informação, especialmente com a adoção massiva de Docker e Kubernetes em infraestruturas modernas. Uma pesquisa recente conduzida pela Kaspersky, publicada em 29 de maio de 2026, expõe a realidade preocupante do estado atual das imagens de container públicas. O estudo analisou uma amostra aleatória de 100 imagens populares do Docker Hub, com downloads variando entre 10.000 e 1 milhão, e encontrou falhas de segurança sistêmicas que colocam em risco organizações que dependem dessas imagens para produção.
O relatório destaca que a infraestrutura hospedada em containers é um alvo atraente para atacantes. Um container comprometido pode ser utilizado para ataques DDoS, mineração de criptomoedas ou como proxy de tráfego. No entanto, as consequências vão muito além disso: uma vez que um invasor ganha controle de um container, ele pode roubar ou destruir dados diretamente, acessar containers vizinhos ou tentar escapar do container para comprometer toda a rede corporativa.
Vulnerabilidades de software e fontes de atualização comprometidas
Um dos principais problemas identificados é a falta de atualização oportuna das imagens pré-construídas. Uma imagem Docker é, por natureza, uma instantânea de uma distribuição Linux específica após a instalação de pacotes. Diferentemente de servidores Linux tradicionais, onde atualizações de segurança são instaladas automaticamente por serviços como unattended-upgrades ou dnf-automatic, as imagens de container não recebem atualizações por conta própria.
Para aplicar atualizações, a imagem deve ser recriada e reimplantada. Frequentemente, esse processo não é automatizado, e algumas atualizações exigem esforço adicional para verificar sua operação correta. Como resultado, muitas imagens populares não recebem atualizações de segurança a tempo, o que aumenta significativamente os riscos associados ao seu uso. Uma imagem que era segura no momento da construção acumula vulnerabilidades conforme elas são descobertas nos pacotes instalados dentro dela.
A pesquisa encontrou 64 imagens com versões de software desatualizadas contendo vulnerabilidades críticas. Exemplos incluem a vulnerabilidade CVE-2025-49844 no servidor Redis, que leva à execução remota de código (RCE) explorando uma falha no parser Lua; a vulnerabilidade CVE-2026-24061 no nginx, que em algumas configurações leva ao crash do processo do servidor e, com ASLR desabilitado, novamente à RCE; e vulnerabilidades CVE-2025-32463 no sudo e CVE-2023-4911 no glibc, permitindo que um atacante ganhe privilégios de root com acesso local.
É importante notar que apenas uma em cada dez imagens de Docker da amostra analisada está totalmente atualizada. Isso indica que a maioria das organizações que utilizam imagens públicas está operando com uma superfície de ataque conhecida e não mitigada.
Riscos de cadeia de suprimentos e atualizações frequentes
Embora atualizações frequentes sejam necessárias, elas têm um lado negativo. Cada recriação que baixa novos pacotes de repositórios de origem introduz um risco adicional de ataque à cadeia de suprimentos. Uma dependência comprometida ou uma imagem base modificada poderia injetar silenciosamente código malicioso no ambiente exatamente através de uma atualização.
Embora a análise da Kaspersky não tenha encontrado sinais de ataques à cadeia de suprimentos na amostra, incidentes como o ocorrido em março de 2026 nos projetos Trivy e LiteLLM demonstram o risco real. No caso do Trivy, o arquivo infectado foi injetado diretamente na imagem de container nos repositórios oficiais.
Isso leva a uma escolha difícil: atualizações infrequentes deixam vulnerabilidades conhecidas não corrigidas dentro da imagem, enquanto atualizações frequentes aumentam o risco de comprometimento da cadeia de suprimentos. Para proteger a infraestrutura, é necessário não apenas atualizar regularmente as imagens base, mas também adotar uma abordagem mais abrangente, especificamente fixando dependências em versões conhecidas como boas e escaneando as imagens resultantes em busca de malware após a atualização.
Vulnerabilidades de configuração e manipulação insegura de credenciais
Até mesmo um container com uma imagem totalmente atualizada pode ser comprometido se estiver configurado incorretamente. A pesquisa identificou diversas configurações inseguras, incluindo chaves e segredos embutidos na imagem, autenticação desabilitada em serviços de rede, senhas padrão e permissões de acesso a arquivos inseguras.
Um exemplo crítico é o uso de senhas padrão definidas via variáveis de ambiente ou diretamente no Dockerfile. Se essas senhas não forem substituídas, os atacantes poderão acessar o aplicativo usando a senha padrão. A análise da ferramenta KIRA, assistente de IA da Kaspersky, revelou que a senha do usuário é armazenada em texto plano na história das camadas da imagem. Qualquer pessoa que ganhe acesso à imagem poderá extrair a senha.
Outro problema comum é a passagem de senhas via argumentos de comando, que são visíveis para todos os usuários no sistema. Em um exemplo analisado, a senha do superusuário MySQL foi passada no comando healthcheck em texto plano, tornando-a visível ao visualizar a lista de processos, em logs de auditoria e em sistemas de monitoramento.
Elevação de privilégios e permissões de arquivos inseguras
A elevação de privilégios dentro do container é um vetor comum para comprometimento inicial. Se um atacante ganha privilégios de root, ele pode controlar totalmente todos os processos dentro do container, ocultar sua atividade e usar métodos para escapar do container. A pesquisa identificou configurações onde o comando sudo é configurado para permitir execução de comandos arbitrários como root sem senha, violando o princípio do menor privilégio.
Permissões de arquivos inseguras também foram encontradas. A maioria das vezes, autores de imagens de container usam permissões 777 por conveniência, o que permite que qualquer usuário, incluindo usuários não privilegiados, crie e exclua arquivos livremente. Isso pode levar à elevação de privilégios, pois um atacante de baixa privilégio pode substituir utilitários ou adicionar novos executáveis maliciosos.
Medidas de mitigação recomendadas para CISOs
Para mitigar esses riscos, as organizações devem adotar as seguintes práticas:
- Auditar configurações de imagem regularmente, verificando camadas e comandos de construção.
- Gerenciar segredos de forma segura, utilizando mecanismos de orquestrador (secrets) ou gerando senhas temporárias no momento da inicialização do container.
- Aplicar atualizações de segurança de forma oportuna, mas com verificação de integridade para evitar ataques à cadeia de suprimentos.
- Escanear o conteúdo das imagens para malware com cada atualização.
- Seguir as melhores práticas da indústria para aprimorar a segurança, como o uso de imagens oficiais e verificadas.
A implementação de soluções especializadas, como a Kaspersky Container Security, é essencial para garantir a segurança de aplicações containerizadas em todas as etapas de seu ciclo de vida, desde o desenvolvimento até a operação.
Perguntas frequentes
Por que as imagens de container são mais vulneráveis?
Porque elas são frequentemente construídas com base em imagens públicas que não recebem atualizações automáticas e podem conter configurações inseguras herdadas.
Como evitar a exposição de senhas em containers?
Nunca especifique senhas no Dockerfile. Use variáveis de ambiente seguras, secrets de orquestrador ou passe credenciais via arquivos de configuração com permissões restritas.
Qual é o risco de usar permissões 777?
Permissões 777 permitem que qualquer usuário modifique arquivos do sistema, facilitando a injeção de código malicioso e a elevação de privilégios.