DeepSeek Harness CVE-2026-82533: um agente em sandbox desativa o próprio sandbox com um único comando

A VulnCheck publicou a CVE-2026-82533 em 8 de setembro de 2026: um bypass de autenticação crítico que permitia a um agente de programação com IA desativar seu próprio sandbox com um único comando de shell. O software é o DeepSeek Harness, o runtime local de código aberto da DeepSeek para agentes de programação, que, segundo a Cloud Security Alliance, alcançou cerca de 215.000 estrelas no GitHub em poucas semanas; todas as versões anteriores a 0.1.2-alpha.1 são afetadas. Ele determinava se um chamador era local com base no próprio cabeçalho Host do chamador, então uma requisição podia alegar ser de loopback. Como seu sandbox restringia gravações de arquivos, mas não a rede de loopback, um agente confinado podia chamar a API de controle não autenticada do harness na porta 3080 e mudar sua sessão para danger-full-access com as aprovações desativadas. A VulnCheck atribui a ela a pontuação 9,4, crítica; não há alegação de exploração em ambiente real. O registro é uma entrada em um conjunto de dados público de incidentes de IA, e o Orca AI Incident Archive contém o conjunto completo de registros, com datas, graus de severidade e fontes para cada entrada.

A verificação que perguntou a uma requisição o que ela era

O componente vulnerável é a API local de controle de agentes do harness, o pequeno serviço HTTP que a interface web e a linha de comando usam para conduzir uma sessão em execução. De acordo com a nota de pesquisa da Cloud Security Alliance de 10 de setembro de 2026, que se baseia na análise da OX Security, a empresa que encontrou a falha, esse serviço escutava em 127.0.0.1 na porta 3080 por padrão e tomava sua decisão de confiança em uma função que a nota chama de isTrustedApiRequest. A função lia o cabeçalho HTTP Host e concedia acesso quando o valor correspondia a um nome de loopback, como localhost ou 127.0.0.1. Um cabeçalho Host é um metadado escrito pelo cliente; ele não diz nada sobre de onde veio a conexão TCP. O The Hacker News, citando o código-fonte afetado em 9 de setembro de 2026, relata que a verificação nunca olhava para a origem da conexão e que um comentário no mesmo arquivo diz que a verificação "não é uma camada de autenticação".

Isso é tudo o que o CWE-807 abrange, a dependência de entradas não confiáveis em uma decisão de segurança, e é o que o registro publicado da VulnCheck descreve: um cabeçalho Host de loopback fornecido pelo cliente aceito em vez de validar a origem real da conexão TCP.

O que transformou uma verificação falha em uma rota de fuga foi o harness entregar ao agente as suas próprias chaves. O Hacker News relata que o harness passa ao shell do agente o endereço da interface de controle e o identificador da sessão atual, de modo que um comando não precisa descobrir nenhum dos dois. O sandbox, por sua vez, cobria um canal e não o outro: a referência de linha de comando da versão afetada diz que, na configuração padrão, as gravações permanecem dentro do workspace e das pastas temporárias, enquanto leituras e acesso à rede não são confinados.

Por que as solicitações de aprovação não o impediram

O harness tinha, sim, prompts de aprovação, e eles não foram tanto contornados quanto inaplicáveis. O The Hacker News relata que, na versão afetada, a aprovação só era solicitada quando um comando buscava acesso mais amplo do que o que a sessão já detinha. A chamada de escalonamento não buscava nada desse tipo; ela alterava a configuração da sessão. Um agente que a executou passou para um modo que a OX Security chama de danger-full-access, com os prompts de aprovação definidos como nunca, e continuou em execução como o usuário que havia iniciado o harness, totalmente fora do sandbox.

As evidências da OX Security para o limite foram um par controlado. O Hacker News relata que a empresa executou duas sessões com configurações padrão idênticas e deu a ambas o mesmo comando: a sessão que fez a chamada gravou em uma pasta fora do seu espaço de trabalho, e a outra foi bloqueada.

O segundo caminho, e a pré-condição de que precisava

A mesma verificação ausente expôs o harness a chamadores que nunca estavam dentro de um sandbox, mas apenas sob uma condição que a configuração padrão não criava. A linha de comando se recusava a vincular a API a todas as interfaces de rede, de modo que a porta só era alcançável de outro lugar se um usuário já a tivesse encaminhado — por meio de um túnel, um proxy reverso, um encaminhamento SSH ou o próprio recurso de encaminhamento de portas de um editor, segundo o The Hacker News; a nota da Cloud Security Alliance lista o mesmo conjunto. Onde essa precondição se aplicava, afirma o aviso da VulnCheck, um chamador sem credenciais poderia criar sessões, executar comandos arbitrários e exfiltrar transcrições de conversas armazenadas. O The Hacker News acrescenta que a mesma interface atendia a uma solicitação que baixa todo o log de uma sessão.

A rota em sandbox precisa de uma pré-condição diferente: texto que o agente lerá e sobre o qual agirá. A nota da Cloud Security Alliance descreve um agente confinado lidando com um prompt fornecido pelo atacante incorporado em um comentário de código, um arquivo README ou texto de issue. Nenhuma das rotas exige uma chave roubada, e a nota observa que o caminho remoto não precisa de nenhuma interação com o modelo depois que a porta estiver exposta.

A população exposta é, portanto, qualquer pessoa que tenha executado o harness na versão 0.1.1-rc.2 ou anterior com as configurações padrão — um conjunto que a contagem de estrelas apenas sugere. O Hacker News contabilizou mais de 216.000 estrelas em 9 de setembro de 2026 e alertou que uma estrela é um marcador, e não uma instalação.

O que está estabelecido e o que não está

Estabelecido, a partir do próprio registro CVE: a VulnCheck é a autoridade de numeração, reservou o identificador em 29 de agosto de 2026 e publicou o registro em 8 de setembro às 16:59 UTC; a fraqueza é CWE-807; o intervalo afetado é todas as versões anteriores a 0.1.2-alpha.1; e o crédito vai para Nir Zadok e Moshe Siman Tov Bustan. As duas pontuações que o registro contém, 9.4 no CVSS 4.0 e 9.6 no CVSS 3.1, vêm da VulnCheck e não de um segundo avaliador independente — a NVD lista ambas as métricas com a VulnCheck como fonte —, portanto são uma única avaliação expressa em dois frameworks, e não duas avaliações concordantes.

Confirmado, a partir do repositório: o commit de correção 3e24087, intitulado "fix(web): authenticate the browser Host API", é datado de 24 de agosto de 2026 e adiciona um módulo de autenticação de navegador, juntamente com 210 linhas de testes de ponta a ponta para o novo fluxo, segundo a API do GitHub. A versão marcada como dsh-v0.1.2-alpha.1 veio em seguida, em 27 de agosto, às 17:06 UTC.

Não estabelecido: uso. Nem o registro CVE, nem o aviso da VulnCheck, nem as notas de lançamento da DeepSeek descrevem exploração na natureza, e o NVD registra a maturidade de exploração como não definida. O modelo EPSS do FIRST atribuiu à falha uma probabilidade de 1,24% de exploração nos 30 dias seguintes, no percentil 68,9, no feed datado de 27 de outubro de 2026. O arquivo não registra danos no mundo real para esta entrada e a classifica com confiança A, bem documentada, com fontes primárias em concordância.

As datas, incluindo dois relatórios que vieram primeiro

Dois desenvolvedores chegaram à mesma conclusão antes de existir um CVE a que apontar. O The Hacker News relata uma postagem no próprio fórum de discussão do projeto, em 13 de agosto de 2026, mostrando um processo ainda confinado pelo sandbox alcançando a interface local e alternando a sessão para danger-full-access, com a saída do teste, e uma segunda postagem, em 14 de agosto, listando as solicitações que essa interface aceitou sem credenciais. A segunda postagem também observava que o projeto não tinha arquivo de política de segurança nem um canal privado para relatar uma falha; o The Hacker News verificou em 9 de setembro e constatou que o arquivo de política de segurança ainda estava ausente.

A linha do tempo da OX Security situa seu relatório ao VulnCheck em 24 de agosto de 2026 — a mesma data que o GitHub registra para o commit de correção. A mensagem do commit não diz nada sobre o relatório, e o relato público da OX Security, conforme descrito pelo The Hacker News, não menciona as postagens anteriores da comunidade. O registro público não afirma se os dois eventos de 24 de agosto estavam conectados, e este artigo não presume que estivessem.

O intervalo entre a correção e a divulgação não é incomum. A nota da Cloud Security Alliance registra que a OX Security confirmou a correção em 30 de agosto, nove dias antes de a VulnCheck publicar a CVE.

Onde a correção foi aplicada, e onde não foi

A tag do GitHub e o registro de pacotes não avançaram juntos, e essa é a parte que vale a pena saber se você instalou o harness da forma como as instruções sugerem. O pacote de linha de comando, @deepseek-ai/dsh, publicou a 0.1.1-rc.2 em 21 de agosto de 2026 e depois nada até a 0.1.2-alpha.2 em 30 de agosto. A versão 0.1.2-alpha.1, a que a CVE aponta como a correção, está totalmente ausente do registro, então a primeira versão corrigida instalável saiu três dias depois da correção. Os metadados do registro npm foram consultados para este artigo em 28 de outubro de 2026; o The Hacker News noticiou a mesma lacuna em 9 de setembro.

As notas de versão não a apresentaram como uma versão de segurança. Elas listam, entre mudanças rotineiras, que a interface web agora exige autenticação por token de uso único para acesso à rede, sem referência a CVE e sem aviso de segurança, e {{1}}The Hacker News{{/1}} não encontrou nenhum aviso de segurança na lista de avisos do repositório em 9 de setembro. O mecanismo, como o {{2}}Cloud Security Alliance{{/2}} o descreve: o harness imprime um token de uso único na inicialização, o navegador troca esse token por um cookie assinado, e cada chamada subsequente deve apresentar o cookie — confiança vinculada a um segredo emitido na inicialização do processo, e não a uma origem de rede declarada.

As compilações de terceiros são a ponta solta. Os wrappers para desktop trazem sua própria cópia do harness, então qual versão um usuário está executando é escolha do mantenedor do wrapper; The Hacker News descobriu uma compilação para Windows fixada em 0.1.1-rc.2 no final de agosto que passou para 0.1.3-alpha.1, que contém a correção, em 6 de setembro.

O próprio sandbox permanece inalterado. Ao ler a referência de linha de comando 0.1.2-rc.1, o The Hacker News encontrou a mesma declaração de que leituras e acesso à rede não são confinados, e constatou que o shell do agente ainda recebe o endereço da interface. Nenhuma fonte nessa reportagem diz se um agente que trabalha dentro do seu workspace ainda consegue obter uma sessão válida no âmbito do novo esquema, uma questão que a própria documentação do patch deixa em aberto.

O que as fontes do registro recomendam

• Considere qualquer instalação na 0.1.1-rc.2 ou anterior como afetada, independentemente de como foi empacotada, incluindo uma cópia incorporada num wrapper de desktop.

Instale 0.1.2-alpha.2 ou posterior do npm; a versão mais recente no registro em 27 de outubro de 2026 era 0.2.2-alpha.2.

• Se não puder atualizar, pare a interface web quando ela não estiver em uso e remova qualquer túnel, proxy ou encaminhamento de porta que alcance a porta 3080.

• Verifique se a porta 3080 é acessível de qualquer origem que não seja o loopback, incluindo encaminhamento de portas de contêiner, proxies reversos e túneis SSH.

• Registre a escalada de privilégios e as alterações no modo de aprovação no nível do harness, porque o ataque funcionou ao fazer uma escalada não autorizada parecer uma atividade de rotina.

Todos os cinco vêm da nota da Cloud Security Alliance e da reportagem do The Hacker News; o registro do CVE em si não traz nenhuma orientação de remediação além da versão corrigida.

Por que a Cloud Security Alliance o interpreta como um padrão

A nota da Cloud Security Alliance coloca este CVE ao lado de outras duas falhas de contenção de agentes de codificação que documentou em 2026: GuardFall, em 1º de julho, na qual dez entre onze agentes de codificação de código aberto populares puderam ser induzidos a executar comandos shell que suas barreiras de proteção foram projetadas para bloquear, e as constatações de 22 de julho sobre transferência de confiança, nas quais um agente confinado gravou um arquivo que um componente confiável fora do sandbox executou posteriormente. A nota é explícita ao afirmar que as três decorrem de suas próprias pesquisas, e não de um levantamento exaustivo do mercado, e que não está estabelecido se o padrão se generaliza para além dos agentes examinados. O que ela argumenta é que as falhas residem em camadas diferentes — barreiras de comando, confiança a jusante e, agora, autenticação do plano de controle — e é por isso que recomenda tratar a arquitetura de sandbox como uma questão de contratação, e não como um requisito já atendido.

A própria documentação de segurança da DeepSeek não contradiz essa leitura. O SAFETY.md do repositório afirma que o software "não passou por uma auditoria de segurança e não deve ser tratado como seguro ou pronto para produção", e que sandboxing, prompts de aprovação e controles de permissão "não garantem isolamento nem previnem danos". A lacuna de autenticação que permitiu que um agente escapasse pela API de controle está fechada nas builds atuais. A assimetria que tornou a fuga curta — uma fronteira em torno das escritas e nada em torno da rede — continua sendo uma limitação declarada do sandbox, e não um defeito que o patch se propunha a corrigir.