Uma falha crítica no Docker Desktop para Windows e macOS abriu uma porta direta para fora do contêiner: qualquer workload malicioso podia “escapar” do isolamento e ganhar controle da máquina hospedeira. Pense no painel de controle do Docker como a sala de comando de um prédio — ele deveria ficar trancado, mas estava acessível de dentro de qualquer “quarto” (contêiner). Catalogada como CVE-2025-9074 (CVSS 9,3), a vulnerabilidade já foi corrigida na versão 4.44.3 do Docker Desktop. E um detalhe importante: ECI (Enhanced Container Isolation) não mitiga esse problema. Atualize agora.
A falha: uma API interna exposta e sem autenticação
O cerne do problema foi uma exposição não autenticada: em versões vulneráveis, qualquer contêiner conseguia falar com a API HTTP interna do Docker Engine no endereço interno padrão (por exemplo, 192.168.65.7:2375) sem precisar montar o socket e sem autenticação. Com isso, o invasor podia criar e iniciar contêineres privilegiados, montar volumes do host, gerenciar imagens e essencialmente fazer tudo que o próprio Docker pode fazer. Em resumo: o plano de controle estava visível para as cargas de trabalho que ele deveria isolar.
Mais preocupante ainda foi a simplicidade do exploit. Em alto nível, bastavam duas chamadas de API:
- /containers/create — para criar um contêiner privilegiado já mapeando um diretório do host;
- /containers/{id}/start — para iniciar e executar comandos com acesso ao que foi montado.
Nem era necessário executar código dentro do contêiner em alguns cenários: um SSRF num aplicativo vulnerável podia encaminhar essas requisições para a API interna.
O impacto: controle total do host no Windows
No Windows (com backend WSL2), o atacante podia montar o drive C: dentro de um contêiner privilegiado e, a partir daí, ler dados sensíveis ou até sobrescrever uma DLL do sistema para obter privilégios de administrador na máquina hospedeira. É a diferença entre um incidente pontual e um comprometimento completo do host.
No macOS, o impacto foi mais contido, mas ainda sério: há barreiras adicionais (por exemplo, prompts ao tentar montar diretórios do usuário) e o aplicativo não roda como administrador por padrão. Mesmo assim, o atacante podia assumir o controle de outros contêineres e até alterar a própria configuração do Docker Desktop (backdoor) em certas condições — suficiente para persistência e movimentação lateral no ambiente local de desenvolvimento.
Quem descobriu — e a lição por trás do “acaso”
A vulnerabilidade foi identificada por Felix Boulet, com colaboração e análise de Philippe Dugre. A história tem um quê de acaso: ao escanear a rede de dentro de um contêiner, Boulet encontrou a porta da API exposta. O lembrete é incômodo, mas necessário: interfaces internas não são seguras por definição. Se um endpoint de control-plane estiver acessível na rede “privada”, alguém vai encontrá-lo. Teste suposições de isolamento, segmente as redes e trate cada caminho de acesso como potencialmente hostil.
Por que isso importa (mesmo “só” no desktop)
No dia a dia, é comum rodar contêineres de terceiros no desktop — demos, ferramentas temporárias, imagens para testar IA ou SDKs. A Docker Desktop vulnerability mostrou que um único contêiner malicioso podia, em segundos, virar uma ponte para o seu host: arquivos do usuário, tokens, chaves SSH, repositórios de trabalho — tudo à mão com duas requisições HTTP. Para times de desenvolvimento, dados e produto, isso é risco operacional imediato.
Ação necessária: atualização urgente
- Atualize já para o Docker Desktop 4.44.3 (ou superior). Essa versão corrige a CVE-2025-9074. Após atualizar, reinicie o app e confira a versão nas notas de versão.
- Refine seu modelo de ameaça local:
– Nunca exponha endpoints de controle a workloads;
– Segmente a rede do Docker e trate o “interno” como não confiável;
– Evite rodar contêineres não confiáveis no desktop;
– Monitore tentativas de acesso ao endpoint interno do engine e bloqueie tráfego suspeito;
– Aplique zero-trust também ao ambiente local (incluindo permissões de arquivos e credenciais).
Nota: alguns relatos mencionam a ausência de programa formal de bug bounty para o Docker. Independentemente disso, o patch foi liberado rapidamente — e o que interessa agora é corrigir e reduzir a superfície de ataque.
