Connexion Premium

Telnet : une faille triviale vieille de 10 ans permet de se connecter en root

Telnet c'est tabou

Telnet : une faille triviale vieille de 10 ans permet de se connecter en root

Illustration : Flock

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.

« Aucun 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).

Commentaires (18)

votre avatar
Je suis tes inquiet pour towel.blinkenlights.nl !
votre avatar
C'est pas mort depuis longtemps ?
Sinon il y a telehack.com ;-)
votre avatar
Non ça a l'air de fonctionner encore.
votre avatar
C'est de toute beauté ! 👌
votre avatar
Ah, je ne suis pas le seul à trouver ça génial. On va pouvoir reprendre la main sur tout un tas de matos verrouillés sans les démonter/dumper/flasher 😄
votre avatar
Si, côté client, vous avez un doute, regardez la configuration de votre PUTTY : Connection type doit être sur SSH (porte 22) et pas sur Other: Telnet (port 23).
Pour quoi faire Putty ? La commande ssh me suffit :langue:
votre avatar
Si mes souvenirs sont bon, y a pas mal de devices connectés qui utilise encore telnet, comme des box internet ou des enceintes connectés. Pas sur que se soit bien fermé…
votre avatar
La dernière fois que j'ai vu utiliser Telnet, c'était sous Windows 7 ...
votre avatar
Alors c’est une faille dans inetutils, dans le composant telnetd. Pas une faille dans le protocole telnet (qui en a déjà une très grosse, vu que tout est en clair).

Ça mériterait d’être rectifié, la news induit en erreur en parlant de telnet. Il y a beaucoup d’implémentations différentes de telnet (faut dire, c’est pas compliqué à implémenter), dont une dans windows, qui n’est vraisemblablement pas concernée par cette faille.
votre avatar
qui en EST déjà une très grosse (à moins que j'ai mal compris ta phrase :roll:)
votre avatar
Je n'appellerais pas une faille le simple fait que les communications ne sont pas chiffrées. C'est une contrainte technique due au fait que Telnet a été pensé pour tourner sur des machines très limitées (je ne suis pas trop sûr qu'un PDP 11/70 avait un CPU suffisant pour faire du chiffrement de flux en temps réel.) Même remarque pour http.

Continuer à l'utiliser est une faille de sécurité dans les procédures de l'entreprise, pas dans le design de Telnet.
votre avatar
Petite pensée à tout les vieux RPG textuels multijoueurs (MUD) qui tournent encore et qui utilisent quasi tous telnet à ma connaissance
votre avatar
C'est bien, j'ai profité de l'occasion pour faire un scan du réseau et réaliser qu'on avait encore 24 switches sur lesquels le service était actif. C'est pas la variante inetutils de telnet, et c'était sur un subnet à l'accès restreint, mais ça n'avait aucun intérêt à être encore actif.
votre avatar
nous sommes en 2026, ceux qui installent encore telnet n'ont qu'à s'en prendre à eux-mêmes pour tout ce que cela implique comme risque.
votre avatar
Installer un telnet sur une distribution Linux de moins de 10 ans, il faut vraiment le vouloir. Le dernier telnet que j'ai vu tourner c'était sur une station SGI sous Irix qui pourrissait depuis 20 ans car elle pilotait un appareil de RMN. Et ça fait 5 ans que c'est parti à la poubelle.
Maintenant dans de l'embarqué bas de gamme, je ne serais pas surpris que l'on en trouve encore dans les foyers. Et là, il faut que Madame Michu s'en rende compte et qu'elle accepte de balancer l'appareil qui ne sera bien sûr jamais mis à jour. Le scénario me semble bien plus probable qu'un informaticien pensant encore en 2026 qu'il faut activer le service telnetd
votre avatar
Pour des question de backward avec nos logiciels, on maintenu un accès Telnet jusqu'à fin 2024. On a remplacé Telnet par une console Web et une API Rest depuis 2020. Lorsqu'on a supprimé Telnet, on a reçu une volée de bois-vert de la part de nos clients.
On ne savait à quel point c'était encore utilisé.
votre avatar
nmap -Pn -p 23 --open 192.168.1.0/24
votre avatar
Vu le nombre de Telnet qui traine encore sur les reseau OT et qui a mon avis tourne sur du Telnetd :eeek2:

Globalement en 2026 une entreprise de taille moyenne sait gérer son parc machine plutôt correctement, par contre son réseau OT c'est autre chose :D