Une faille critique dans telnetd, composant Telnet de GNU InetUtils, permet de court-circuiter l’authentification et d’obtenir un accès root au système ciblé, à distance.
Pour rappel, Telnet sert à ouvrir une session à distance, généralement pour administrer une machine ou un équipement réseau. Le protocole est ancien, il est léger, et surtout il n’est pas chiffré, ce qui explique pourquoi SSH l’a remplacé presque partout. Sauf qu’en pratique, Telnet continue de traîner sur des systèmes anciens, des appareils embarqués et des réseaux industriels où les mises à jour se heurtent à des contraintes de compatibilité et d’exploitation. Un choix qui montre aujourd’hui ses limites, alors qu’une faille critique introduite en 2015 dans telnetd a récemment été signalée par le chercheur en sécurité Carlos Cortes Alvarez, puis documentée et partiellement corrigée par Simon Josefsson, mainteneur de GNU InetUtils, tandis que GreyNoise observe déjà des tentatives d’exploitation.
Offre partenaire
Protection avancée des e-mails, des calendriers, des mots de passe, du réseau… de votre entreprise grâce à la suite d'applications professionnelles sécurisées.
Offre partenaire
Une faille d’authentification vieille de 10 ans, désormais exploitée
La vulnérabilité est désormais suivie sous l’identifiant CVE-2026-24061 (CVSS 9.8). Elle affecte telnetd, le serveur Telnet de GNU InetUtils, dans toutes les versions comprises entre 1.9.3 et 2.7. Des correctifs sont disponibles dans le dépôt du projet (ici et ici).
Le problème tient à la façon dont telnetd gère l’authentification. Lorsqu’une connexion est établie, le serveur confie cette étape à un programme du système chargé de vérifier l’identité de l’utilisateur et d’ouvrir la session (/usr/bin/login). telnetd lui transmet pour cela le nom d’utilisateur fourni par le client, sans le contrôler. Or ce programme accepte une option interne (-f) qui indique que l’utilisateur est déjà authentifié et qu’aucun mot de passe ne doit être demandé. À titre d’exemple, une valeur comme -f alice permet d’ouvrir directement une session pour alice, sans vérification préalable.
En exploitant cette faiblesse, un attaquant peut fournir -f root lors de la connexion Telnet et obtenir immédiatement un accès administrateur, sans disposer d’un compte valide ni d’un accès physique à la machine.
Le bug a été introduit en mars 2015 et est resté présent dans le code jusqu’à sa découverte, signalée le 19 janvier 2026 par le chercheur en sécurité Carlos Cortes Alvarez. La faille a ensuite été documentée et corrigée par Simon Josefsson, mainteneur de GNU InetUtils. Le CERT-FR souligne de son côté que l’exploitation est triviale et qu’un code d’exploitation est déjà disponible publiquement, tout en rappelant que de nombreux services Telnet sont toujours accessibles sur Internet.
Une alerte à ne surtout pas prendre à la légère, les chercheurs de GreyNoise ayant confirmé avoir observé une hausse des tentatives d’exploitation entre les 21 et 22 janvier. Les activités recensées ciblent exclusivement des services Telnet exposés, avec une majorité de tentatives automatisées visant directement le compte root. Après l’accès initial, les attaquants procèdent à des actions classiques de reconnaissance et tentent, dans certains cas, de mettre en place des mécanismes de persistance. Si l’activité reste limitée en volume (18 IP sources distinctes pour une soixantaine de sessions observées sur moins de 24 heures), elle confirme que la faille a rapidement été intégrée dans des campagnes opportunistes.
Mettre à jour, isoler, surveiller
La priorité doit donc être donnée à la mise à jour des équipements concernés, dès lors qu’ils exécutent une version de GNU InetUtils antérieure à la 2.8. À défaut de mise à jour, le service doit être désactivé et remplacé par SSH.
Lorsque Telnet doit impérativement continuer à fonctionner, l’accès au service doit être strictement limité, notamment par le blocage du port TCP 23 au niveau des pare-feu, la restriction des connexions à un nombre très limité d’adresses IP de confiance, et le cloisonnement des flux afin qu’une compromission ne permette pas de rebondir vers d’autres systèmes.
Enfin, il faut prévoir un minimum de supervision, à savoir journaliser les connexions, poser des alertes sur les connexions entrantes sur le port TCP 23, surveiller les ouvertures de session inhabituelles, et, si pertinent, tracer les modifications de clés SSH pour éviter qu’un accès obtenu via Telnet ne débouche sur une persistance.
Sources : Simon Josefsson, CERT-FR, GreyNoise
