Código malicioso executado dentro de uma máquina virtual do Docker Sandboxes no macOS poderia escapar do diretório do projeto compartilhado com ela e ler ou alterar arquivos em qualquer outra área do host, alertou a Docker em um aviso de segurança publicado em 15 de setembro.
A fuga acontece com os privilégios da conta do host que executa a máquina virtual. A falha, identificada como
CVE-2026-77179
, foi classificada como Crítica, afeta versões da 0.28.0 até antes da 0.42.0 no macOS e foi corrigida na 0.42.0, em 7 de setembro.
O Docker Sandboxes executa cada agente de codificação de IA em sua própria pequena máquina virtual, com o diretório do projeto compartilhado. O código que poderia escapar é qualquer coisa que rode dentro dessa máquina, como um agente de codificação que tenha sido comprometido ou qualquer conteúdo malicioso que o agente instale e execute.
A Docker não informou casos de exploração. A avaliação adicionada pela CISA ao registro da CVE indica exploração como inexistente, e a falha não aparece no catálogo Known Exploited Vulnerabilities da agência, na versão publicada em 16 de setembro.
A falha exige código malicioso dentro do sandbox, e proteger o host do que o agente executa é justamente a função do sandbox. O agente instala pacotes e executa comandos com sudo dentro da máquina virtual, e a documentação de isolamento da Docker afirma que o limite imposto pelo hypervisor “é o controle de isolamento, não a separação de privilégios dentro da VM”.
A fuga ocorre pelo servidor host do virtio-fs, a parte do compartilhamento de arquivos entre o Mac e a máquina virtual que fica no lado do host, explicou a Docker. Segundo a empresa, o componente seguia symlinks quando reabria um arquivo removido a partir de um caminho armazenado.
Um convidado, ou seja, tudo o que roda dentro da máquina virtual, poderia substituir um diretório pai por um symlink e então ler ou alterar arquivos como usuário VMM, a conta do host sob a qual o monitor da máquina virtual é executado, disse a Docker, “potencialmente levando à execução de código no host”.
A documentação da Docker afirma desde março que symlinks que apontam para fora do workspace, termo da empresa para o diretório de projeto compartilhado, não são seguidos.
A mesma versão corrige uma segunda falha, a
CVE-2026-79994
, classificada pela Docker como Alta e com pontuação CVSS de 8,7, no relay que permite que um sandbox se conecte a sockets de domínio Unix dentro do workspace autorizado.
O relay verificava se o caminho de um socket estava dentro do workspace e, em seguida, reconectava usando o nome do caminho. Um convidado que trocasse um diretório ao longo desse caminho por um symlink entre a verificação e a conexão poderia fazer o host se conectar a qualquer socket AF_UNIX fora do workspace, informou a Docker, “expondo dados ou capacidades do lado do host fornecidas por esse socket”.
Essa falha afeta as versões 0.37.0 a 0.41.9, mas não a 0.42.0. A Docker lista a primeira falha como exclusiva do macOS, mas não informa plataforma para a segunda, embora o Docker Sandboxes funcione em hosts macOS, Windows e Linux. A avaliação da CISA também aponta exploração como inexistente, e a falha igualmente não está no catálogo KEV.
Versões afetadas e o que instalar
| CVE | Componente | Versões afetadas | Plataforma | Classificação da Docker |
|---|---|---|---|---|
|
CVE-2026-77179
| servidor host do virtio-fs | da 0.28.0 até antes da 0.42.0 | macOS | Crítica, CVSS 9,4 |
|
CVE-2026-79994
| relay de socket Unix do convidado para o host | da 0.37.0 até antes da 0.42.0 | não informada | Alta, CVSS 8,7 |
Atualize para a versão 0.42.0 ou posterior. Em 17 de setembro, a versão mais recente era a 0.43.0, publicada em 15 de setembro.
Se ainda não for possível atualizar, use o modo clone e evite adicionar montagens do host com permissão de leitura e escrita. Essa é a recomendação da Docker para as duas falhas.
Por padrão, o comando sbx run compartilha o diretório atual com o sandbox com acesso de leitura e escrita. O modo clone só funciona quando o projeto é um repositório Git e é definido no momento em que o sandbox é criado, de modo que um sandbox já existente precisa ser removido e recriado com --clone.
O modo clone protege o repositório contra alterações, mas não contra leitura. A documentação da Docker informa que o repositório é montado somente para leitura em /run/sandbox/source, e que arquivos não rastreados, como .env, continuam legíveis dentro do sandbox.
A Docker publicou os registros das CVEs e o aviso em 15 de setembro, oito dias depois do lançamento da 0.42.0.
As notas da versão 0.42.0 no GitHub e no site de documentação da Docker não citavam nenhuma das CVEs até 17 de setembro. Entre as correções rotineiras, elas mencionam uma em que “um processo isolado poderia fazer o daemon abrir um transporte D-Bus do host e executar um comando arbitrário no host”. A Docker não associou essa correção a nenhuma das CVEs.
O registro da
CVE-2026-79994
inicialmente indicava a 0.41.0 como primeira versão corrigida e trazia um link para uma página de lançamento da 0.41.0 que não existia. A Docker corrigiu ambos para 0.42.0 cerca de uma hora depois de publicar o registro, em 15 de setembro.
A Docker credita Oren Yomtov, da accomplish.ai, pela descoberta da
CVE-2026-77179
, e Jurre van Bergen, da ThreatNotify, pela descoberta da
CVE-2026-79994
.
Em abril, a Cyera Research Labs descreveu como um agente de codificação com 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.
Publicidade
Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...