Rejetto HFS: uma chave previsível derruba a fronteira da sessão

A VulnCheck detectou tentativas de exploração da CVE-2026-61500 no Rejetto HTTP File Server, com CVSS 9,3 e intervalo afetado de HFS 3.0.0 a 3.2.0.[2] A correção inicial saiu em julho de 2026, no HFS 3.2.1, mas foram observadas tentativas contra hosts vulneráveis reais em 01/10/2026.[2]

O caso merece atenção porque a falha não termina em uma sessão indevida.[2] Ela conecta geração de segredo, autenticação administrativa e uma função capaz de executar código.[2] Para quem desenvolve, revisar cada peça isoladamente pode esconder a gravidade da combinação.

O que muda para quem desenvolve

Segundo a reportagem, nas versões afetadas, o HFS usa Math.random() para gerar a chave de assinatura dos cookies e expõe saídas do mesmo gerador no fluxo de login acessível sem autenticação.[2] Essa combinação permite inferir o estado do gerador, recuperar a chave e produzir um cookie administrativo válido.[2]

Depois de contornar a autenticação, o atacante pode abusar de server_code, funcionalidade legítima que executa JavaScript no servidor.[2] A cadeia pode, portanto, chegar à execução remota de código, não apenas ao acesso a arquivos.[2]

A lição de arquitetura é desconfiar de fronteiras que compartilham a mesma premissa de segurança. Uma função administrativa poderosa exige autenticação confiável, mas também merece controles próprios. Se toda a proteção depende de um cookie, a revisão precisa perguntar o que acontece quando esse cookie deixa de ser confiável.

Para este caso, Math.random() não oferece a aleatoriedade criptográfica necessária à geração do segredo de autenticação.[2] Não escolha o gerador por conveniência ou pelo formato da saída. Trate a geração e o ciclo de vida das chaves como parte explícita do desenho de segurança.

Como aplicar

Primeiro, procure o HFS no inventário de compartilhamento de arquivos, inclusive instalações que não fazem parte da arquitetura principal. Confirme a versão efetivamente em execução e adote uma versão mantida que incorpore a correção. A presença de um instalador atualizado não comprova a versão do processo ativo.

Depois, revise acessos administrativos, exposição do serviço e alterações de configuração. Em um ambiente autorizado, separe a verificação de atualização da investigação de possível comprometimento.

Para uma aplicação própria, proponho um exercício defensivo em ambiente isolado: crie uma sessão com usuário de teste, altere um caractere do cookie e confirme a rejeição. Em seguida, teste expiração, troca de chave e acesso a uma operação administrativa por um usuário comum. Registre o comportamento esperado antes de executar.

Esse roteiro não reproduz a exploração do HFS. Ele ajuda a testar contratos de sessão e autorização sem distribuir uma cadeia ofensiva. Acrescente revisão de código para identificar como os segredos são gerados e se dados públicos compartilham estado com essa geração.

Cuidados e limites

Não presuma que atualizar o executável invalida automaticamente sessões antigas ou desfaz alterações feitas por um invasor. Confirme esses comportamentos no produto e no ambiente antes de encerrar a resposta.

A correção disponível há meses e a exploração observada são fatos diferentes.[2] O trabalho operacional é fechar essa distância. Uma verificação simples de cookie adulterado também não demonstra resistência a todos os ataques: ela testa rejeição de adulteração, não a imprevisibilidade da chave.

Fonte

[2] Fonte: The Hacker News, com conferência da descrição no GitHub Advisory Database