Uma falha no DeepSeek Harness, ferramenta open source da DeepSeek para executar agentes de codificação com IA na máquina de um desenvolvedor, permitia que um agente dentro de um sandbox desativasse o próprio isolamento com um único comando.
A ferramenta executa os comandos do agente em um sandbox do sistema operacional, para que um agente trabalhando com arquivos não confiáveis não consiga gravar fora do seu espaço de trabalho. O agente podia remover essa restrição chamando a própria interface web da ferramenta na mesma máquina e, então, seus comandos passavam a ser executados fora do sandbox, sem solicitação de aprovação.
O problema funcionava em uma instalação padrão até a DeepSeek corrigir a ferramenta em 27 de agosto e dependia de texto fornecido pelo atacante, que o agente lia antes de ser induzido a fazer a chamada.
A falha está registrada como
CVE-2026-82533
. A VulnCheck, responsável por atribuir o identificador, publicou o registro em 8 de setembro e classificou a falha com nota 9,4 de 10.
A OX Research, empresa de segurança que relatou a falha, afirmou que bastava um único comando de shell. O comando acionava a interface local da ferramenta e colocava a sessão do agente em um modo chamado danger-full-access, que desativa o sandbox e interrompe os pedidos de aprovação.
Os comandos comuns já não precisavam de aprovação desde o início. A aprovação só era aplicada quando um comando solicitava acesso mais amplo do que a sessão já tinha, e essa chamada não pedia isso. Ela apenas alterava a configuração da sessão.
A OX informou que verificou que o sandbox estava funcionando antes da fuga. A empresa executou duas sessões com as mesmas configurações padrão e enviou o mesmo comando para ambas. A sessão que fez a chamada gravou em uma pasta fora do seu espaço de trabalho, enquanto a outra foi bloqueada.
O sandbox cobre apenas arquivos. A documentação de linha de comando da versão afetada informa que, na configuração padrão, as gravações permanecem dentro do espaço de trabalho e das pastas temporárias, enquanto “leituras e acesso à rede não são confinados”.
Isso deixava a própria interface da ferramenta acessível de dentro do sandbox. A ferramenta também fornece ao shell do agente o endereço dessa interface e o identificador da sessão em andamento, de modo que o agente não precisa procurá-los.
A interface não tinha autenticação. Na versão afetada, a verificação que determinava se uma solicitação poderia alcançá-la lia o cabeçalho Host da requisição e nunca examinava de onde a conexão havia se originado. Um comentário nesse arquivo diz que a verificação “não é uma camada de autenticação”.
Essa é a checagem descrita no registro do CVE. Como ela confiava em um cabeçalho fornecido pelo cliente, uma máquina externa podia se passar por local e controlar o agente. A linha de comando da ferramenta se recusava a escutar em todas as interfaces de rede, então o acesso externo exigia que o usuário tivesse encaminhado ou proxied a porta por meio de um túnel, de um redirecionamento SSH ou de um editor.
A mesma interface também atendia a uma solicitação para baixar o log completo de uma sessão. O comunicado da VulnCheck afirma que qualquer pessoa que conseguisse alcançar a interface poderia recuperar todos os históricos de conversas armazenados, sem necessidade de chave.
Versões afetadas e o que instalar
As versões 0.1.1-rc.2 e anteriores são afetadas. O registro aponta a 0.1.2-alpha.1 como a versão corrigida, mas essa versão nunca foi publicada no registro do npm, que é justamente o destino indicado pelas instruções do próprio projeto.
| Versão | Status | Lançamento |
| --- | --- | --- |
| 0.1.1-rc.2 e anteriores | Afetada | 0.1.1-rc.2 publicado em 21 de agosto |
| 0.1.2-alpha.1 | Corrigida, apenas no GitHub | 27 de agosto, não disponível no npm |
| 0.1.2-alpha.2 | Primeiro lançamento corrigido no npm | 30 de agosto |
| 0.1.2-rc.1 | Versão atual no npm, com a correção | 3 de setembro |
O Hacker News verificou o registro do npm em 9 de setembro e encontrou que o primeiro lançamento publicado com a mudança de autenticação é a 0.1.2-alpha.2, três dias depois de a correção ter sido enviada ao GitHub.
Instale a versão 0.1.2-alpha.2 ou posterior. A versão atual no registro é a 0.1.2-rc.1.
Se a instalação foi feita por meio de um aplicativo de desktop de terceiros, verifique qual versão do harness ele inclui.
Se não for possível atualizar, desligue a interface web quando não estiver usando e remova qualquer túnel, proxy ou redirecionamento de porta que a alcance.
Nenhuma das fontes revisadas para esta reportagem oferece uma forma de impedir a fuga de dentro do sandbox em uma instalação local padrão enquanto a ferramenta estiver em execução. O relatório de 13 de agosto diz que limitar o endereço no qual a ferramenta escuta não ajuda, porque o agente já está na mesma máquina.
A correção adiciona uma verificação de identidade à interface. Agora a ferramenta exibe um token de uso único no endereço de inicialização; o navegador troca esse token por um cookie assinado, e cada chamada à interface exige esse cookie.
O que a correção não altera é o sandbox. Na 0.1.2-rc.1, a mesma documentação ainda informa que leituras e acesso à rede não são confinados, e o shell do agente continua recebendo o endereço da interface. Nenhuma fonte informa se um agente executando dentro do seu espaço de trabalho ainda pode obter uma sessão válida no novo esquema.
As versões de desktop de terceiros trazem sua própria cópia do harness, e a versão distribuída depende da decisão do mantenedor do pacote. Uma versão para Windows manteve a 0.1.1-rc.2 no fim de agosto e migrou para a 0.1.3-alpha.1, que traz a correção, em 6 de setembro. Quem instalou o harness por meio de um wrapper deve verificar qual versão ele distribui.
Vale atacar um harness de agente de codificação porque ele tem acesso a um shell. O DeepSeek Harness executa os comandos do agente com a conta que o iniciou.
O próprio aviso de segurança do projeto afirma que o software não passou por uma auditoria de segurança e que o sandbox e os pedidos de aprovação “não garantem isolamento nem evitam danos”. O texto orienta os usuários a não tratar a ferramenta como única medida de segurança para trabalhos não confiáveis.
O repositório tinha mais de 216.000 estrelas em 9 de setembro, um número de contas que o marcaram como favorito, e não de instalações.
Pesquisadores têm encontrado repetidamente agentes de codificação escapando de seus sandbox este ano, incluindo um conjunto de falhas em que a própria configuração de um repositório fazia os agentes executarem código de atacante fora do isolamento.
Relatos da comunidade descreveram a mesma fuga em agosto
Dois desenvolvedores descreveram a mesma fuga no próprio fórum de discussões da DeepSeek antes de o CVE existir. Em 13 de agosto, um deles publicou um relato mostrando um processo ainda contido pelo sandbox acessando a interface local e, em seguida, mudando a sessão para danger-full-access, com saída de teste.
Em 14 de agosto, outro publicou um relato sobre a mesma interface, listando as requisições que ela aceitava sem qualquer credencial.
Esse segundo relato também observou que o projeto não tinha um arquivo de política de segurança nem um canal privado para reportar falhas. O projeto ainda não tem arquivo de política de segurança.
A OX Research relatou a falha à VulnCheck em 24 de agosto, segundo sua própria linha do tempo, e a VulnCheck credita Nir Zadok e Moshe Siman Tov Bustan. A publicação da OX não menciona os relatos anteriores.
O Hacker News verificou a lista de avisos do repositório em 9 de setembro e não encontrou nenhum aviso de segurança publicado. A versão que trouxe a correção a lista entre mudanças rotineiras, como a remoção de um transporte antigo e a exigência de “autenticação por token de uso único para acesso à rede”, sem aviso de segurança e sem menção ao CVE.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...