CVE-2026-24061

O telnetd do GNU Inetutils (versões 1.9.3 até 2.7 inclusive) permite bypass completo de autenticação: um cliente telnet que envie a variável de ambiente USER com o valor "-f root" faz o servidor repassar esse valor para /usr/bin/login como argumento, e login(1) interpreta "-f" como login automático sem senha. O impacto é root remoto sem credenciais, mas a falha só existe onde telnetd está instalado, habilitado e acessível na rede — algo cada vez mais raro, exceto em appliances legados, dispositivos embarcados e infraestrutura industrial/educacional que ainda expõe telnet.

A causa é injeção de argumento (CWE-88) somada a bypass de autenticação (CWE-287). Em telnetd/telnetd.c, o daemon monta a linha de comando de login(1) a partir de um template com placeholders: em sistemas GNU/Linux o template é `PATH_LOGIN " -p -h %h %?u{-f %u}{%U}"`. O placeholder %u/%U é expandido em telnetd/utility.c pela função _var_short_name, que simplesmente lê a variável de ambiente USER recebida do cliente via a opção NEW-ENVIRON do protocolo telnet (RFC 1572) e a devolve sem nenhuma sanitização.

Se o cliente define USER='-f root', a expansão gera a linha de comando `login -p -h -f root`, e login(1) do shadow-utils trata "-f" como flag legítima para pular a autenticação e autenticar diretamente o usuário indicado — nesse caso root. O bug foi introduzido em 19/03/2015 (commit fa3245ac8c288b87139a0da8249d0a408c4dfb87) e entrou na release 1.9.3 (12/05/2015); esteve presente em todas as versões subsequentes até 2.7.

O próprio advisory do mantenedor (Simon Josefsson) nota que o problema é estrutural: qualquer campo expandido por _var_short_name que aceite dados não confiáveis é candidato a variante do mesmo bug — inclusive %h (remote_hostname), preenchido por getnameinfo()/gethostbyaddr(), cuja resposta também não é dado confiável em muitos ambientes.

O vetor é a negociação da opção NEW-ENVIRON do protocolo telnet: o cliente `telnet` com a flag `-a` (ou `--login`) envia automaticamente o valor da variável de ambiente USER local para o servidor. Um atacante só precisa definir USER="-f root" no shell antes de conectar e usar essa flag ao chamar o cliente telnet contra o host-alvo — sem usuário, senha ou qualquer interação adicional. Isso casa com o vetor CVSS (AV:N/AC:L/PR:N/UI:N): nenhuma autenticação, nenhuma condição de rede além de alcançar a porta do telnetd (normalmente 23/tcp).

A única pré-condição relevante que a nota do CVSS não deixa óbvia é que o telnetd precisa estar instalado, habilitado (via inetd/xinetd ou standalone) e alcançável pela rede — coisa que não é padrão na maioria dos sistemas modernos, mas é comum em firmware de dispositivos, appliances de rede antigos, sistemas OT/ICS e distribuições que mantêm compatibilidade legada. login(1) também precisa suportar a flag -f com esse comportamento (típico do shadow-utils em GNU/Linux); a expansão do template varia em Solaris, onde o parâmetro -f não é usado da mesma forma.

A falha está no catálogo KEV da CISA, o que indica exploração confirmada em produção, e há módulo Metasploit e PoC pública — ou seja, a barreira técnica para exploração é mínima. O post do GreyNoise ("18 Hours of Unsolicited Houseguests") descreve varredura em massa na internet buscando telnetd exposto pouco depois da divulgação, sugerindo campanha oportunista de scanning e exploração automatizada, não ataque direcionado.

A correção do mantenedor consiste em dois patches que sanitizam todas as variáveis expandidas no template de invocação de login(1), não só USER: https://codeberg.org/inetutils/inetutils/commit/fd702c02497b2f398e739e3119bed0b23dd7aa7b e https://codeberg.org/inetutils/inetutils/commit/ccba9f748aa8d50a38d7748e2e60362edd6a32cc. Até a publicação do advisory, o projeto não havia cortado uma release numerada que já incorporasse esses patches — o que existe são os commits e correções aplicadas por distribuições em seus próprios pacotes (ver o anúncio da Debian LTS). Aplique esses patches ou acompanhe o pacote da sua distribuição para confirmar que a versão instalada os incorpora.

Histórico importante para quem confia em "já corrigi isso há anos": a Debian aplicou um patch equivalente (0028-telnetd-Scrub-USER-from-environment.patch) em inetutils 1.9.4-7 (fevereiro de 2019), mas a correção subsequente para CVE-2020-10188 (RCE em telnetd), lançada em 1.9.4-7+deb10u1 (setembro de 2020, Debian 10), reintroduziu o bug do USER/-f — e isso se propagou para Debian e Ubuntu posteriores. Ou seja, a mitigação aplicada em 2019 não protege builds baseadas nos pacotes derivados dessa correção de 2020 sem reverificação.

O paliativo mais eficaz e de menor custo é simplesmente não expor telnetd: desabilitar o serviço (remover a linha telnet do inetd.conf/xinetd.d ou desinstalar o pacote inetutils-telnetd) e restringir a porta 23/tcp a redes de gerência confiáveis via firewall. Como workaround alternativo quando telnetd precisa continuar rodando, o próprio advisory sugere substituir o login(1) usado pelo telnetd por uma variante que não aceite a flag -f — mas isso é um controle compensatório frágil, não uma correção. Trocar apenas a senha de root ou desabilitar login root via SSH não mitiga nada: o bug ocorre inteiramente dentro do fluxo de autenticação do telnetd/login, sem depender de credenciais.

Telnet é protocolo em texto claro, então a exploração é visível em captura de tráfego: procure na negociação NEW-ENVIRON (opção telnet) o envio da variável USER contendo a string "-f" seguida de um nome de usuário, tipicamente "-f root", logo após o handshake inicial na porta 23/tcp. No host, logs de login(1)/PAM podem registrar uma sessão autenticada via flag -f sem prompt de senha correspondente, e logs do inetd/xinetd mostrarão a invocação do processo login com argumentos anômalos.

Não há assinatura única confiável além dessa string, porque "-f " é também uso legítimo de login(1) em alguns fluxos administrativos locais — o sinal forte é a origem remota (conexão telnet externa) combinada com o valor da variável USER controlado pelo cliente. Dado o histórico de scanning em massa reportado, presença de qualquer telnetd exposto à internet já deve ser tratada como indicador de risco, independente de log de tentativa específica.