Der Tag, an dem Telnet verschwand

 (labs.greynoise.io)
4 Punkte von GN⁺ 2026-02-12 | 1 Kommentare | Auf WhatsApp teilen
  • Am 14. Januar 2026 um 21:00 Uhr (UTC) brach der weltweite Telnet-Traffic abrupt ein; im Beobachtungsnetz wurde ein anhaltender Rückgang um 59 % festgestellt
  • 18 ASNs verstummten vollständig, und der Traffic aus 5 Ländern (Simbabwe, Ukraine, Kanada, Polen und Ägypten) verschwand komplett
  • Große Cloud-Anbieter (AWS, Contabo usw.) legten hingegen zu, während ISPs in Nordamerika starke Rückgänge verzeichneten
  • Sechs Tage später wurde die Authentication-Bypass-Schwachstelle in GNU Inetutils telnetd (CVE-2026-24061) veröffentlicht, ein kritischer Fehler, der Root-Rechte ermöglichen kann
  • Die Branche richtet den Blick auf die Möglichkeit eines Port-23-Filterns auf Backbone-Ebene als Maßnahme nach Vorabinformation und bewertet dies als symbolisches Ereignis für das Ende von Telnet

Weltweiter Einbruch des Telnet-Traffics

  • Am 14. Januar 2026 um 21:00 Uhr (UTC) erkannte das GreyNoise Global Observation Grid einen abrupten Einbruch des Telnet-Traffics
    • Von rund 74.000 Sessions eine Stunde zuvor fiel der Wert in der nächsten Stunde um 65 % auf 22.000
    • Zwei Stunden später sank er auf 11.000 Sessions, ein Rückgang von 83 %, und blieb anschließend auf diesem Niveau
  • Gegenüber den durchschnittlich 910.000 täglichen Sessions von Dezember 2025 bis Anfang Januar 2026 sank der Wert danach auf etwa 370.000 Sessions, also 59 % weniger
  • Die Veränderung war kein gradueller Rückgang, sondern ein abrupter Bruch zu einem einzigen Zeitpunkt (step-function-artige Veränderung), was auf eine mögliche Änderung in der Routing-Infrastruktur hindeutet

Verstummte Netzwerke und Länder

  • 18 ASNs wechselten ab dem 15. Januar auf Telnet-Traffic von „0“
    • Vultr (AS20473) 380.000 → 0, Cox Communications (AS22773) 150.000 → 0
    • Darunter auch Charter/Spectrum (AS20115), BT/British Telecom (AS2856) usw.
  • Der Traffic aus 5 Ländern (Simbabwe, Ukraine, Kanada, Polen, Ägypten) verschwand vollständig
  • AWS +78 %, Contabo +90 %, DigitalOcean stabil bei +3 %
    • Cloud-Anbieter umgingen die Auswirkungen des Backbone-Filterns über private Peering-Netze

Möglichkeit eines Port-23-Filterns

  • Das Muster deutet darauf hin, dass ein nordamerikanischer Tier-1-Transit-Anbieter Port-23-Filtering angewendet haben könnte
    • Der Zeitpunkt entsprach 16:00 Uhr US-Ostküstenzeit und damit einem Wartungsfenster in den USA
    • US-ISPs wie Cox, Charter, Comcast (-74 %) wurden stark getroffen
    • Verizon/UUNET (AS701) verzeichnete 79 % Rückgang und kommt als ausführender Backbone-Anbieter oder Upstream-Pfad in Betracht
  • Länder mit direktem europäischem Peering (Frankreich +18 %, Deutschland -1 %) waren kaum betroffen
  • Chinesische Netzbetreiber (China Telecom, China Unicom) verzeichneten beide einen Rückgang um 59 %
    • Die gleichmäßige Rückgangsquote deutet auf ein mögliches Filtering auf transpazifischen Links auf US-Seite hin

Veröffentlichung der Schwachstelle CVE-2026-24061

  • Authentication-Bypass-Schwachstelle in GNU Inetutils telnetd, CVSS 9.8
    • Bei der Verarbeitung der Umgebungsvariable USER kann per Argument-Injection mit -f root ohne Authentifizierung eine Root-Shell erlangt werden
    • Der Fehler wurde mit einem Commit von 2015 eingeführt und blieb rund 11 Jahre unentdeckt
  • Wichtige Termine
      1. Januar: Beginn des Telnet-Traffic-Einbruchs
      1. Januar: Veröffentlichung der CVE
      1. Januar: Eintrag in die NVD und erste beobachtete Ausnutzung
      1. Januar: Aufnahme in die CISA-KEV-Liste
  • Der Traffic-Einbruch begann 6 Tage vor der Veröffentlichung der CVE, was die Möglichkeit eines Zusammenhangs über einen bloßen Zufall hinaus aufwirft

Hypothese zu Vorabinformation und Infrastruktur-Reaktion

  • Als Melder der Schwachstelle werden Kyu Neushwaistein / Carlos Cortes Alvarez genannt; die Meldung soll am 19. Januar erfolgt sein
  • Dass Patch-Vorbereitung und CISA-Reaktion innerhalb eines Tages nach Veröffentlichung erfolgten, deutet auf eine mögliche vorherige Abstimmung hin
  • GreyNoise skizziert folgendes Szenario
    • Große Infrastrukturbetreiber wurden vorab informiert und setzten proaktiv Port-23-Filtering um
      1. Januar: Aktivierung des Filterns → 20. Januar: Veröffentlichung → 26. Januar: CISA-Eintrag
  • Es gibt keine eindeutigen Belege, und auch ein bloßer zeitlicher Zufall wird erwähnt

Telnet-Traffic danach

  • Seit dem 14. Januar hält ein sägezahnartiges Muster an
    • Beispiel: 800.000 Sessions am 28. Januar → 190.000 Sessions am 30. Januar
    • Möglich sind intermittierendes Filtering, Routing-Änderungen oder bestimmte Scanner-Kampagnen
  • Wochenmittel
    • Woche vom 19. Januar: 360.000 Sessions (40 % des Ausgangswerts)
    • Woche vom 2. Februar: 320.000 Sessions (35 %)
  • Stabilisierung bei etwa einem Drittel des Ausgangsniveaus, weiterhin mit sinkender Tendenz

Folgen für Sicherheit und Betrieb

  • Nutzer von GNU Inetutils telnetd sollten sofort auf 2.7-2 oder neuer aktualisieren oder den Dienst deaktivieren
    • CISA setzt für Bundesbehörden eine Patch-Frist bis 16. Februar 2026
    • Kurz nach der Veröffentlichung wurden innerhalb weniger Stunden Ausnutzungsversuche beobachtet; Anfang Februar stieg dies auf bis zu 2.600 Sessions pro Tag und ging danach zurück
  • Netzwerkbetreiber sollten Port-23-Filtering prüfen
    • Auf Backbone-Ebene wird bereits gefiltert, und Telnet-Traffic gilt nicht länger als wertvolles Protokoll
  • GreyNoise hält fest, dass „jemand Telnet in weiten Teilen des Internets abgeschaltet hat“, und bewertet dies als ein Ereignis, das das Ende des Telnet-Zeitalters symbolisiert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-12
Hacker-News-Kommentare

  • Noch gravierender als telnetd ist die Tatsache, dass Tier-1-Transit-Anbieter mit dem Filtern von Ports begonnen haben.
    Das bedeutet eine Fragmentierung des Internets, und mit automatischem Routing (BGP) lässt sich das nicht mehr umgehen.

    • Als ich früher bei einem kleinen ISP gearbeitet habe, brach der Blaster-Wurm aus, und das Blockieren von Ports wie 139 war die schnellste Reaktion.
      Damals haben die meisten ISPs Ports gesperrt, und dadurch wurde alles letztlich sicherer.
      Wenn man wirklich Telnet braucht, kann man es auf einen anderen Port legen oder tunneln.
      Ich frage mich, ob heute überhaupt noch jemand Telnet auf dem Standard-Port 23 betreibt.
    • Das Risiko von Zensur ist ein Problem, aber ebenso ernst ist es, wenn Systeme in Krankenhäusern, Banken oder Kernkraftwerken gehackt werden und Menschenleben gefährdet sind.
      Die Leute, die solche Entscheidungen treffen, tragen zugleich Befugnis und Verantwortung.
    • Port 23 wird von den meisten Anbietern schon seit Jahrzehnten gefiltert.
      Deshalb verlagert sich alles auf TLS-Port 443.
      Das ist nichts, worüber man laut „Zensur“ rufen sollte; echte Zensur findet man eher in Gesetzen wie FOSTA/SESTA.
    • Ich finde, Ports zu blockieren ist letztlich nichts anderes als Zensur.
    • Ich konnte über den ISP Spectrum mit dem GNU-Telnet-Client auf Server in Seattle und den Niederlanden zugreifen.

  • Das ist wirklich ein erstaunlicher Bug.
    In den ersten zehn Jahren des Internets wurde fast nur Telnet benutzt.
    Wenn man damals Ethernet-Traffic ansah, konnte man Passwörter im Klartext sehen, und die meisten Systeme waren Mehrbenutzerumgebungen.
    Dass ein Befehl wie telnet -l 'root -f' server.test 11 Jahre lang überlebt hat, ist kaum zu glauben.

    • Je länger ich in der Softwarebranche arbeite, desto erstaunlicher finde ich einfach, dass die Welt so funktioniert.
      Vermutlich gibt es noch viele Schwachstellen, die wie tief hängende Früchte sind.
    • Ich habe mich zwar nicht als root angemeldet, aber es gab eine Zeit, in der ich mit meinem AIX-Schulkonto per lynx im Web unterwegs war.
      Damals dachte ich nicht einmal daran, dass der Traffic überwacht werden könnte; es war einfach eine freiere Zeit.
      Per Telnet habe ich Mail (pine), Web (lynx) und sogar IRC genutzt.
    • Ich erinnere mich nicht einmal mehr daran, wann ich aufgehört habe, Telnet zu benutzen.
      Unzählige Server hatten Root-Logins per Telnet offen, und keiner wurde je gehackt.
      Ich vermisse diese Zeit wirklich.
    • Ich erinnere mich daran, dass es früher auch Schwachstellen wie rlogin -l '-froot' gab.
      Solche Dinge waren damals ganz normal.
    • Zum Einloggen habe ich es nicht benutzt, aber als Debugging-Werkzeug war es weiterhin nützlich.
      Ich habe es oft verwendet, um zu prüfen, ob Traffic zwischen Containern durchkommt.

  • Der Telnet-Client selbst ist noch nicht tot.
    Früher hat man sich per Telnet mit SMTP-Servern (Port 25) verbunden und Spoofing-Mails verschickt.
    Aber weil unter dem Vorwand der Sicherheit immer mehr Ports blockiert werden, werden am Ende wohl alle Services auf Port 443 zusammenlaufen.

    • Heutzutage sind Tools wie netcat, socat, openssl s_client viel bessere Alternativen.
      Sie sind deutlich leistungsfähiger als Telnet.
    • Als Kind habe ich einmal per Telnet SMS verschickt.
      Für den Empfänger sah es aus wie ein offizielles Konto des Mobilfunkanbieters, und damals war es unschuldig gemeint, aber rückblickend war es ein gefährlicher Streich.
    • Den Telnet-Client oder telnetd selbst kann man noch immer benutzen.
      Es scheint nur so zu sein, dass der Standard-Port auf Ebene des globalen Routings blockiert wird.
      Das wirkt wie eine Maßnahme zum Schutz alter, ungesicherter Systeme.

  • Ich verstehe immer noch nicht, warum man Telnet im Internet verwendet.
    Ist das nicht größtenteils Angriffstraffic?

    • Manche betreiben es zur Bewahrung historischer Systeme.
    • Eigentlich nur, um ASCII Star Wars anzuschauen.
      telnet towel.blinkenlights.nl
      YouTube-Video-Link
    • In Legacy-, IoT- und Industrieanlagen wird Telnet noch immer verwendet.
      Auch SSH wird in der Praxis oft unsauber eingesetzt, etwa mit deaktivierter Host-Key-Prüfung oder passwortlosen Schlüsseln.
      Daher könnte die Kombination Telnet + HTTPS-WebSocket + OAuth in der Realität sogar sicherer sein.
    • Im Amateurfunk (HAM) ist Verschlüsselung verboten, deshalb wird Telnet verwendet.
      Signierte Datenübertragung ist jedoch erlaubt, daher braucht es dafür alternative Protokolle.
    • Textbasierte Spieleserver wie MUD oder MOO verwenden meist noch immer Telnet.

  • Diese CVE ist für die Community rund um das Hacken eingebetteter Geräte eine gute Nachricht.
    Die Chancen sind gestiegen, auf Geräten mit offenem telnetd Root-Rechte zu erlangen.

    • Ich habe es direkt auf einem Zyxel-WiFi-AP getestet, aber wahrscheinlich war es wegen des BusyBox-basierten telnetd nicht verwundbar.

  • Die betreffende CVE stammt aus diesem Commit.
    Entscheidend war die Umbenennung von user_name zu uname, und ich habe mich gefragt, warum so eine Umbenennung überhaupt nötig war.

    • Laut ChangeLog wurde user_name geändert, weil es mit einer globalen Variable einen Namenskonflikt (Shadowing) verursachte.
    • Aber wichtiger als solche Änderungen wäre es meiner Meinung nach, getenv()-Aufrufe zu prüfen.
      Beim Parsen von Eingabewerten entstehen dort oft Schwachstellen.

  • Es ist interessant, dass jemand ganz oben in der Internet-Transit-Infrastruktur entschieden hat, Telnet-Traffic zu verwerfen.
    Vielleicht war das sogar die richtige Entscheidung.
    Ich frage mich, ob das Auswirkungen auf MUD-Traffic hat.

    • Die meisten MUDs verwenden nicht direkt das Telnet-Protokoll.
      Sie basieren einfach auf TCP und bevorzugen spezialisierte Clients.
      Port 23 ist bei der IANA zwar für Telnet reserviert, aber MUDs verwenden normalerweise höhere vierstellige Ports.
      Tatsächlich dürfte es heute eher schwieriger sein, einen Dienst auf Port 23 erreichbar zu machen.
    • Im Artikel wird das nicht klar gesagt, aber vermutlich wird nur Angriffstraffic gefiltert.
      Telnet ist unverschlüsselt und lässt sich deshalb durch Musteranalyse leicht erkennen.
    • Wahrscheinlich ist es ein portbasierter Block wie bei der SMTP-Port-Sperre.
      Wenn man heute einen Server im öffentlichen Netz betreibt, sollte man SSH verwenden.

  • Diese CVE und die Reaktion darauf sind wirklich ein historisches Ereignis.
    Kaum zu glauben, dass eine einzelne Person faktisch das Telnet-Zeitalter beendet hat.

    • Tatsächlich waren es zwei Personen: eine hat den PR eingereicht und eine andere ihn freigegeben.
      Es ist nicht die Schuld des Sicherheitsforschers.

  • Als ich Praktikant war, fand ich es unglaublich faszinierend, dass man sich per Telnet mit dem VoIP-Telefon auf meinem Schreibtisch verbinden konnte.

    • Auch ich habe als Praktikant Perl-CGI-Skripte per Telnet getestet.
      Ich war an Hayes-Befehle gewöhnt, deshalb war es für mich ganz natürlich, HTTP-Requests direkt einzutippen.
    • Ging mir genauso, schöne Erinnerung.

  • Laut den aktuellen Statistiken meines Telnet-Servers verbinden sich im Schnitt etwa 2000 IPs.
    Mitte Januar gab es einen sprunghaften Anstieg auf 7500, danach ging es wieder zurück, und im Februar fiel es auf etwa 1000.