A CVE-2026-34040 afeta ambientes que dependem de plugins AuthZ para decidir acesso com base no corpo da requisição à API do Docker, permitindo que uma requisição manipulada seja processada pelo daemon sem a mesma avaliação de autorização.
| Componente | Docker Engine com plugins de autorização AuthZ que inspecionam o corpo de requisições da API para tomar decisões de controle de acesso. |
| Vetor | Requisição especialmente construída à API do Docker, com corpo HTTP preenchido acima de 1 MB, enviada por um usuário ou processo que já possui acesso à API restrito por plugin AuthZ. |
| Impacto | Bypass de autorização em decisões baseadas no corpo da requisição, com possibilidade de criação de contêiner privilegiado e montagem do sistema de arquivos do host nas condições descritas. |
| Prioridade | Atualizar para Docker Engine 29.3.1, revisar dependência de plugins AuthZ que analisam o corpo HTTP e restringir o acesso à API do Docker pelo princípio do menor privilégio. |
| Versões | Correção disponibilizada no Docker Engine 29.3.1. |
| Referência técnica | CVE-2026-34040, classificada com CVSS 8.8, decorre de correção incompleta para CVE-2024-41110. |
A CVE-2026-34040 é uma vulnerabilidade de alta severidade no Docker Engine que afeta a integração entre o daemon do Docker e plugins de autorização, conhecidos como AuthZ. O problema ocorre quando o ambiente usa esse tipo de plugin para tomar decisões de controle de acesso com base no conteúdo do corpo de requisições enviadas à API do Docker. Nessas condições, uma requisição manipulada pode fazer com que o daemon encaminhe ao plugin uma versão sem o corpo necessário para a decisão, enquanto o próprio daemon ainda processa a requisição completa. O resultado é uma diferença crítica entre o que o mecanismo de autorização avalia e o que o Docker efetivamente executa.
A falha é ligada a uma correção incompleta da CVE-2024-41110, vulnerabilidade anterior no mesmo componente. A nova condição envolve corpos HTTP grandes, especialmente requisições de criação de contêiner com preenchimento acima de 1 MB. Em um cenário de ataque condicionado, um usuário, processo automatizado ou agente com acesso à API do Docker, mas limitado por um plugin AuthZ, pode enviar uma requisição que deveria ser bloqueada caso o plugin recebesse o corpo completo. Como a decisão de autorização fica cega para os campos relevantes, a requisição pode ser permitida e depois processada pelo daemon com todos os parâmetros originais.
O fluxo vulnerável depende de uma assimetria no tratamento de requisições grandes. Um plugin AuthZ normalmente recebe informações da requisição feita ao Docker daemon e decide se aquela operação deve prosseguir. Em ambientes que usam inspeção do corpo HTTP, campos como modo privilegiado, volumes montados, parâmetros de criação de contêiner ou acesso ao sistema de arquivos podem ser usados para negar operações perigosas. A CVE-2026-34040 rompe essa premissa: uma requisição com preenchimento artificial pode chegar ao plugin sem o corpo que contém justamente os elementos sensíveis, enquanto o daemon mantém capacidade de interpretar a solicitação integral e aplicar seus efeitos.
O cenário descrito envolve a criação de um contêiner privilegiado com acesso ao sistema de arquivos do host. A pré-condição não é acesso anônimo universal ao Docker; o atacante precisa conseguir falar com a API do Docker em um ambiente onde a política de autorização está sendo aplicada por plugin. O ponto de falha está no fato de que o plugin pode aprovar uma operação por falta de visibilidade, não por decisão explícita sobre os atributos reais da requisição. Depois disso, o daemon pode criar o contêiner com privilégios elevados e montar áreas do host, expondo arquivos sensíveis presentes na máquina, como credenciais de serviços em nuvem, chaves SSH ou configurações de Kubernetes, quando esses artefatos existirem no host acessível.
O caso também é relevante para fluxos modernos de desenvolvimento que usam agentes de IA em sandboxes baseadas em Docker. Um agente com permissão para acionar a API do Docker pode ser induzido por uma tarefa, por instruções escondidas em um repositório ou por tentativa de depuração a construir uma requisição que explore o comportamento de autorização. Esse ponto não altera a vulnerabilidade central: o gatilho continua sendo a requisição HTTP manipulada e o impacto continua condicionado ao acesso à API e ao desenho da política AuthZ. A diferença é que automações com autonomia operacional podem transformar uma falha de controle de acesso em um caminho indireto para criação de contêiner com capacidade maior do que a pretendida.
A superfície de maior risco está em hosts que executam Docker Engine com plugins AuthZ usados como barreira de segurança para a API. O risco aumenta quando a política de autorização depende da inspeção do corpo da requisição, porque a falha está justamente na ausência desse corpo na visão do plugin em determinadas condições. Ambientes de CI/CD, estáções de desenvolvimento, plataformas internas, sandboxes de agentes automatizados e servidores que expõem o Docker daemon a ferramentas de orquestração ou integração devem ser avaliados com atenção. A exposição não deve ser tratada apenas como problema de contêiner: quando um contêiner privilegiado monta o host, o limite de isolamento fica reduzido de forma significativa.
A correção está disponível no Docker Engine 29.3.1, que deve ser usado como referência para atualização. Até que a correção esteja implantada, controles compensatórios devem reduzir a dependência de plugins que tomam decisões a partir do corpo HTTP e limitar quem pode enviar requisições à API. A operação em modo rootless reduz o impacto porque o usuário root dentro do contêiner é mapeado para um UID sem privilégio equivalente no host. Para ambientes que não conseguem operar completamente em modo rootless, o remapeamento de namespace de usuário por --userns-remap oferece uma forma de reduzir o alcance de privilégios, embora não substitua a atualização do Docker Engine.
A análise da exposição precisa considerar tanto usuários humanos quanto identidades de máquina. Tokens de automação, runners de pipeline, serviços internos, agentes de IA, ferramentas de build e integrações que criam contêineres podem possuir acesso suficiente à API do Docker para acionar a condição. Mesmo quando esses componentes são considerados confiáveis, uma cadeia de execução influenciada por entrada externa, como repositórios, tarefas de depuração ou metadados de projeto, pode produzir requisições perigosas. A revisão deve mapear quem fala com o daemon, por qual transporte, com quais permissões e sob qual política AuthZ.
- Hosts com Docker Engine usando plugins AuthZ para decisões baseadas no corpo de requisições da API.
- Ambientes nos quais usuários, serviços, pipelines ou agentes automatizados possuem acesso à API do Docker, ainda que sob restrição de autorização.
- Sistemas em que a criação de contêiner privilegiado e montagem do host seriam bloqueadas apenas por inspeção do corpo HTTP.
A detecção deve começar pela auditoria de operações na API do Docker, especialmente chamadas de criação de contêiner com corpo HTTP incomumente grande ou com preenchimento sem função operacional aparente. Como o bypass depende da diferença entre a avaliação do plugin e o processamento do daemon, logs de autorização podem parecer benignos ou incompletos. Por isso, a correlação precisa juntar eventos do plugin AuthZ, eventos do daemon, criação efetiva de contêineres, parâmetros de privilégio, montagens de volumes e atividade posterior no host. Um evento permitido pelo plugin, seguido de criação de contêiner privilegiado que a política deveria negar, é um sinal forte de falha de controle.
No endpoint, defensores devem procurar contêineres recém-criados com modo privilegiado, montagens amplas do sistema de arquivos do host e leitura de diretórios associados a credenciais ou configurações operacionais. O foco não deve ser apenas o payload da requisição, que pode não estar disponível nos logs, mas o efeito produzido: contêiner com privilégios elevados, acesso a caminhos sensíveis e tentativas subsequentes de ler arquivos de identidade, nuvem ou Kubernetes. Em ambientes com agentes de IA ou automação de desenvolvimento, também é útil correlacionar tarefas recentes, repositórios processados e erros de acesso a arquivos que antecedam chamadas anômalas ao Docker daemon.
Em rede e identidade, a telemetria deve destacar origens incomuns de requisições à API do Docker, aumento de tamanho médio de corpos HTTP, sequências de tentativa e erro antes de uma criação bem-sucedida e uso de credenciais de automação fora do padrão esperado. Quando houver suspeita de leitura de material sensível no host, a investigação deve rastrear uso posterior de credenciais em serviços de nuvem, Kubernetes e SSH. Esse rastreamento deve ser tratado como validação de impacto condicionado, não como pressuposto automático de exfiltração, porque a vulnerabilidade em si confirma o bypass e a capacidade de acesso ao host nas condições descritas, mas não prova por si só uso posterior de credenciais.
Também é importante revisar a lacuna entre intenção de política e execução observada. Uma organização pode acreditar que seu plugin AuthZ bloqueia criação de contêiner privilegiado, montagem do host ou acesso a caminhos específicos, mas a vulnerabilidade permite que a decisão seja tomada sem os campos que descrevem essas ações. Testes defensivos controlados, sem comandos ofensivos reproduzíveis em produção, devem verificar se eventos sensíveis são negados e se logs registram o corpo ou metadados suficientes para auditoria. A ausência de visibilidade no plugin não deve ser interpretada como ausência de tentativa.
- Criação de contêineres privilegiados logo após requisições grandes ou atípicas à API do Docker.
- Divergência entre decisão permissiva do plugin AuthZ e operação que a política deveria negar.
- Montagens de diretórios do host em contêineres criados por identidades de automação, agentes ou usuários com acesso limitado.
- Leitura de arquivos associados a credenciais de nuvem, chaves SSH ou configurações de Kubernetes após criação de contêiner privilegiado.
A mitigação principal é atualizar o Docker Engine para a versão 29.3.1. Essa ação deve ter prioridade em hosts que combinam plugins AuthZ, acesso de automação à API e políticas baseadas em inspeção do corpo HTTP. Antes da atualização, ou quando a janela de mudança exigir controles temporários, a organização deve reduzir a exposição da API do Docker a identidades estritamente necessárias. A API não deve ser acessível por processos genéricos, ferramentas não inventariadas ou fluxos de desenvolvimento que processem conteúdo externo sem isolamento adicional. O princípio do menor privilégio deve ser aplicado tanto às credenciais quanto aos caminhos de comunicação com o daemon.
Também é necessário revisar o desenho das políticas AuthZ. Regras que dependem exclusivamente de campos presentes no corpo da requisição são frágeis diante dessa condição específica. Enquanto a atualização não estiver concluída, a recomendação defensiva é evitar depender de plugins que inspecionam o corpo para decisões críticas, especialmente bloqueios de modo privilegiado e montagens do host. O modo rootless deve ser avaliado como controle de redução de impacto, pois limita a equivalência entre root do contêiner e privilégio no host. Onde rootless não for viável, o remapeamento de namespace de usuário por --userns-remap pode diminuir o raio de impacto associado a contêineres com privilégios elevados.
A resposta operacional deve incluir inventário de plugins AuthZ instalados, identificação de hosts que aceitam requisições da API, revisão de identidades com permissão de criação de contêiner e análise de contêineres criados durante o período de exposição. Quando houver indício de montagem do host ou leitura de arquivos sensíveis, credenciais potencialmente acessadas devem ser rotacionadas de forma seletiva e verificável, priorizando chaves SSH, credenciais de nuvem e configurações de clusters Kubernetes presentes no host. A validação final deve confirmar que o Docker Engine está corrigido, que políticas críticas continuam funcionando e que automações não conseguem criar contêineres privilegiados fora do modelo esperado.
Ambientes com agentes de IA exigem um controle adicional: separar a capacidade de interpretar tarefas e repositórios da capacidade de acionar diretamente operações sensíveis no Docker daemon. Mesmo quando o agente atua em uma sandbox, permissões de criação de contêiner, montagem do host e acesso à API precisam ser tratadas como privilégios críticos. A contenção adequada combina atualização, rootless ou remapeamento de usuário, restrição de API, auditoria de chamadas e revisão de fluxos em que conteúdo externo pode influenciar ações de automação. Essa abordagem reduz tanto a exploração direta por um usuário com acesso limitado quanto cenários indiretos em que uma ferramenta automatizada constrói a requisição vulnerável.
- Atualizar hosts afetados para Docker Engine 29.3.1.
- Restringir o acesso à API do Docker a identidades e serviços estritamente necessários.
- Evitar dependência temporária de plugins AuthZ que tomam decisões críticas apenas pela inspeção do corpo HTTP.
- Executar Docker em modo rootless quando possível ou aplicar
--userns-remapcomo redução de impacto. - Revisar contêineres privilegiados recentes, montagens do host e possível acesso a credenciais locais.
0 Comentários