Uma vulnerabilidade de alta gravidade foi revelada no Docker Engine e pode permitir que um atacante burle plugins de autorização, conhecidos como AuthZ, em determinadas condições.
Identificada como
CVE-2026-34040
, com pontuação CVSS 8,8, a falha é resultado de uma correção incompleta aplicada ao
CVE-2024-41110
, uma vulnerabilidade de gravidade máxima no mesmo componente, descoberta em julho de 2024.
De acordo com os mantenedores do Docker Engine, em aviso publicado no fim do mês passado, um atacante pode usar uma requisição de API especialmente preparada para fazer com que o Docker daemon encaminhe a solicitação a um plugin de autorização sem o body.
Nesse cenário, o plugin pode aprovar uma requisição que normalmente negaria se o conteúdo completo tivesse sido repassado.
Isso afeta diretamente qualquer ambiente que dependa de plugins de autorização que analisam o body da requisição para tomar decisões de controle de acesso.
A falha foi descoberta e reportada de forma independente por vários pesquisadores, entre eles Asim Viladi Oglu Manizada, Cody, Oleh Konko e Vladimir Tokarev.
O problema foi corrigido na versão 29.3.1 do Docker Engine.
Segundo um relatório publicado por Tokarev, pesquisador da Cyera Research Labs, a vulnerabilidade existe porque a correção do
CVE-2024-41110
não tratou corretamente bodies HTTP grandes demais.
Isso abre espaço para um ataque em que uma única requisição HTTP com padding pode ser usada para criar um container privilegiado com acesso ao sistema de arquivos do host.
Em um cenário hipotético, um invasor com acesso restrito à Docker API por um plugin AuthZ pode contornar a proteção ao adicionar padding a uma requisição de criação de container para mais de 1 MB.
Com isso, a requisição seria descartada antes de chegar ao plugin.
“O plugin permite a requisição porque não vê nada para bloquear”, explicou Tokarev em relatório compartilhado com o The Hacker News.
“O Docker daemon processa a solicitação completa e cria um container privilegiado com acesso root ao host: suas credenciais da AWS, chaves SSH, configs do Kubernetes e tudo o mais na máquina.
Isso funciona contra qualquer plugin AuthZ do ecossistema.”
O problema também pode ser explorado em cenários que envolvem agentes de inteligência artificial.
Um agente de coding como o OpenClaw, executando dentro de um sandbox baseado em Docker, pode ser induzido a executar uma prompt injection escondida em um repositório do GitHub preparado de forma maliciosa.
Isso pode levar à execução de código malicioso que explora a
CVE-2026-34040
para burlar a autorização, criar um container privilegiado e montar o sistema de arquivos do host.
Com esse nível de acesso, o atacante pode extrair credenciais de serviços em nuvem e usá-las para assumir o controle de contas cloud, clusters Kubernetes e até acessar servidores de produção via SSH.
A Cyera também alerta que agentes de IA podem descobrir o bypass por conta própria e acioná-lo ao construir uma requisição HTTP com padding quando encontram erros ao tentar acessar arquivos como o kubeconfig durante uma tarefa legítima de depuração enviada por um desenvolvedor, como investigar um problema de falta de memória no Kubernetes.
Nesse caso, nem seria necessário plantar um repositório contaminado com instruções maliciosas.
“O plugin AuthZ negou a solicitação de montagem”, explicou a Cyera.
“O agente tem acesso à Docker API e sabe como HTTP funciona.
A
CVE-2026-34040
não exige exploit, privilégio ou ferramenta especial.
É uma única requisição HTTP com padding extra.
Qualquer agente que consiga ler a documentação da Docker API pode montá-la.”
Como medida temporária, a recomendação é evitar o uso de plugins AuthZ que dependam da inspeção do body da requisição para decisões de segurança, restringir o acesso à Docker API apenas a partes confiáveis com base no princípio do menor privilégio e, sempre que possível, executar o Docker em modo rootless.
“No modo rootless, até mesmo o ‘root’ de um container privilegiado é mapeado para um UID sem privilégios no host”, disse Tokarev.
“O impacto cai de ‘comprometimento total do host’ para ‘comprometimento de um usuário sem privilégios’.
Em ambientes que não podem migrar totalmente para rootless, o parâmetro --userns-remap oferece um mapeamento de UID semelhante.”
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...