O dia em que o Telnet desapareceu

 (labs.greynoise.io)
4 pontos por GN⁺ 2026-02-12 | 1 comentários | Compartilhar no WhatsApp
  • Em 14 de janeiro de 2026, às 21h (UTC), o tráfego global de Telnet entrou em colapso abruptamente, com uma queda sustentada de 59% confirmada pela malha de observação
  • 18 ASNs ficaram completamente em silêncio, e o tráfego de 5 países (Zimbábue, Ucrânia, Canadá, Polônia e Egito) desapareceu por completo
  • Grandes provedores de nuvem (AWS, Contabo etc.) tiveram aumento, enquanto ISPs da América do Norte registraram forte queda
  • Seis dias depois, foi divulgada a vulnerabilidade de bypass de autenticação no GNU Inetutils telnetd (CVE-2026-24061), confirmada como uma falha crítica capaz de obter privilégios de root
  • O setor observa a possibilidade de filtragem da porta 23 em nível de backbone como medida adotada após aviso prévio, e avalia o caso como um evento simbólico do fim do Telnet

Colapso do tráfego global de Telnet

  • Em 14 de janeiro de 2026, às 21h (UTC), a GreyNoise Global Observation Grid detectou um colapso repentino no tráfego de Telnet
    • De cerca de 74.000 sessões uma hora antes para 22.000 na hora seguinte, uma queda de 65%
    • Duas horas depois, caiu para cerca de 11.000 sessões, uma redução de 83%, e permaneceu nesse patamar
  • Em comparação com a média diária de 910 mil sessões entre dezembro de 2025 e o início de janeiro de 2026, depois disso o volume caiu para cerca de 370 mil, uma redução de 59%
  • A mudança não foi uma queda gradual, mas uma ruptura abrupta em um único momento (mudança em função degrau), sugerindo a possibilidade de alteração na configuração da infraestrutura de roteamento

Redes e países que ficaram em silêncio

  • 18 ASNs passaram a registrar tráfego Telnet “0” após 15 de janeiro
    • Vultr (AS20473) 380 mil → 0, Cox Communications (AS22773) 150 mil → 0
    • Inclui também Charter/Spectrum (AS20115), BT/British Telecom (AS2856) etc.
  • O tráfego de 5 países (Zimbábue, Ucrânia, Canadá, Polônia e Egito) desapareceu completamente
  • Em contrapartida, AWS +78%, Contabo +90%, DigitalOcean manteve +3%
    • Provedores de nuvem evitaram o impacto da filtragem no backbone por meio de redes privadas de peering

Possibilidade de filtragem da porta 23

  • O padrão indica que operadoras norte-americanas de trânsito Tier 1 podem ter aplicado filtragem da porta 23
    • O horário corresponde a 16h na costa leste dos EUA, coincidindo com a janela de manutenção no país
    • Cox, Charter, Comcast (-74%) e outros ISPs dos EUA foram fortemente afetados
    • Verizon/UUNET (AS701) teve queda de 79% e, como importante operadora de backbone, pode ter sido a responsável pela filtragem ou um caminho superior afetado
  • Países europeus com peering direto (França +18%, Alemanha -1%) sofreram impacto mínimo
  • Operadoras chinesas (China Telecom, China Unicom) registraram ambas queda de 59%
    • A uniformidade na taxa de queda sugere possível filtragem em links transpacíficos do lado americano

Divulgação da vulnerabilidade CVE-2026-24061

  • Vulnerabilidade de bypass de autenticação no GNU Inetutils telnetd, com nota CVSS 9.8
    • Durante o processamento da variável de ambiente USER, a injeção de argumento permite que, ao passar -f root, seja possível obter um shell root sem autenticação
    • Introduzida em um commit de 2015, permaneceu sem ser detectada por cerca de 11 anos
  • Principais datas
    • 14 de janeiro: início do colapso do tráfego Telnet
    • 20 de janeiro: divulgação do CVE
    • 21 de janeiro: registro no NVD e primeira observação de exploração
    • 26 de janeiro: inclusão na lista KEV da CISA
  • Como o colapso do tráfego ocorreu 6 dias antes da divulgação do CVE, levanta-se a possibilidade de uma relação que vai além de mera coincidência

Hipótese de aviso prévio e resposta da infraestrutura

  • Os relatores da vulnerabilidade são Kyu Neushwaistein / Carlos Cortes Alvarez, com reporte conhecido em 19 de janeiro
  • Como a preparação do patch e a resposta da CISA ocorreram já no dia seguinte à divulgação, existe a possibilidade de coordenação prévia
  • A GreyNoise apresenta o seguinte cenário
    • Principais operadores de infraestrutura teriam recebido aviso prévio e aplicado filtragem da porta 23 de forma preventiva
    • 14 de janeiro: ativação da filtragem → 20 de janeiro: divulgação → 26 de janeiro: registro na CISA
  • Não há prova conclusiva, e também é mencionada a possibilidade de mera coincidência temporal

Padrão do tráfego Telnet depois disso

  • Após 14 de janeiro, persistiu um padrão em dentes de serra
    • Ex.: 28 de janeiro, 800 mil sessões → 30 de janeiro, 190 mil sessões
    • Possíveis causas: filtragem intermitente, mudanças de roteamento ou campanhas específicas de scanner
  • Médias semanais
    • Semana de 19 de janeiro: 360 mil sessões (40% da linha de base)
    • Semana de 2 de fevereiro: 320 mil sessões (35%)
  • Estabilização em cerca de 1/3 da linha de base, ainda em tendência de queda

Implicações para segurança e operações

  • Usuários do GNU Inetutils telnetd devem atualizar imediatamente para 2.7-2 ou superior ou desativar o serviço
    • A CISA definiu 16 de fevereiro de 2026 como prazo para patch em órgãos federais
    • Tentativas de exploração foram observadas poucas horas após a divulgação, chegando a 2.600 sessões diárias no início de fevereiro antes de cair
  • Operadores de rede devem avaliar a filtragem da porta 23
    • A filtragem já está em andamento em nível de backbone, e o tráfego Telnet já não é mais considerado um protocolo com valor
  • A GreyNoise registrou o fato de que “alguém cortou o Telnet em uma parte considerável da internet”,
    avaliando o caso como um evento simbólico do fim da era do Telnet

Leituras relacionadas

1 comentários

 
GN⁺ 2026-02-12
Opiniões no Hacker News

  • Mais grave do que o telnetd é o fato de que provedores de trânsito Tier 1 começaram a filtrar portas
    Isso significa que a internet foi fragmentada, virando uma estrutura que nem o roteamento automático (BGP) consegue contornar

    • Quando eu trabalhava num ISP pequeno, o worm Blaster explodiu, e bloquear portas como a 139 foi a resposta mais rápida
      Na época, a maioria dos ISPs bloqueou portas, e no fim isso deixou tudo mais seguro
      Se alguém realmente precisa de telnet, dá para mover para outra porta ou usar tunelamento
      Fico me perguntando se ainda existe alguém rodando telnet na porta padrão 23
    • O risco de censura é um problema, mas também é gravíssimo quando sistemas de hospitais, bancos e usinas nucleares são invadidos e vidas ficam em risco
      Quem toma esse tipo de decisão carrega ao mesmo tempo autoridade e responsabilidade
    • A porta 23 já era filtrada pela maioria dos provedores há décadas
      Por isso tudo está convergindo para a porta 443 com TLS
      Não é o caso de gritar censura por causa disso; censura de verdade é algo para procurar em leis como FOSTA/SESTA
    • Acho que bloquear portas no fim não é diferente de censura
    • Eu consegui me conectar, usando o ISP Spectrum e o cliente GNU telnet, a servidores em Seattle e na Holanda

  • É um bug realmente surpreendente
    Nos primeiros 10 anos da internet, era praticamente a era do telnet
    Naquele tempo, você olhava o tráfego Ethernet e via as senhas em texto puro, e a maioria dos sistemas era multiusuário
    É difícil acreditar que um comando como telnet -l 'root -f' server.test tenha sobrevivido por 11 anos

    • Quanto mais tempo eu trabalho com software, mais só me espanto com o fato de o mundo funcionar desse jeito
      Ainda deve haver muitas vulnerabilidades do tipo fruta ao alcance da mão
    • Eu não fazia login como root, mas houve uma época em que eu navegava na web com lynx usando minha conta AIX da escola
      Naquele tempo eu nem pensava que o tráfego pudesse estar sendo monitorado; parecia simplesmente uma época mais livre
      Eu fazia tudo por telnet: e-mail (pine), web (lynx) e até IRC
    • Nem lembro quando parei de usar telnet
      Muitos servidores deixavam o acesso root via telnet aberto, e nunca foram invadidos
      Eu realmente sinto saudade daquela época
    • Isso me lembrou de vulnerabilidades antigas como rlogin -l '-froot'
      Naquela época esse tipo de coisa era comum
    • Eu não usava para login, mas ele ainda era útil como ferramenta de depuração
      Eu usava bastante para verificar se o tráfego entre contêineres estava passando

  • O cliente Telnet em si ainda não morreu
    Antigamente eu me conectava a servidores SMTP (porta 25) com telnet para enviar e-mails com spoofing
    Mas, com o aumento dos bloqueios de porta em nome da segurança, acho que no fim todos os serviços vão acabar convergindo para a porta 443

    • Hoje ferramentas como netcat, socat e openssl s_client são alternativas bem melhores
      São muito mais poderosas que o telnet
    • Quando eu era mais novo, já enviei SMS por telnet
      Para o destinatário, parecia vir de uma conta oficial da operadora; na época foi ingenuidade, mas hoje pensando bem era uma brincadeira perigosa
    • Tanto o cliente telnet quanto o telnetd ainda podem ser usados
      Só parece que a porta padrão foi bloqueada no nível do roteamento global
      Isso parece uma medida para proteger sistemas antigos e inseguros

  • Ainda não entendo por que alguém usaria telnet na internet hoje
    Imagino que a maior parte seja tráfego de ataque

    • Alguns mantêm isso rodando por preservação de sistemas históricos
    • Na verdade é para ver Star Wars em ASCII
      telnet towel.blinkenlights.nl
      Link do vídeo no YouTube
    • Equipamentos legados, IoT e industriais ainda usam telnet
      Na prática, até SSH muitas vezes é usado de forma insegura
      Desativando a verificação de chave do host, ou usando chaves sem senha, por exemplo
      Então, na prática, uma combinação de telnet + HTTPS websocket + OAuth pode até ser mais segura
    • No rádio amador (HAM), criptografia é proibida, então usam telnet
      Em vez disso, transmissão de dados assinados é permitida, então há necessidade de um protocolo alternativo desse tipo
    • Servidores de jogos de texto como MUD e MOO ainda usam telnet em sua maioria

  • Este CVE é uma boa notícia para a comunidade de hacking de dispositivos embarcados
    Ficou maior a chance de conseguir privilégios de root em equipamentos com telnetd exposto

    • Testei diretamente num Zyxel WiFi AP, mas aparentemente não era vulnerável, talvez por usar um telnetd baseado em busybox

  • O CVE em questão surgiu deste commit
    O ponto principal foi trocar user_name por uname, e eu fiquei me perguntando por que essa mudança de nome seria necessária

    • Pelo ChangeLog, user_name estava causando conflito de nomes (shadowing) com uma variável global, então foi alterado
    • Mas acho mais importante revisar chamadas de getenv() do que esse tipo de ajuste
      Como parsing de entrada é difícil, vulnerabilidades acabam surgindo com frequência

  • É interessante que alguém tenha decidido descartar tráfego telnet no topo da infraestrutura de trânsito da internet
    Talvez até tenha sido a decisão correta
    Fico curioso se isso afeta o tráfego de MUD

    • A maioria dos MUDs não usa diretamente o protocolo Telnet
      São baseados em TCP simples e preferem clientes dedicados
      A porta 23 é reservada pela IANA para Telnet, mas MUDs normalmente usam portas altas de 4 dígitos
      Na verdade, hoje rodar na porta 23 provavelmente tornaria o acesso mais difícil
    • Não ficou claro no artigo, mas parece que eles provavelmente filtram só o tráfego de ataque
      Como o Telnet é texto puro, é fácil detectar por análise de padrões
    • Provavelmente é um bloqueio por porta, como no caso do bloqueio da porta SMTP
      Hoje, se o servidor estiver numa rede pública, o certo é usar SSH

  • Este CVE e a resposta a ele são realmente um evento histórico
    É difícil acreditar que uma pessoa praticamente tenha encerrado a era do telnet

    • Na verdade, houve duas pessoas: quem abriu o PR e quem o aprovou
      A culpa não é do pesquisador de segurança

  • Quando eu era estagiário, achei fascinante descobrir que dava para fazer telnet para o telefone VoIP em cima da minha mesa

    • Eu também testava scripts CGI em Perl por telnet quando era estagiário
      Como eu já estava acostumado com comandos Hayes, digitar requisições HTTP à mão parecia natural
    • Eu também fazia isso, boas lembranças

  • Vi recentemente as estatísticas do meu servidor telnet, e em média ele recebe conexões de cerca de 2000 IPs
    Em meados de janeiro isso disparou para 7500 e depois voltou a cair, e em fevereiro caiu para a faixa de 1000 IPs