Fallo crítico CVE-2026-24061 en Telnetd de GNU InetUtils permite eludir la autenticación y obtener acceso root tras casi once años

Un fallo crítico en el demonio telnet de GNU InetUtils ha salido a la luz después de permanecer inadvertido casi once años. Catalogado como CVE-2026-24061 y con una puntuación de severidad de 9.8 sobre 10 en la escala CVSS, este problema permite eludir el proceso de autenticación y obtener acceso con privilegios de root en sistemas afectados.

Telnetd es el programa que acepta conexiones Telnet y sirve de puente para iniciar sesión en un sistema remoto; aunque el protocolo Telnet es antiguo y carece de cifrado, todavía se emplea en algunos entornos embebidos y redes de administración donde la simplicidad prima sobre la seguridad. La vulnerabilidad descubierta reside en la forma en que telnetd transmite la variable de entorno USER al binario /usr/bin/login sin realizar una limpieza adecuada. El demonio pasa literalmente el contenido que recibe desde el cliente como último argumento de login, y si ese contenido se interpreta como una opción válida para login, puede cambiar su comportamiento.

En concreto, si un cliente envía la cadena "-f root" como valor de USER y utiliza la opción de cliente telnet que envía variables de entorno (por ejemplo -a o --login), el proceso login recibe esa cadena y la interpreta como la opción -f, que instruye a login a marcar al usuario especificado como ya autenticado. El resultado es una entrada directa como root sin que se solicite contraseña, lo que explica por qué la clasificación del fallo es tan alta.

El origen del problema puede rastrearse hasta un cambio en el código realizado el 19 de marzo de 2015, que acabó formando parte de la versión 1.9.3 lanzada en mayo de ese mismo año. El descubrimiento fue reportado recientemente por el investigador identificado como Kyu Neushwaistein (también conocido como Carlos Cortes Alvarez) y comunicado públicamente por el colaborador de GNU Simon Josefsson en la lista de correo oss-security. La entrada oficial del NIST describe el problema y lo clasifica como una vulnerabilidad que permite eludir la autenticación remota; puede consultarse en la base de datos de vulnerabilidades en NVD – CVE-2026-24061.

Para los administradores y responsables de seguridad hay dos mensajes claros: primero, revisar si su entorno ejecuta versiones afectadas de GNU InetUtils (desde la 1.9.3 hasta la 2.7 inclusive); segundo, aplicar parches o actualizar a una versión corregida tan pronto como estén disponibles. La página del proyecto GNU Inetutils ofrece información sobre el software y sus componentes en GNU Inetutils, y el manual de telnetd ayuda a entender el comportamiento esperado del demonio.

Como soluciones inmediatas y paliativas, se aconseja restringir el acceso al puerto Telnet mediante reglas de cortafuegos o listas de control de acceso, desactivar el servicio telnetd cuando no sea imprescindible y, si es imprescindible, configurarlo para que utilice una versión de login que no admita la opción -f o que valide estrictamente sus argumentos. Otra alternativa temporal es reemplazar el binario login por un envoltorio que filtre la variable USER antes de llamarlo. Estas medidas reducen la exposición mientras se despliegan actualizaciones definitivas.

Más allá del parche y de las contramedidas técnicas, conviene auditar los sistemas por signos de explotación. Revisar los registros de acceso y los historiales de inicio de sesión, comprobar ficheros de auditoría y buscar procesos o cuentas recién creadas con privilegios elevados son acciones obligadas si se sospecha que el sistema pudo haber sido vulnerado. En entornos con telemetría o IDS/IPS, crear firmas o reglas específicas para detectar cadenas sospechosas enviadas en variables de entorno puede ayudar a identificar intentos de explotación.

Indicadores de actividad ya se han observado en la naturaleza. La firma de inteligencia de amenazas GreyNoise registra intentos de esta explotación: en las últimas 24 horas se detectaron 21 direcciones IP distintas intentando explotar el bypass mediante la opción -f en telnetd, y esas IPs proceden de varios países y han sido marcadas como maliciosas. Los datos y visualizaciones de esos eventos están disponibles en el panel de GreyNoise en GreyNoise – intentos detectados y en las consultas públicas GreyNoise – detalles por IP.

Este incidente subraya dos enseñanzas importantes: por un lado, cómo una línea de código aparentemente inocua y una validación insuficiente pueden convertirse en una brecha grave que perdura años; por otro, la necesidad de reducir la dependencia de servicios inseguros por diseño, como Telnet, en favor de alternativas que ofrezcan cifrado y controles modernos, por ejemplo SSH. A corto plazo, aplicar parches y limitar el acceso de red son las mejores defensas. A medio y largo plazo, planificar migraciones fuera de servicios obsoletos y reforzar prácticas de revisión de código y pruebas de seguridad ayudará a evitar que errores similares permanezcan sin detectar durante tanto tiempo.

Para mantenerse informado y acceder a las referencias técnicas citadas en este artículo: la descripción del fallo y su valoración en NVD está en NVD – CVE-2026-24061, la discusión técnica y la notificación en la lista oss-security aparece en oss-security, el commit que introdujo el cambio está disponible en el repositorio en Codeberg – commit del 19-mar-2015, y para seguir actividad de explotación pública puede consultarse la telemetría de GreyNoise en GreyNoise. Si gestionas sistemas que pudieran verse afectados, prioriza la mitigación y la comprobación forense antes de reactivar cualquier servicio deshabilitado.