DeepSeek Harness permitiu que um invasor em um ambiente de sandbox executasse comandos arbitrários apenas alterando o cabeçalho HTTP Host para 127.0.0.1, o que resulta em uma pontuação de 9.4 na escala CVSS. A falha mostra como uma única decisão de confiança equivocada pode transformar uma barreira de proteção em uma porta de entrada aberta.
Como o bug passou despercebido
O código vulnerável reside em uma única função que lê o cabeçalho Host da requisição e, se o valor for igual ao endereço de loopback, trata a requisição como se viesse da máquina local.
Um invasor que consiga executar código dentro do sandbox não precisa de um payload sofisticado. Ao enviar uma requisição HTTP com Host: 127.0.0.1, o backend acredita que a chamada se origina do próprio host e pula todos os avisos de segurança, verificações de limite de taxa (rate-limit) e etapas de validação de comando. O resultado: execução de comandos irrestrita sem a necessidade de qualquer interação adicional.
Por que confiar em cabeçalhos é perigoso
Cabeçalhos são strings de texto simples fornecidas pelo chamador. Quer o campo se chame Host, X-Forwarded-For ou qualquer outro nome personalizado, o cliente pode defini-lo com o valor que desejar. A única fonte de verdade confiável sobre a origem real de uma conexão é a camada de transporte – o endereço IP de origem do socket que o sistema operacional registra quando o handshake TCP é concluído.
Quando uma aplicação decide confiar em um cabeçalho sem confirmar que um proxy conhecido e configurado corretamente o injetou, ela entrega as chaves do reino ao invasor. O bug do DeepSeek Harness é um exemplo clássico desse erro.
Impacto no mundo real: o exemplo do shell.online
O projeto de código aberto shell.online, que oferece um terminal baseado na web, documentou recentemente a mesma armadilha. Ele utiliza uma flag de configuração chamada TRUST_PROXY:
- TRUST_PROXY = 0 – o app ignora o cabeçalho X-Forwarded-For e depende do endereço remoto do socket. Isso impede que um cliente forje um endereço IP para burlar limites de taxa ou se passar por um usuário confiável.
- TRUST_PROXY = 1 – o app confia no cabeçalho X-Forwarded-For como a identidade do cliente. Se o serviço não estiver atrás de um proxy real que sanitize este cabeçalho, um invasor pode fornecer um novo endereço IP em cada requisição, resetando efetivamente qualquer limitação (throttling) por IP.
O bug do DeepSeek reflete esse cenário: o código confiava no Host como se um proxy o tivesse definido, mas o serviço podia ser acessado diretamente.
O que os desenvolvedores precisam fazer agora
- Audite todos os locais onde você lê cabeçalhos fornecidos pelo cliente. Identifique quais cabeçalhos você trata como autoritativos (ex: Host, X-Forwarded-For, X-Real-IP) e verifique se há a garantia de que um proxy confiável os reescreverá antes de chegarem à sua aplicação.
- Vincule as decisões de segurança ao endereço do socket sempre que possível. Use o IP de origem fornecido pelo SO para autenticação, limites de taxa e verificações de controle de acesso.
- Ative flags de confiança de proxy apenas quando um proxy reverso configurado corretamente estiver à frente do serviço. Se você executar o app diretamente, mantenha essas flags desativadas.
- Documente a topologia de implantação necessária no README ou no guia de implantação do seu projeto, para que os usuários que fazem o self-hosting saibam sobre o requisito de confiança do proxy.
- Execute ferramentas de análise estática ou revisão de código que sinalizem o uso direto de cabeçalhos para decisões de segurança sem a lógica de validação de proxy correspondente.
O que observar a seguir
Comunidades que disponibilizam serviços web para self-hosting provavelmente revisarão suas próprias configurações de confiança de proxy após este incidente.
A lição principal é clara: nunca deixe que um pedaço de texto que qualquer pessoa na internet pode escrever dite a postura de segurança do seu sistema. Confie na camada de rede, não na camada de requisição.