Pónganse cómodos. Lo que estás a punto de leer es una historia que nos hace entender cómo una era de la tecnología está a punto de cambiar: Telnet es uno de los protocolos de red más antiguos.atacado por una vulnerabilidad, con una historia que parece una novela de misterio y que hace que todo sea más intrigante porque está envuelta en secreto, con las dinámicas que giran en torno a los grandes nombres de la tecnología, la columna vertebral de Internetlas redes privadas de proveedores de nube.
Un auténtico misterio, en definitiva, de esos para sentarse a leer el cuento con tranquilidad, como si fuera una novela. Porque al final eso es: una novela moderna de tecnología, misterio y peligro digital. Cuya trama es aparentemente sencilla: 14 de enero de 2026 El tráfico mundial de Telnet se desplomó un 59 por ciento en una hora. Seis días después surgió una vulnerabilidad crítica. La coincidencia plantea preguntas inquietantes sobre el futuro de uno de los protocolos más antiguos de Internet. Pero veamos los detalles.
Era una noche oscura y tormentosa…
El 14 de enero de 2026 a las 21:00 UTC (es decir, hora media de Greenwich), algo cambió en el tejido invisible de Internet. Los sensores de Red global de observación GreyNoise informó una caída repentina en el tráfico Telnet global. No es una reducción gradual, ni una atenuación fisiológica, sino una caída total. Una hora antes fluían alrededor de 74 mil sesiones cada 60 minutos, una hora después quedaban 22 mil, luego 11 mil y al final el nivel se estabilizó allí.
Seis días después, el 20 de enero, apareció en la página el aviso de seguridad para la vulnerabilidad CVE-2026-24061. lista de correo de seguridad oss. El 26 de enero, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. lo agregó al catálogo de vulnerabilidades explotadas activamente. En breve, Primero el colapso, luego la vulnerabilidad.. A nivel temporal, el primer acontecimiento no puede ser consecuencia del segundo. Pero el mero hecho de que los dos fenómenos estén tan cerca plantea preguntas que no tienen respuestas fáciles.
GreyNoise ya había informado de las primeras dieciocho horas de actividad maliciosa tras la divulgación de la falla el 22 de enero. Esta historia es sobre algo diferente.: El cambio estructural en el tráfico Telnet global que precedió a la publicación de la vulnerabilidad. Y la inquietante posibilidad de que los dos acontecimientos no sean independientes.
El colapso
Desde el 1 de diciembre de 2025 hasta el 14 de enero de 2026, GreyNoise había observado un promedio de aproximadamente 914 mil sesiones Telnet diarias de un total de 51,2 millones de sesiones. Esta era la base, cien por ciento para empezar. El 14 de enero a las 21:00 UTC el volumen horario se desplomó un 65 por ciento en sólo un minuto. En dos horas había caído un 83 por ciento. El nuevo nivel se ubicó en alrededor de 373 mil sesiones por día, una reducción sostenida del 59 por ciento que aún persiste en la actualidad.
No fue una transición fácil. Los datos horarios alrededor del punto de inflexión lo dicen todo: a las 19:00 UTC del 14 de enero había 73.900 sesiones, a las 20:00 horas eran 64.722, a las 21:00 horas habían caído a 22.460. A las 22.00 horas habían caído a 11.325, 83 por ciento por debajo del valor inicial. A las 23.00 horas el nuevo nivel se había estabilizado en 11.147 sesiones.
Este tipo de función escalonada, que se propaga en una única ventana de tiempo de una hora, sólo puede interpretarse como un cambio de configuración en la infraestructura de enrutamiento. No como una variación del comportamiento en las poblaciones de escáneres. No como un accidente tecnológico. Es un cambio deseado y perseguido fríamente. ¿Pero por qué? ¿Cómo?
lo que se quedo en silencio
Dieciocho redes independientes con importantes volúmenes de tráfico Telnet antes del colapso cayeron al cero absoluto después del 15 de enero. Algunos nombres destacan en la lista: Vultr con 382 mil sesiones antes del colapso y luego nada más, Comunicaciones Cox con 150 mil sesiones faltantes, Carta y espectro con 141 mil, Telecomunicaciones británicas con 127 mil.
Cinco países enteros desaparecieron de los datos Telnet de GreyNoise: Zimbabwe, Ucrania, Canadá, Polonia y Egipto. No reducido, sólo reducido a cero. Mientras tanto, los grandes proveedores de la nube se han mantenido prácticamente sin cambios o incluso han aumentado. Amazon Web Services aumentó un 78 por cientoContabo en un 90 por ciento, DigitalOcean se mantuvo esencialmente sin cambios con un aumento del 3 por ciento.
Se debe conocer otro detalle técnico para comprenderlo. Los proveedores de nube tienen Amplios sistemas de peering privados. en los principales puntos de intercambio de Internet. Sistemas de peering privados evitar las rutas troncales de tránsito tradicionales (básicamente: las principales autopistas de Internet). Los proveedores de servicios de Internet residenciales y comerciales generalmente no tienen lo siguiente: Usan backbones públicos.. Traducido: el tráfico se ha movido enormemente.
¿Dónde está ubicado el filtro?
La distribución de datos apunta hacia una interpretación muy simple y directa: uno o más proveedores de tránsito de primer nivel de América del Norte (los más grandes del mundo) implementaron filtrado del puerto 23. La hora, 21:00 UTC correspondiente a las 16:00 Hora del Este de los Estados Unidos, es compatible con una ventana de mantenimiento típica de los centros informáticos de EE. UU.. Los proveedores residenciales estadounidenses han quedado completamente devastados, mientras que los proveedores de nube en el mismo continente han pasado por alto cualquier cambio a través del peering. ¿Cómo?
Veamos los últimos números que nos permiten concluir el retrato de lo sucedido. Verizon y UUNET cayeron un 79 por cientoy como backbone principal de primer nivel esto es compatible con que sea la entidad de filtrado o que esté directamente aguas arriba de una de estas grandes redes. Y un filtro coordinado de antemano En definitiva: no hay confirmación oficial, pero los datos apuntan en esa dirección.
El 21 por ciento del tráfico permanece en esta red. representaría rutas que no pasan por las conexiones filtradas. Por ejemplo, los países que dependen de rutas troncales transatlánticas o transpacíficas para llegar a la infraestructura alojada en Estados Unidos han sido golpea más fuerte. Los países con fuertes pares europeos directos se mantuvieron esencialmente sin cambios.
En cambio, Proveedores centrales chinos cayeron uniformemente en un 59 por ciento. Esta uniformidad sugiere que el filtro está en el lado estadounidense de los vínculos transpacíficos y no dentro de China. Si hubiera sido una acción del cortafuegos chinocabría esperar un impacto asimétrico entre las compañías aéreas chinas y un recorte más pronunciado.
Luego vino la vulnerabilidad
Bueno, si has seguido hasta aquí, has visto las consecuencias. ¿Pero las consecuencias de qué? De un documento que en realidad fue publicado después de sus consecuencias, y no antes. ¿Por qué? Vayamos en orden.
El CVE-2026-24061 (la nomenclatura estándar de los informes de vulnerabilidad de ciberseguridad) es una omisión de autenticación crítica en GNU Inetutils telnetd con Puntuación CVSS de 9,8. El defecto es una inyección de datos (en realidad, argumentos de cadena de comando) de la misma manera el demonio telnetd de Unix/Linux maneja la variable de entorno USER al negociar opciones de Telnet. Un atacante envía la cadena con un argumento (“-f root” como valor de nombre de usuario) e el comando «iniciar sesión» omite la autenticación por completo y obedientementeentregando un shell raíz al atacante de forma remota. No se requieren credencialessin interacción del usuario. El código vulnerable se introdujo en una confirmación de 2015 y permaneció oculto durante casi once años.
La cronología de los acontecimientos es significativa: el 14 de enero A las 21:00 UTC comienza el colapso del tráfico Telnet en la red troncal. 20 de enero el aviso para CVE-2026-24061 está publicado en oss-security. 21 de enero la entrada se publica en la base de datos nacional de vulnerabilidades, GreyNoise activa la etiqueta de monitoreo y se observa la primera explotación. 22 de enero GreyNoise publica un análisis de las primeras dieciocho horas de actividad maliciosa. 26 de enero CISA añade CVE-2026-24061 al catálogo de vulnerabilidades explotadas.
¿Has visto ahora? La brecha de seis días Entre el colapso del tráfico Telnet (que ocurrió antes, de manera preventiva) y la divulgación pública de la vulnerabilidad (ya descubierta pero evidentemente aún no explotada por nadie) es la parte interesante. A primera vista el colapso no pudo haber sido causado por la divulgación de la vulnerabilidad porque el colapso ocurrió primero. Pero la causada por no es la única relación que vale la pena considerar.
la hipotesis
El momento de la divulgación responsable no comienzan en la publicación. El investigador que encontró el defecto informó del problema el 19 de enero, según fuentes públicas. Pero coordinación que conduce a parches listoslos avisos redactados y CISA preparados para agregar algo al catálogo dentro de los seis días posteriores a la publicación generalmente comienzan antes del día anterior a la divulgación.
Esto es lo que podría haber sucedido: Notificación anticipada de una vulnerabilidad trivialmente explotable que permite acceso raíz no autenticado a demonios Telnet ha llegado a partes con capacidad de actuar a nivel de infraestructura. Un proveedor troncal o de tránsito, que probablemente responda a una solicitud coordinada o actúe según su propia evaluación, implementado filtrado del puerto 23 en enlaces de tránsito. La filtración entró en vigor el 14 de enero. La divulgación pública siguió el 20 de enero.
Esto explicaría el lapso de tiempo entre la notificación anticipada, la respuesta de la infraestructura y la divulgación pública. Explicaría la especificidad del filtrado en el puerto TCP 23. y no un cambio de ruta general. Explicaría la topología del impacto, ya que las rutas dependientes del tránsito se ven afectadas y las rutas de intercambio directo no. Explicaría el carácter sostenido del fenómeno dado que el filtro sigue activo semanas después.
El mundo después del colapso
El paisaje de Telnet después del 14 de enero muestra un patrón recurrente en dientes de sierra con picos periódicos seguidos de valles. Esto podría indicar aplicación intermitente del filtroenrutar oscilaciones alrededor de la infraestructura de filtrado o campañas de escaneo utilizando rutas no afectadas por el filtro. Los promedios semanales, sin embargo, son favorables. La teoría de la historia tal como ha sido explicada.: de la primera semana de diciembre con más de un millón de sesiones diarias pasamos a la semana del 19 de enero con 363 mil sesiones, el 40 por ciento del valor base.
El nivel operativo se sitúa ahora en alrededor de un tercio del nivel de referencia previo al accidente y la tendencia sigue siendo ligeramente a la baja. Si ejecuta demonios “GNU Inetutils telnetd” (aquellos que son el corazón de código abierto de Internet) en cualquier parte del mundo, y dada la ventana de once años, también hay muchos de ellos en sistemas integradosdispositivos de red e instalaciones heredadas de Linux, debe actualizar a la versión correcta o desactivar el servicio por completo.
La fecha límite para la corrección de las agencias federales estadounidenses según CISA es el 16 de febrero de 2026. GreyNoise observó intentos de explotación a las pocas horas de la divulgación, y la campaña alcanzó un máximo de alrededor de 2600 sesiones por día a principios de febrero antes de disminuir. Si alguno de los grandes Si el upstream de una parte importante de la infraestructura de tránsito de Internet ha decidido que ya no vale la pena transportar tráfico Telnet, probablemente sea la decisión correcta. Pero también es el fin de Telnet.
La red cambia así, como un misterio de Agatha Christie que luego se convierte en Un misterio internacional entre superpotencias en línea.. Un misterio y un choque subterráneo del que casi nunca nadie cuenta nada, pero que cambia el mundo en el que vivimos.