CVE-2026-77179 permite que código dentro da máquina virtual escape do diretório de projeto compartilhado e aja com os direitos da conta que executa o VMM; correção saiu na versão 0.42.0
| Componente | Docker Sandboxes no macOS, servidor virtio-fs e relay de Unix domain sockets |
| Vetor | Código malicioso dentro da VM do sandbox substitui diretório pai por symlink e força reabertura de arquivo removido ou reconexão de socket |
| Impacto | Leitura e modificação de arquivos fora do workspace com privilégios do VMM, acesso a sockets AF_UNIX fora do workspace e potencial execução de código no host |
| Prioridade | Atualizar para 0.42.0 ou posterior (mais recente: 0.43.0); como contenção provisória, usar clone mode e evitar montagens read-write |
| Versões | CVE-2026-77179: 0.28.0 até menor que 0.42.0 (macOS). CVE-2026-79994: 0.37.0 até 0.41.9 (CVSS 8,7). Corrigidas em 0.42.0 |
| Mitigação | Atualizar para 0.42.0 ou 0.43.0; usar clone mode; remover montagens de leitura e escrita do host; recriar sandboxes existentes com --clone |
O Docker divulgou, em 15 de setembro, um aviso de segurança sobre duas vulnerabilidades no Docker Sandboxes, produto que executa cada agente de codificação por IA em uma máquina virtual pequena e isolada, com o diretório do projeto compartilhado para dentro do ambiente. A falha mais grave, identificada como CVE-2026-77179 e classificada como Critical, afeta as versões 0.28.0 até menores que 0.42.0 em hosts macOS e permite que código malicioso em execução dentro da máquina virtual escape do diretório compartilhado e leia ou modifique arquivos em qualquer ponto do host, com os direitos da conta sob a qual roda o monitor de máquina virtual (VMM), potencialmente levando à execução de código no host.
A correção foi disponibilizada na versão 0.42.0, lançada em 7 de setembro, oito dias antes da publicação do aviso e dos registros de CVE. A mesma versão corrige uma segunda falha, CVE-2026-79994, avaliada como High pela empresa com pontuação CVSS 8,7, que afeta o relay responsável por permitir que um sandbox se conecte a Unix domain sockets dentro do workspace autorizado. Até 17 de setembro, a avaliação da CISA registrava exploração como inexistente para ambas as falhas, e nenhuma das duas constava no catálogo Known Exploited Vulnerabilities. O Docker também não relatou exploração em campo.
O escape da primeira falha ocorre no servidor virtio-fs, o componente no lado do host responsável pelo compartilhamento de arquivos entre o macOS e a máquina virtual. Segundo a análise divulgada, esse servidor seguia symlinks ao reabrir um arquivo removido a partir de um caminho armazenado. Um guest — qualquer código em execução dentro da máquina virtual — podia substituir um diretório pai por um symlink e, assim, ler ou alterar arquivos como o usuário do VMM, a conta do host sob a qual o monitor de máquina virtual executa. O impacto prático é que qualquer processo dentro do sandbox, incluindo um agente de codificação manipulado por prompt injection ou qualquer dependência maliciosa que ele instale e execute, poderia alcançar arquivos fora do projeto com os privilégios dessa conta.
A segunda falha, CVE-2026-79994, explora uma janela de competição no relay de sockets. O componente validava se o caminho do socket estava dentro do workspace e, em seguida, reconectava usando o nome do caminho. Se um guest substituísse um diretório ao longo desse caminho por um symlink entre a verificação e a conexão, o host passava a se conectar a qualquer socket AF_UNIX fora do workspace, expondo dados ou capacidades do lado do host oferecidas por esse socket. A documentação do Docker já afirmava, desde março, que symlinks apontando para fora do workspace não são seguidos — comportamento que estas falhas violavam na prática. Vale notar que a documentação de isolamento do produto é explícita ao definir que o limite do hipervisor é o controle de isolamento, e não a separação de privilégios dentro da VM, o que torna a fronteira do virtio-fs o ponto crítico de defesa.
A primeira falha é listada pelo Docker como exclusiva do macOS, enquanto a segunda não teve plataforma declarada, embora o Docker Sandboxes rode em hosts macOS, Windows e Linux. O vetor pressupõe código malicioso já em execução dentro do sandbox, o que é precisamente o cenário que o produto tenta conter: agentes de codificação que instalam pacotes e executam comandos com sudo dentro da máquina virtual. Por padrão, o comando sbx run compartilha o diretório corrente para dentro do sandbox com acesso de leitura e escrita, ampliando a superfície quando o escape é possível.
O clone mode, alternativa de compartilhamento, só funciona quando o projeto é um repositório Git e precisa ser definido na criação do sandbox — ambientes existentes devem ser removidos e recriados com a opção --clone. Importante para avaliação de risco: o clone mode protege o repositório contra alterações, mas não contra leitura. O código é montado somente para leitura em /run/sandbox/source, e arquivos não rastreados pelo Git, como o .env, permanecem legíveis dentro do sandbox, mantendo exposição de segredos locais mesmo com a proteção ativida.
- CVE-2026-77179: versões 0.28.0 até menores que 0.42.0, apenas macOS
- CVE-2026-79994: versões 0.37.0 até 0.41.9; 0.42.0 não é afetada
- Compartilhamento padrão via sbx run concede leitura e escrita no diretório atual
- Clone mode monta o repositório read-only, mas arquivos não rastreados como
.envcontinuam legíveis
Para equipes que operam Docker Sandboxes em estações de desenvolvimento, a investigação deve começar pelo inventário de versões instaladas e pela identificação de sandboxes criados antes da atualização, incluindo aqueles com montagens read-write do host. Como as falhas exigem código malicioso dentro da máquina virtual, a telemetria relevante está nas ações do agente dentro do sandbox: instalação de pacotes incomuns, execução de comandos com sudo e, sobretudo, qualquer tentativa de acesso a caminhos fora do workspace compartilhado.
No lado do host, vale monitorar processos do VMM acessando arquivos fora dos diretórios de projeto, criação ou substituição de symlinks em caminhos usados pelo compartilhamento virtio-fs e conexões do host a Unix domain sockets fora do workspace. Ambas as avaliações de exploração permanecem como nenhuma até 17 de setembro, de modo que sinais de uso malicioso ainda indicariam atividade pioneira e merecem tratamento prioritário. Um precedente relevante: em abril, uma pesquisa descreveu como um agente de codificação vítima de prompt injection dentro de um sandbox baseado em Docker poderia ser induzido a explorar uma falha separada do Docker Engine contra o próprio host, cenário que ilustra o risco real de agentes manipulados como vetor inicial.
- Inventariar instalações do Docker Sandboxes entre 0.28.0 e 0.41.9
- Monitorar acessos do processo VMM a caminhos fora do workspace
- Detectar substituição de diretórios pai por symlinks dentro do compartilhamento virtio-fs
- Observar conexões do host a sockets AF_UNIX fora do workspace autorizado
- Revisar histórico de comandos e pacotes instalados por agentes dentro de sandboxes
A ação primária é atualizar para 0.42.0 ou posterior; a versão mais recente até 17 de setembro é a 0.43.0, publicada no mesmo dia do aviso. Ambas as vulnerabilidades estão corrigidas a partir de 0.42.0. O registro da CVE-2026-79994 chegou a listar 0.41.0 como primeira versão corrigida e vinculava uma página de release inexistente; o Docker corrigiu ambas as informações cerca de uma hora após a publicação, o que reforça a necessidade de validar a versão de correção diretamente na plataforma instalada.
Para ambientes que não possam atualizar imediatamente, a recomendação do Docker para as duas falhas é usar clone mode e evitar adicionar montagens de leitura e escrita do host. Como o clone mode precisa ser definido na criação do sandbox, sandboxes existentes devem ser removidos e recriados com a opção apropriada. Vale registrar ainda que as notas de versão da 0.42.0 não nomeiam nenhuma das CVEs, mas listam, entre correções rotineiras, a correção de um problema em que um processo no sandbox poderia fazer o daemon abrir um transporte D-Bus do host e executar um comando arbitrário no host — conexão que o próprio Docker não estabeleceu com nenhuma das duas falhas. A descoberta da CVE-2026-77179 é creditada a Oren Yomtov, da accomplish[.]ai, e a da CVE-2026-79994, a Jurre van Bergen, da ThreatNotify.
- Atualizar o Docker Sandboxes para 0.42.0 ou 0.43.0
- Recriar sandboxes existentes com clone mode quando a atualização não for imediata
- Remover montagens de leitura e escrita do host nos compartilhamentos
- Tratar arquivos não rastreados como
.envcomo legíveis dentro do sandbox mesmo em clone mode - Verificar a numeração de versão de correção diretamente no registro atualizado do CVE
0 Comentários