Le jour où Telnet a disparu

 (labs.greynoise.io)
4 points par GN⁺ 2026-02-12 | 1 commentaires | Partager sur WhatsApp
  • Le 14 janvier 2026 à 21 h (UTC), le trafic Telnet mondial s’est brutalement effondré, avec une baisse persistante de 59 % confirmée par le réseau d’observation
  • 18 ASN sont devenus complètement silencieux, et le trafic a entièrement disparu dans 5 pays (Zimbabwe, Ukraine, Canada, Pologne, Égypte)
  • Les principaux fournisseurs cloud (AWS, Contabo, etc.) ont au contraire progressé, tandis que les ISP nord-américains ont subi une forte baisse
  • Six jours plus tard, la vulnérabilité de contournement d’authentification de GNU Inetutils telnetd (CVE-2026-24061) a été rendue publique, confirmant une faille critique permettant d’obtenir les privilèges root
  • Le secteur s’intéresse à l’hypothèse d’un filtrage du port 23 au niveau du backbone mis en place après notification préalable, et considère cet épisode comme symbolique de la fin de Telnet

Effondrement du trafic Telnet mondial

  • Le 14 janvier 2026 à 21 h (UTC), la GreyNoise Global Observation Grid a détecté un effondrement brutal du trafic Telnet
    • En une heure, on est passé d’environ 74 000 sessions à 22 000, soit une chute de 65 %
    • Deux heures plus tard, le niveau est tombé à 11 000 sessions, soit une baisse de 83 %, avant de se stabiliser
  • Par rapport à la moyenne quotidienne de 910 000 sessions observée entre décembre 2025 et début janvier 2026, le trafic est ensuite descendu à 370 000 sessions, soit une baisse de 59 %
  • Il ne s’agit pas d’un déclin progressif mais d’une rupture brutale à un instant précis (changement de type fonction en escalier), ce qui suggère une possible modification de configuration dans l’infrastructure de routage

Réseaux et pays devenus silencieux

  • 18 ASN sont passés à 0 trafic Telnet après le 15 janvier
    • Vultr (AS20473) : 380 000 → 0, Cox Communications (AS22773) : 150 000 → 0
    • Y compris Charter/Spectrum (AS20115), BT/British Telecom (AS2856), etc.
  • Disparition complète du trafic dans 5 pays (Zimbabwe, Ukraine, Canada, Pologne, Égypte)
  • À l’inverse, AWS a progressé de 78 %, Contabo de 90 %, et DigitalOcean s’est maintenu à +3 %
    • Les fournisseurs cloud ont évité l’impact du filtrage backbone via des réseaux de peering privés

Hypothèse d’un filtrage du port 23

  • Le schéma observé suggère qu’un fournisseur nord-américain de transit Tier 1 a appliqué un filtrage du port 23
    • Le moment correspond à 16 h, heure de la côte Est des États-Unis, en phase avec une fenêtre de maintenance américaine
    • Les ISP américains comme Cox, Charter, Comcast (-74 %) ont été fortement touchés
    • Verizon/UUNET (AS701) recule de 79 %, pouvant être l’acteur du filtrage ou un chemin amont majeur en cause
  • Les pays européens en peering direct (France +18 %, Allemagne -1 %) ont été peu affectés
  • Les opérateurs chinois China Telecom et China Unicom enregistrent tous deux une baisse de 59 %
    • Cette baisse uniforme suggère un filtrage sur les liens transpacifiques côté américain

Divulgation de la vulnérabilité CVE-2026-24061

  • Vulnérabilité de contournement d’authentification dans GNU Inetutils telnetd, classée CVSS 9.8
    • Lors du traitement de la variable d’environnement USER, une injection d’argument permet, en passant -f root, d’obtenir un shell root sans authentification
    • Introduite par un commit de 2015, elle est restée non détectée pendant environ 11 ans
  • Calendrier principal
    • 14 janvier : début de l’effondrement du trafic Telnet
    • 20 janvier : publication de la CVE
    • 21 janvier : inscription au NVD et premières exploitations observées
    • 26 janvier : ajout à la liste CISA KEV
  • Le trafic s’est effondré 6 jours avant la publication de la CVE, ce qui alimente l’idée d’un lien allant au-delà d’une simple coïncidence

Hypothèse d’une notification préalable et d’une réponse d’infrastructure

  • Les auteurs du signalement de la vulnérabilité seraient Kyu Neushwaistein / Carlos Cortes Alvarez, avec un rapport daté du 19 janvier
  • Le fait que la préparation du correctif et la réponse de la CISA aient été engagées dès le lendemain de la publication laisse envisager une coordination préalable
  • GreyNoise avance le scénario suivant
    • Les principaux opérateurs d’infrastructure auraient été prévenus à l’avance et appliqué de manière préventive un filtrage du port 23
    • Mise en service du filtrage le 14 janvier → publication le 20 janvier → inscription CISA le 26 janvier
  • Aucune preuve claire n’existe, et une simple coïncidence de calendrier reste aussi possible

Évolution du trafic Telnet par la suite

  • Après le 14 janvier, un profil en dents de scie persiste
    • Exemple : 800 000 sessions le 28 janvier → 190 000 sessions le 30 janvier
    • Cela peut correspondre à un filtrage intermittent, à des variations de routage ou à une campagne de scan spécifique
  • Moyennes hebdomadaires
    • Semaine du 19 janvier : 360 000 sessions (40 % du niveau de référence)
    • Semaine du 2 février : 320 000 sessions (35 %)
  • Le trafic s’est stabilisé autour d’environ un tiers du niveau de référence, tout en poursuivant sa baisse

Enseignements pour la sécurité et l’exploitation

  • Les utilisateurs de GNU Inetutils telnetd doivent mettre à jour immédiatement vers la version 2.7-2 ou supérieure ou désactiver le service
    • La CISA fixe au 16 février 2026 la date limite de correctif pour les agences fédérales
    • Des tentatives d’exploitation ont été observées en quelques heures après la divulgation publique, atteignant 2 600 sessions par jour début février avant de reculer
  • Les opérateurs réseau doivent envisager un filtrage du port 23
    • Un filtrage est déjà en cours au niveau backbone, et le trafic Telnet est désormais considéré comme un protocole sans valeur
  • GreyNoise note que « quelqu’un a coupé Telnet sur une part significative d’Internet »,
    et y voit un événement symbolisant la fin de l’ère Telnet

À lire aussi

1 commentaires

 
GN⁺ 2026-02-12
Avis de Hacker News

  • Ce qui est plus grave que telnetd, c’est le fait que des fournisseurs de transit Tier 1 aient commencé à filtrer des ports
    Cela signifie que l’internet est fragmenté, et qu’il est désormais impossible de contourner cela même avec le routage automatique (BGP)

    • Quand je travaillais autrefois dans un petit FAI, le ver Blaster a explosé, et bloquer des ports comme le 139 était la réponse la plus rapide
      À l’époque, la plupart des FAI ont bloqué ces ports, et au final c’est devenu plus sûr
      Si quelqu’un a vraiment besoin de telnet, il peut le déplacer sur un autre port ou le faire passer par un tunnel
      Je me demande s’il y a encore des gens qui font tourner telnet sur le port 23 par défaut
    • Le risque de censure est un problème, mais le fait que des systèmes comme les hôpitaux, les banques ou le nucléaire se fassent pirater et mettent des vies en danger est aussi extrêmement grave
      Les gens qui prennent ce type de décision portent à la fois l’autorité et la responsabilité
    • Le port 23 est déjà filtré par la plupart des fournisseurs depuis des décennies
      C’est pour cela que tout se concentre sur le port 443 avec TLS
      Il ne faut pas crier à la censure pour ça ; la vraie censure, il faut plutôt la chercher du côté de lois comme FOSTA/SESTA
    • À mon avis, bloquer des ports, ce n’est au fond pas différent de la censure
    • J’ai pu me connecter à des serveurs à Seattle et aux Pays-Bas via le client GNU telnet en passant par le FAI Spectrum

  • C’est vraiment un bug étonnant
    Pendant la première décennie de l’internet, on utilisait presque uniquement telnet
    À l’époque, il suffisait de regarder le trafic Ethernet pour voir les mots de passe en clair, et la plupart des systèmes étaient multi-utilisateurs
    J’ai du mal à croire qu’une commande comme telnet -l 'root -f' server.test ait survécu pendant 11 ans

    • Plus je travaille longtemps dans le logiciel, plus je trouve étonnant que le monde fonctionne comme ça
      J’ai l’impression qu’il reste encore beaucoup de vulnérabilités de type fruit à portée de main
    • Je ne me connectais pas en root, mais il fut un temps où je naviguais sur le web avec lynx depuis mon compte AIX à l’école
      À l’époque, je n’imaginais même pas que le trafic pouvait être surveillé ; c’était juste une époque plus libre
      Je faisais tout en telnet : le mail avec pine, le web avec lynx, et même l’IRC
    • Je ne me souviens même plus à quel moment j’ai arrêté d’utiliser telnet
      Il y avait d’innombrables serveurs qui laissaient l’accès telnet root ouvert, et ils ne se faisaient jamais pirater
      Cette époque me manque vraiment
    • Ça me rappelle qu’il y avait aussi autrefois des vulnérabilités du genre rlogin -l '-froot'
      À cette époque, ce genre de choses était courant
    • Je ne l’utilisais pas pour me connecter, mais c’était encore utile comme outil de débogage
      Je m’en servais souvent pour vérifier si le trafic passait bien entre des conteneurs

  • Le client Telnet lui-même n’est pas encore mort
    Autrefois, on se connectait à des serveurs SMTP (port 25) avec telnet pour envoyer des mails usurpés
    Mais avec la multiplication des blocages de ports au nom de la sécurité, j’ai l’impression que tous les services finiront par se concentrer sur le port 443

    • De nos jours, des outils comme netcat, socat, openssl s_client sont de bien meilleures alternatives
      Ils sont bien plus puissants que telnet
    • Quand j’étais plus jeune, j’ai déjà envoyé des SMS avec telnet
      Pour le destinataire, cela apparaissait comme s’ils venaient d’un compte officiel de l’opérateur ; à l’époque c’était innocent, mais en y repensant, c’était une plaisanterie risquée
    • Le client telnet ou telnetd lui-même restent encore utilisables
      Mais il semble que le port par défaut soit désormais bloqué au niveau du routage global
      Cela ressemble à une mesure destinée à protéger des anciens systèmes non sécurisés

  • Je ne comprends toujours pas pourquoi on utilise encore telnet sur internet
    Ce n’est pas, pour l’essentiel, du trafic d’attaque ?

    • Certains le maintiennent pour préserver des systèmes historiques
    • En réalité, c’est pour regarder ASCII Star Wars
      telnet towel.blinkenlights.nl
      Lien vidéo YouTube
    • Dans les équipements legacy, IoT et industriels, telnet est encore utilisé
      Même SSH est souvent employé de façon peu rigoureuse en matière de sécurité
      Par exemple en désactivant la vérification de la clé d’hôte, ou en utilisant des clés sans mot de passe
      Donc, en pratique, une combinaison telnet + WebSocket HTTPS + OAuth peut parfois être plus sûre
    • En radioamateur (HAM), le chiffrement est interdit, donc on utilise telnet
      En revanche, la transmission de données signées est autorisée, ce qui crée un besoin pour des protocoles alternatifs de ce type
    • Les serveurs de jeux textuels comme les MUD ou MOO utilisent encore majoritairement telnet

  • Ce CVE est une bonne nouvelle pour la communauté du piratage d’équipements embarqués
    Les chances d’obtenir les privilèges root sur des appareils avec telnetd ouvert ont augmenté

    • Je l’ai testé moi-même sur un point d’accès Wi‑Fi Zyxel, mais comme il utilisait un telnetd basé sur busybox, il n’était apparemment pas vulnérable

  • Le CVE en question provient de ce commit
    Le point clé est le remplacement de user_name par uname, et je me demandais pourquoi un tel renommage était nécessaire

    • Si on regarde le ChangeLog, user_name entrait en conflit de nom (shadowing) avec une variable globale, d’où ce changement
    • Mais je pense qu’au-delà de ce correctif, il est encore plus important d’examiner les appels à getenv()
      L’analyse des valeurs d’entrée est difficile, et c’est souvent là que naissent les vulnérabilités

  • Il est intéressant que quelqu’un ait décidé de jeter le trafic telnet tout en haut de l’infrastructure de transit internet
    C’était peut-être la bonne décision
    Je me demande si cela aura un impact sur le trafic MUD

    • La plupart des MUD n’utilisent pas directement le protocole Telnet
      Ils reposent simplement sur du TCP, et préfèrent des clients dédiés
      Le port 23 est réservé par l’IANA pour Telnet, mais les MUD utilisent en général des ports élevés à 4 chiffres
      Au contraire, les faire tourner sur le port 23 rendrait probablement leur accès plus difficile aujourd’hui
    • Ce n’est pas clairement indiqué dans l’article, mais il semble probable qu’ils ne filtrent que le trafic d’attaque
      Telnet étant en clair, il peut être facilement détecté par analyse de motifs
    • Il est probable qu’il s’agisse d’un blocage basé sur les ports, comme pour le blocage du port SMTP
      De nos jours, pour un serveur sur le réseau public, il faut utiliser SSH

  • Ce CVE et la réponse qui y a été apportée sont vraiment un événement historique
    J’ai du mal à croire qu’une seule personne ait, en pratique, mis fin à l’ère de telnet

    • En réalité, il y avait deux personnes : celle qui a soumis la PR et celle qui l’a approuvée
      Ce n’est pas la faute du chercheur en sécurité

  • Pendant mon stage, j’ai trouvé fascinant de découvrir qu’on pouvait se connecter en telnet à un téléphone VoIP posé sur le bureau

    • Moi aussi, pendant mon stage, je testais des scripts CGI Perl en telnet
      J’étais habitué aux commandes Hayes, donc taper directement des requêtes HTTP me semblait naturel
    • Moi aussi, je faisais ça ; c’est un souvenir amusant

  • En regardant récemment les statistiques de mon serveur telnet, j’ai constaté une moyenne d’environ 2 000 adresses IP qui s’y connectent
    Il y a eu un pic à 7 500 à la mi-janvier, puis c’est redescendu, et en février on est tombé autour de 1 000