Alerte générale ! En théorie, il n’y a pas de raison de paniquer, mais en pratique… C’est, en creux, un peu le sens du dernier bulletin du CERT-FR. Une faille triviale a été identifiée dans Telnet ; elle permet de se connecter en root. En théorie, un serveur Telnet ne devrait jamais être accessible… mais c’est la théorie.
Le CERT-FR a publié un bulletin d’alerte pour informer que « les détails de la vulnérabilité CVE-2026-24061, affectant telnetd, ont été publiés ». Ils sont en effet disponibles sur un fil de discussion Openwall, dans la liste de diffusion oss-security.
Une faille et hop, vous voilà connecté en root sur le serveur
Telnetd – ou Telnet daemon – est la partie serveur du protocole Telnet (terminal network), « permettant de communiquer avec un serveur distant en échangeant des lignes de texte et en recevant des réponses également sous forme de texte » pour reprendre Wikipédia.
« Cette vulnérabilité permet à un attaquant de contourner l’authentification et de se connecter à une machine vulnérable en tant que l’utilisateur root ». Autant dire que c’est le scénario catastrophe, puisque root est l’utilisateur avec tous les droits, d’autant plus que le CERT-FR ajoute que cette faille a été « introduite en mars 2015 et affecte GNU InetUtils versions 1.9.3 à 2.7 », soit la dernière version disponible actuellement.
« A_ucun correctif officiel n’est disponible pour l’instant_ », ajoute le CERT-FR. Vous en voulez encore ? « Un code d’exploitation est publiquement disponible ». Cette vilaine faille est référencée sous le nom CVE-2026-24061 et son score CVSS 3.1 est de 9,8 sur 10.
#Fear Des serveurs telnet sont accessibles sur Internet
Selon les constatations du CERT-FR, des services telnet sont accessibles sur Internet, « ce qui est contraire aux bonnes pratiques »… Au-delà de la faille, il y a depuis toujours une bonne raison de ne pas exposer Telnet sur le Net : « Les mots de passe Telnet ne sont pas chiffrés lorsqu’ils sont envoyés entre le client traditionnel et le serveur », comme le rappelle IBM.
Le CERT-FR recommande donc de supprimer les services telnet et, si c’est impossible, de ne pas exposer le service directement sur Internet, ou a minima d’en restreindre l’accès à certaines adresses IP (liste blanche). Évidemment, il faudra appliquer les correctifs dès que possible une fois ces derniers disponibles.
Telnet est remplacé par SSH depuis longtemps
Telnet est un vieux protocole, remplacé depuis longtemps par d’autres plus récents, dont SSH, ce qui devrait (en théorie) limiter les risques. En cybersécurité, on n’est jamais à l’abri d’une mauvaise nouvelle et/ou configuration.
Comme le rappelait déjà l’ANSSI en 2015, « SSH, ou Secure SHell, est un protocole applicatif qui vise à corriger les déficiences connues dans les protocoles FTP, RSH, RCP et Telnet ». L’Agence ajoutait que « l’avantage évident apporté par SSH est sa sécurité ».
« Là où Telnet n’apporte ni authentification du serveur ni création d’un canal chiffré et authentifié, SSH va permettre de le faire dès lors que quelques règles d’hygiène simples sont appliquées », détaillait l’ANSSI. Les recommandations d’il y a 10 ans étaient claires : utiliser SSH à la place des protocoles historiques pour des accès shell distants, mais aussi désinstaller Telnet comme service d’accès à distance.
Pour rappel, SSH est par défaut sur le port 22, Telnet sur le 23. Si, côté client, vous avez un doute, regardez la configuration de votre PUTTY : Connection type doit être sur SSH (port 22) et pas sur Other: Telnet (port 23).
Source : next.ink
