Falhas no Docker Sandboxes rompem isolamento e expõem o host: o que fazer agora

Duas vulnerabilidades corrigidas no Docker Sandboxes mostram que a microVM não encerra, por si só, a discussão sobre confiança. Em condições específicas, um guest controlado pode explorar diferenças entre validação e uso de caminhos para alcançar recursos do host que deveriam permanecer fora do sandbox.

O Docker Sandboxes foi desenhado para isolar agentes de IA e outros workloads potencialmente não confiáveis em microVMs. A proposta reduz a superfície de exposição em comparação com a execução direta no host, mas duas falhas divulgadas pela Flatt Security — CVE-2026-77179 e CVE-2026-79994 — demonstram que a segurança da fronteira depende também da forma como arquivos e sockets são resolvidos entre guest e host.

O problema não está no container: está na fronteira de confiança

As duas vulnerabilidades exploram uma classe de problema particularmente importante em ambientes de sandbox: o sistema verifica um caminho em determinado momento, mas depois utiliza esse caminho novamente sob condições que podem ter mudado. Essa diferença abre espaço para ataques envolvendo links simbólicos e condições de corrida do tipo TOCTOU, em que o objeto validado deixa de ser o mesmo objeto efetivamente acessado.

Na CVE-2026-77179, classificada como crítica no advisory do GitHub, o componente de compartilhamento de arquivos usado no Docker Sandboxes no macOS pode seguir um link simbólico quando reabre um arquivo. Segundo a análise técnica da Flatt Security, isso pode permitir que um processo malicioso dentro do sandbox escape da raiz exportada e alcance arquivos fora do workspace autorizado. O impacto descrito inclui leitura e modificação de arquivos do host com as permissões do processo VMM e, dependendo do que puder ser alterado, possibilidade de execução de código no contexto do usuário.

A CVE-2026-79994, classificada como alta, afeta o relay de sockets Unix. O caminho é inicialmente validado para confirmar que está dentro do workspace permitido, mas uma troca posterior por link simbólico pode fazer com que o host se conecte a outro socket AF_UNIX. O risco deixa de ser apenas acesso a arquivo: sockets locais podem representar interfaces privilegiadas e pontos de controle de outros serviços.

Por que o risco cresce com agentes de IA

O contexto torna as falhas especialmente relevantes. Docker Sandboxes é apresentado pelo próprio Docker como um mecanismo para executar agentes de IA em microVMs privadas, com filesystem e rede isolados. Um agente que recebe código, instruções, dependências e conteúdo de repositórios externos pode processar entradas que a organização não controla integralmente. Se a fronteira de isolamento for contornada, a autonomia que torna o agente útil também amplia o impacto potencial.

Isso muda o modelo mental de segurança. A pergunta deixa de ser apenas “o container está isolado?” e passa a incluir “quais recursos do host continuam alcançáveis caso o guest seja completamente comprometido?”. Credenciais, sockets, diretórios montados, tokens de desenvolvimento, chaves SSH, arquivos de configuração e serviços locais entram nessa análise.

Correção disponível e ausência de exploração pública conhecida

Os advisories do projeto indicam correção no Docker Sandboxes 0.42.0. Para a CVE-2026-77179, a orientação também aponta o uso do modo --clone como alternativa de mitigação quando a atualização imediata não for possível. Para a CVE-2026-79994, o advisory informa que não há workaround além da atualização.

Até a checagem realizada em 17 de setembro de 2026, não foi localizada evidência pública confiável de exploração ativa dessas duas CVEs em ataques reais. Isso não reduz a prioridade da correção: os detalhes técnicos estão públicos e as falhas atingem justamente um mecanismo criado para receber workloads que devem ser tratados como não confiáveis.

Controles técnicos: reduzir a confiança antes de aumentar a barreira

A primeira medida é atualizar o Docker Sandboxes para uma versão corrigida e inventariar onde o recurso está sendo usado. Mas patching é apenas o início. Workspaces montados no host devem ser reduzidos ao mínimo necessário; montagens de leitura e escrita precisam ser justificadas; credenciais não devem permanecer em diretórios acessíveis ao agente; e sockets locais devem ser considerados interfaces sensíveis, não simples arquivos.

O princípio do menor privilégio deve alcançar todo o caminho: usuário que executa o VMM, permissões do workspace, credenciais disponíveis, acesso à rede e serviços locais. Em ambientes de desenvolvimento, é comum que o usuário possua chaves, tokens de cloud, credenciais de repositórios e acesso a ferramentas administrativas. Uma falha de sandbox pode transformar esse conforto operacional em caminho de escalada.

Também é importante separar ambientes. Sandboxes destinados a código externo, automação experimental ou agentes com capacidade de executar comandos não deveriam compartilhar a mesma superfície de credenciais e serviços de uma estação administrativa. A segmentação deve considerar identidade, rede, filesystem e ciclo de vida das credenciais.

Governança: sandbox precisa de dono, política e evidência

Organizações que adotam agentes de IA e ambientes efêmeros precisam incorporar sandboxes ao inventário de ativos e ao processo de gestão de vulnerabilidades. A governança deve definir versões mínimas permitidas, política de atualização, quem pode criar mounts, quais diretórios podem ser expostos, quais serviços locais são proibidos e quais exceções exigem aprovação.

O monitoramento deve observar comportamento anômalo no host e não apenas dentro da microVM. Tentativas de acesso a caminhos inesperados, criação e troca de symlinks em alta frequência, conexões incomuns com sockets Unix e alterações em arquivos sensíveis são sinais que merecem telemetria. Para agentes autônomos, logs das ações executadas e rastreabilidade das permissões concedidas são controles de auditoria, não apenas recursos de troubleshooting.

Há ainda uma questão de arquitetura: sandbox não substitui política de identidade, gestão de segredos, EDR, hardening, segmentação ou revisão de supply chain. Ele é uma camada. Quanto mais autônomo for o workload, mais importante é assumir que essa camada poderá falhar e limitar o impacto da falha por desenho.

O que a equipe de segurança deve verificar agora

O primeiro passo é localizar instalações de Docker Sandboxes e confirmar a versão. Em seguida, mapear quais sandboxes recebem código, repositórios ou instruções externas; revisar mounts de host; identificar credenciais disponíveis ao usuário que executa o VMM; verificar exposição a sockets Unix; e validar se existe segregação entre ambientes experimentais e recursos administrativos.

Para organizações que já adotam agentes de IA, a revisão deve entrar no modelo de ameaça desses agentes. O controle relevante não é apenas impedir que um modelo “faça algo errado”, mas garantir que uma instrução maliciosa, dependência comprometida ou ferramenta explorada não atravesse a fronteira técnica e alcance recursos que nunca deveriam estar disponíveis.

Conclusão

As CVE-2026-77179 e CVE-2026-79994 são um lembrete de que isolamento é uma propriedade construída em camadas. A microVM melhora significativamente a separação, mas não elimina bugs na ponte entre guest e host. Quando o workload é deliberadamente tratado como não confiável — exatamente o cenário dos sandboxes para agentes — a arquitetura precisa presumir comprometimento e conter as consequências.

Referências

GBHackers — Docker Sandboxes Vulnerabilities Allow Attackers to Escape Workspace Isolation
Docker Sandboxes — CVE-2026-77179 / GHSA-4jfw-6cfq-j2gx
Docker Sandboxes — CVE-2026-79994 / GHSA-6×65-54p5-3pwx
Flatt Security — Security flaws in Docker Sandboxes
Docker Docs — Sandboxes