Docker em risco: CVE-2026-34040 permite bypass de AuthZ e exposição de segredos com uma única petição HTTP inflada

Recentemente, tornou-se pública uma vulnerabilidade de alta gravidade em Docker Engine que, em determinadas condições, permite contornar os plugins de autorização (AuthZ) e conseguir que o demônio de Docker realize ações que deveriam ter sido bloqueadas. Identificada como CVE-2026-34040 e valorada com uma pontuação CVSS de 8.8, a falha nasce de uma correção incompleta aplicada após uma incidência anterior no mesmo componente, vinculada a CVE-2024-41110. Para quem administra ambientes com Docker, isso não é apenas uma falha técnica: é uma porta de entrada que pode derivar na exposição de credenciais e na tomada de controle de recursos na nuvem e clusters de Kubernetes.

Em termos simples, o problema ocorre quando um pedido HTTP especialmente manipulado — com um corpo muito grande — faz com que o demônio de Docker reenvie o pedido a um plugin de autorização sem incluir esse corpo. Se o plugin basear a sua decisão de permitir ou recusar a operação no conteúdo do pedido (por exemplo, na configuração de criação de um contentor), e receber um pedido vazio, você pode conceder permissões normalmente recusadas. Depois de aceitar a operação, o servidor processa a versão completa e devidamente preenchida do corpo e acaba criando, por exemplo, um contentor privilegiado com acesso ao sistema de arquivos do anfitrião.

A raiz da vulnerabilidade está associada a como o adesivo anterior foi tratado para a vulnerabilidade de 2024: a correção não contemplou adequadamente corpos de petição acima de um certo limiar (cerca de 1 MB), o que permitiu um cenário em que um único pedido HTTP "inflada" pode terminar criando um contentor com privilégios de host. Pesquisadores que participaram do achado e da divulgação do problema incluem várias pessoas e instituições que informaram de forma independente, e a correção foi publicada na versão Docker Engine 29.3.1.

Mais preocupante ainda é a possibilidade de agentes de codificação baseados em inteligência artificial, que operam dentro de sandboxes Docker (por exemplo, assistentes que automatizam tarefas de desenvolvimento), poderem ser manipulados para executar uma cadeia de ações que resulte neste bypass. Um repositório de código com instruções maliciosas ocultas ou mesmo um agente que, de forma autônoma, tente resolver uma falha (por exemplo, aceder a um kubeconfig para depurar um problema) poderia construir a petição acolchada que desencadeia a vulnerabilidade sem necessidade de código de exploração sofisticado. Em outras palavras, qualquer entidade com acesso à API do Docker e conhecimento básico de HTTP poderia reproduzir o bypass: não são necessárias ferramentas avançadas ou privilégios adicionais para além do acesso já utilizado em um fluxo legítimo.

O impacto potencial é grave. Com um recipiente privilegiado e o sistema de arquivos do host montado, um atacante pode extrair chaves SSH, credenciais de acesso a fornecedores de nuvem, arquivos de configuração de Kubernetes e outros segredos que permitam escalar o compromisso até contas na nuvem, clusters inteiros ou servidores de produção. Por isso, a recomendação mais urgente é atualizar a versão patchada do Docker Engine o mais rapidamente possível e revisar a exposição da API do Docker em seus sistemas.

Como medidas imediatas enquanto a atualização é exibida, recomenda-se evitar depender de plugins de autorização cuja lógica se baseie em inspecionar o corpo dos pedidos para tomar decisões críticas, e aplicar o princípio de menor privilégio no acesso à API do Docker: restringir apenas atores confiáveis e minimizar quais credenciais/roles podem usá-lo. Além disso, a execução do Docker em modo rootless reduz drasticamente a superfície de ataque, uma vez que o "root" dentro de um recipiente deixa de corresponder ao utilizador root do sistema anfitrião; para ambientes onde não é viável uma mudança completa, a remapificação de utilizadores com opções como o --userns-remap oferece uma mitigação parcial que reduz o impacto de um contentor comprometido.

Se você quiser consultar fontes oficiais e ampliar detalhes técnicos, convém revisar a documentação e avisos de segurança do Docker em seu site oficial, a cobertura de meios especializados que seguiram a divulgação e a análise técnica publicada por equipes de pesquisa em cibersegurança. Podemos começar pela página de segurança do Docker em https://docs.docker.com/engine/security/, onde se anunciam boletins e notas de versão; documentação sobre execução sem privilégios em https://docs.docker.com/engine/security/rootless/ e sobre remapeamento de usuários; o portal de vulnerabilidades e bases de dados públicas como NVD (National Vulnerability Database) ou MITRE CVE para seguir os identificadores oficiais; e as análises de equipamentos independentes que investigaram a técnica de exploração e suas implicações.

Esta classe de erros sublinha duas lições importantes para equipamentos de engenharia e segurança: primeiro, as correcções rápidas e incompletas em componentes críticos podem deixar impressões exploráveis que aparecem mais tarde em forma de bypasses; segundo, o boom de ferramentas automatizadas e agentes AI introduz novos vectores que combinam erros clássicos de segurança com comportamentos autónomos imprevisíveis. Manter atualizado, reduzir a superfície de exposição e repensar a confiança em mecanismos que inspecionem conteúdos transmitidos pela rede são medidas-chave para reduzir o risco até que todas as máquinas do parque estejam protegidas.