Falha crítica no telnetd do GNU InetUtils permite RCE como root sem autenticação
A CVE-2026-32746, com CVSS 9.8, afeta o telnetd do GNU InetUtils até a versão 2.7 e pode ser explorada antes do login, com execução remota de código como root. Sem patch imediato, a prioridade é desabilitar o serviço exposto e bloquear a porta 23.
Uma falha crítica no GNU InetUtils telnetd reacende um alerta que muita organização prefere esquecer: serviços legados continuam oferecendo uma superfície de ataque desproporcional ao valor que entregam. A CVE-2026-32746 recebeu pontuação CVSS 9.8 e pode permitir execução remota de código como root sem autenticação.
O problema está no tratamento da opção LINEMODE Set Local Characters (SLC) durante o handshake do protocolo Telnet. Na prática, um invasor consegue enviar mensagens maliciosas logo no início da conexão, antes mesmo de qualquer tela de login, provocando corrupção de memória e abrindo caminho para comprometimento total do host.
Por que isso é grave
- Não exige credenciais: o ataque ocorre antes da autenticação.
- Baixa barreira de exploração: uma única conexão à porta 23 pode bastar.
- Impacto máximo: como o telnetd costuma rodar com privilégios elevados, a exploração bem-sucedida pode entregar acesso root ao atacante.
- Efeito cascata: após o comprometimento inicial, o host pode ser usado para persistência, exfiltração de dados e movimento lateral.
Contexto operacional
Segundo a pesquisa divulgada, o bug afeta versões do telnetd até a 2.7. O conserto era esperado para o início de abril, mas até a publicação do alerta o risco imediato recaía sobre ambientes ainda expostos com Telnet ativo. Dados citados no relatório indicavam milhares de hosts expostos na internet, o que amplia a chance de varredura automatizada e exploração oportunista.
O que as equipes devem fazer agora
- Desabilitar o Telnet onde ele não for estritamente necessário.
- Bloquear a porta 23 no perímetro e também no firewall local.
- Remover privilégios excessivos do serviço em ambientes onde a desativação imediata não for possível.
- Isolar o acesso administrativo e revisar ativos legados ainda dependentes do protocolo.
- Priorizar atualização assim que a correção oficial estiver disponível.
Leitura do cenário
O caso é mais uma demonstração de que protocolos antigos seguem cobrando sua fatura de segurança. Mesmo quando o uso é residual, a exposição de um serviço histórico como o Telnet continua atraindo ataques por combinar simplicidade operacional para o invasor com impacto severo para a vítima.
Fonte: The Hacker News
