El día en que desapareció Telnet

 (labs.greynoise.io)
4 puntos por GN⁺ 2026-02-12 | 1 comentarios | Compartir por WhatsApp
  • El 14 de enero de 2026 a las 21:00 (UTC), el tráfico global de Telnet colapsó bruscamente y la red de observación confirmó una caída sostenida del 59%
  • 18 ASN quedaron completamente en silencio y el tráfico de 5 países (Zimbabue, Ucrania, Canadá, Polonia y Egipto) desapareció por completo
  • Los principales proveedores de nube (AWS, Contabo, etc.) incluso aumentaron, mientras que los ISP de Norteamérica registraron una caída masiva
  • Seis días después se reveló la vulnerabilidad de bypass de autenticación en GNU Inetutils telnetd (CVE-2026-24061), confirmada como una falla crítica que permite obtener privilegios de root
  • La industria pone atención en la posibilidad de que se haya aplicado filtrado del puerto 23 a nivel de backbone como medida tomada tras una notificación previa, y lo evalúa como un hecho simbólico del fin de Telnet

Colapso del tráfico global de Telnet

  • El 14 de enero de 2026 a las 21:00 (UTC), GreyNoise Global Observation Grid detectó un colapso repentino del tráfico de Telnet
    • Aproximadamente 74,000 sesiones una hora antes cayeron 65% hasta 22,000 en la hora siguiente
    • Dos horas después bajó a unas 11,000 sesiones, una caída del 83%, y se mantuvo en ese nivel
  • Frente al promedio diario de 910,000 sesiones entre diciembre de 2025 y principios de enero de 2026, posteriormente bajó a unas 370,000, una reducción del 59%
  • El cambio no fue una disminución gradual, sino una interrupción brusca en un único momento (cambio tipo función escalón), lo que sugiere una posible modificación en la configuración de la infraestructura de enrutamiento

Redes y países que quedaron en silencio

  • 18 ASN pasaron a tráfico Telnet “0” desde el 15 de enero
    • Vultr (AS20473) 380,000 → 0, Cox Communications (AS22773) 150,000 → 0
    • También incluidos Charter/Spectrum (AS20115), BT/British Telecom (AS2856), entre otros
  • El tráfico de 5 países (Zimbabue, Ucrania, Canadá, Polonia y Egipto) desapareció por completo
  • En cambio, AWS aumentó 78%, Contabo 90% y DigitalOcean se mantuvo en +3%
    • Los proveedores de nube evitaron el impacto del filtrado en backbone mediante redes privadas de peering

La posibilidad de filtrado del puerto 23

  • El patrón apunta a que proveedores de tránsito Tier 1 de Norteamérica aplicaron filtrado al puerto 23
    • El momento coincide con las 16:00 de la costa este de EE. UU., horario típico de mantenimiento dentro del país
    • Cox, Charter, Comcast (-74%) y otros ISP estadounidenses fueron fuertemente afectados
    • Verizon/UUNET (AS701) cayó 79%, lo que lo señala como posible actor del filtrado o ruta superior clave
  • Los países europeos con peering directo (Francia +18%, Alemania -1%) tuvieron un impacto mínimo
  • Las telecom chinas (China Telecom, China Unicom) cayeron ambas 59%
    • La uniformidad de la caída sugiere la posibilidad de filtrado en enlaces transpacíficos del lado estadounidense

Divulgación de la vulnerabilidad CVE-2026-24061

  • Vulnerabilidad de bypass de autenticación en GNU Inetutils telnetd, con calificación CVSS 9.8
    • Durante el procesamiento de la variable de entorno USER, una inyección de argumentos permite pasar -f root y obtener un shell root sin autenticación
    • Fue introducida en un commit de 2015 y permaneció sin detectarse durante unos 11 años
  • Cronología principal
    • 14 de enero: comienza el colapso del tráfico de Telnet
    • 20 de enero: se publica el CVE
    • 21 de enero: registro en NVD y primera observación de explotación
    • 26 de enero: se añade a la lista KEV de CISA
  • Como el colapso del tráfico ocurrió 6 días antes de la divulgación del CVE, se plantea una posible relación más allá de una simple coincidencia

Hipótesis de notificación previa y respuesta de infraestructura

  • Se indica que quienes reportaron la vulnerabilidad fueron Kyu Neushwaistein / Carlos Cortes Alvarez, con reporte fechado el 19 de enero
  • El hecho de que la preparación del parche y la respuesta de CISA se dieran en apenas un día desde la publicación sugiere una posible coordinación previa
  • GreyNoise plantea el siguiente escenario
    • Operadores de infraestructura clave recibieron notificación previa y aplicaron de manera preventiva filtrado al puerto 23
    • 14 de enero: activación del filtrado → 20 de enero: divulgación → 26 de enero: inclusión por CISA
  • No hay pruebas concluyentes, y también se menciona la posibilidad de que sea solo una coincidencia temporal

Comportamiento posterior del tráfico de Telnet

  • Desde el 14 de enero persiste un patrón en dientes de sierra
    • Ejemplo: 800,000 sesiones el 28 de enero → 190,000 sesiones el 30 de enero
    • Posibles causas: filtrado intermitente, cambios de enrutamiento o campañas específicas de escaneo
  • Promedios semanales
    • Semana del 19 de enero: 360,000 sesiones (40% del nivel base)
    • Semana del 2 de febrero: 320,000 sesiones (35%)
  • Se estabilizó en aproximadamente un tercio del nivel base, aunque la tendencia sigue siendo descendente

Implicaciones operativas y de seguridad

  • Los usuarios de GNU Inetutils telnetd deben actualizar de inmediato a 2.7-2 o superior o desactivar el servicio
    • CISA fijó como fecha límite de parcheo para agencias federales el 16 de febrero de 2026
    • Tras la divulgación pública, se observaron intentos de explotación en cuestión de horas, que aumentaron hasta 2,600 sesiones diarias a inicios de febrero y luego disminuyeron
  • Los operadores de red deben evaluar el filtrado del puerto 23
    • El filtrado ya avanza a nivel de backbone y el tráfico Telnet ya se considera un protocolo sin valor
  • GreyNoise deja constancia de que “alguien desconectó Telnet de una parte considerable de Internet”,
    y lo evalúa como un hecho simbólico del fin de la era de Telnet

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-02-12
Comentarios en Hacker News

  • Más grave que telnetd es el hecho de que los proveedores de tránsito Tier 1 hayan empezado a filtrar puertos
    Eso significa que Internet se ha fragmentado, y se volvió una estructura que ni siquiera el enrutamiento automático (BGP) puede rodear

    • Cuando trabajaba en un ISP pequeño, explotó el gusano Blaster, y bloquear cosas como el puerto 139 fue la respuesta más rápida
      En ese momento la mayoría de los ISP bloquearon puertos, y como resultado todo se volvió más seguro
      Si de verdad necesitas telnet, puedes moverlo a otro puerto o usar túneles
      Me pregunto si todavía queda alguien ejecutando telnet en el puerto 23 por defecto
    • El riesgo de censura es un problema, pero también es grave que sistemas de hospitales, bancos o plantas nucleares sean hackeados y pongan vidas en peligro
      Quienes toman este tipo de decisiones tienen al mismo tiempo autoridad y responsabilidad
    • El puerto 23 ya lo filtraban la mayoría de los proveedores desde hace décadas
      Por eso todo se está concentrando en el puerto 443 con TLS
      No es para gritar que esto es censura; si quieren censura de verdad, hay que buscarla en leyes como FOSTA/SESTA
    • Creo que bloquear puertos al final no es diferente de la censura
    • Yo pude conectarme a servidores en Seattle y en los Países Bajos usando el cliente GNU telnet a través del ISP Spectrum

  • Es un bug realmente sorprendente
    Durante los primeros 10 años de Internet casi todo se hacía con telnet
    En ese tiempo, si mirabas el tráfico Ethernet podías ver las contraseñas tal cual, y la mayoría de los sistemas eran entornos multiusuario
    Cuesta creer que un comando como telnet -l 'root -f' server.test haya sobrevivido 11 años

    • Cuanto más tiempo trabajo en software, más me sorprende que el mundo funcione así
      Siento que todavía debe haber muchas vulnerabilidades tipo fruta al alcance de la mano
    • Yo no iniciaba sesión como root, pero hubo una época en que navegaba la web con lynx desde mi cuenta AIX de la escuela
      Ni se me ocurría que el tráfico pudiera estar siendo monitoreado; simplemente era una época más libre
      Hacía todo por telnet: correo (pine), web (lynx) e incluso IRC
    • Ni siquiera recuerdo cuándo dejé de usar telnet
      Muchos servidores dejaban abierto el acceso root por telnet, y aun así nunca fueron hackeados
      Sí extraño esa época
    • Me acordé de que antes también había vulnerabilidades como rlogin -l '-froot'
      En esos tiempos eso era bastante común
    • No lo usaba para iniciar sesión, pero seguía siendo útil como herramienta de depuración
      Lo usaba mucho para comprobar si había tráfico entre contenedores

  • El cliente Telnet en sí todavía no está muerto
    Antes uno se conectaba por telnet a un servidor SMTP (puerto 25) para enviar correos falsificados
    Pero con el aumento de bloqueos de puertos en nombre de la seguridad, creo que al final todos los servicios van a terminar concentrándose en el puerto 443

    • Hoy herramientas como netcat, socat y openssl s_client son alternativas mucho mejores
      Son bastante más potentes que telnet
    • De chico llegué a enviar SMS con telnet
      Para el destinatario parecía venir de una cuenta oficial de la operadora, y aunque entonces era una travesura inocente, ahora pensándolo bien era algo peligroso
    • El cliente telnet o telnetd en sí todavía se pueden usar
      Lo que parece haber pasado es que se bloqueó el puerto por defecto a nivel de enrutamiento global
      Da la impresión de ser una medida para proteger sistemas viejos e inseguros

  • Todavía no entiendo por qué alguien seguiría usando telnet en Internet
    Sospecho que la mayoría es tráfico de ataque

    • Algunos lo mantienen por preservación de sistemas históricos
    • En realidad es para ver Star Wars en ASCII
      telnet towel.blinkenlights.nl
      Enlace al video de YouTube
    • En equipos legacy, IoT e industriales telnet todavía se usa
      Incluso SSH muchas veces se usa de forma insegura en la práctica
      Se desactiva la verificación de host keys o se usan claves sin contraseña, por ejemplo
      Así que en la realidad una combinación de telnet + HTTPS websocket + OAuth podría ser más segura
    • En la radioafición (HAM), el cifrado está prohibido, así que usan telnet
      En cambio sí se permite transmitir datos firmados, así que hace falta algún protocolo alternativo de ese tipo
    • Los servidores de juegos de texto como MUD o MOO todavía usan mayormente telnet

  • Este CVE es una buena noticia para la comunidad que hackea equipos embebidos
    Aumentaron las probabilidades de obtener privilegios root en dispositivos con telnetd abierto

    • Lo probé directamente en un Zyxel WiFi AP, pero como usaba un telnetd basado en busybox, no era vulnerable

  • El CVE en cuestión se originó en este commit
    La clave fue cambiar user_name por uname, y me pregunté por qué hacía falta un cambio de nombre así

    • Si ves el ChangeLog, fue porque user_name entraba en conflicto de nombres (shadowing) con una variable global
    • Pero creo que más importante que ese ajuste es revisar las llamadas a getenv()
      Como analizar valores de entrada es complicado, ahí suelen aparecer vulnerabilidades

  • Es interesante que alguien haya decidido tirar el tráfico telnet desde lo más alto de la infraestructura de tránsito de Internet
    Probablemente hasta haya sido la decisión correcta
    Me pregunto si eso afectará al tráfico de MUD

    • La mayoría de los MUD no usan directamente el protocolo Telnet
      Funcionan sobre TCP simple y prefieren clientes dedicados
      El puerto 23 está reservado por IANA para Telnet, pero los MUD normalmente usan puertos altos de 4 dígitos
      De hecho, ahora usar el puerto 23 probablemente haría que fueran más difíciles de alcanzar
    • El artículo no lo deja claro, pero da la impresión de que tal vez solo estén filtrando tráfico de ataque
      Como Telnet va en texto plano, es fácil detectarlo con análisis de patrones
    • Seguramente sea un bloqueo por puerto, como el bloqueo del puerto SMTP
      Hoy, si es un servidor en una red pública, debería usar SSH

  • Este CVE y su respuesta son realmente un hecho histórico
    Cuesta creer que una sola persona haya terminado, en los hechos, con la era de telnet

    • En realidad fueron dos personas: quien envió el PR y quien lo aprobó
      No es culpa del investigador de seguridad

  • Cuando era intern, me sorprendió muchísimo descubrir que se podía entrar por telnet al teléfono VoIP que tenía en el escritorio

    • Yo también, cuando era intern, probaba scripts CGI en Perl por telnet
      Como ya estaba acostumbrado a los comandos Hayes, me salía natural escribir solicitudes HTTP a mano
    • Yo también lo hacía, qué buenos recuerdos

  • Revisé hace poco las estadísticas de mi servidor telnet y en promedio se conectan unos 2000 IP
    A mediados de enero se disparó hasta 7500 y después volvió a bajar; en febrero cayó a alrededor de 1000