Wenn ich an Telnet denke, habe ich sofort dieses typische Gefühl von „Das ist doch ein Thema von früher“. So ein Dienst, den man irgendwo zwischen Röhrenmonitor, Diskette und Serverraum-Legenden einsortiert.
Genau deshalb finde ich die aktuelle Telnetd-Sicherheitslücke so spannend — und auch so unangenehm. Denn sie zeigt mal wieder, dass alte Technik nicht harmlos wird, nur weil man sie innerlich längst abgehakt hat.
Im Gegenteil: Gerade das, was irgendwo noch still mitläuft, kann im Ernstfall plötzlich zum echten Problem werden. Und genau darum lohnt sich ein genauer Blick auf das aktuelle Telnetd-Problem.
Die aktuelle Schwachstelle in GNU InetUtils telnetd hat sich ganz heimlich angeschlichen: altbekanntes Protokoll, alte Gewohnheiten – aber brandgefährliche Folgen.
Und ja, Telnet klingt erst mal nach Museum, Mottenkugel und Modemgeräusch. Das Problem ist nur: In vielen Umgebungen ist „alt“ leider nicht automatisch „weg“.
In vielen gewachsenen Infrastrukturen, bei Spezialanwendungen, in Produktionsnetzen oder auf lange gepflegten Linux-Systemen taucht Telnet immer noch auf. Genau deshalb sollten IT-Verantwortliche jetzt hinschauen.
Hacker News berichtet, dass mit CVE-2026-32746 eine kritische Schwachstelle bekannt wurde, die es Angreifern unter Umständen ermöglicht, Code mit Root-Rechten auszuführen – ohne Anmeldung.
Anders gesagt: bevor überhaupt ein Login erscheint, kann es schon zu spät sein.
Telnet ist ein sehr altes Netzwerkprotokoll, mit dem man sich auf entfernten Systemen anmelden und dort Befehle ausführen kann. Der Dienst, der diese Verbindungen entgegennimmt, heißt telnetd.
Früher war das normal. Heute gilt Telnet in den meisten modernen IT-Umgebungen als problematisch, weil es nicht für heutige Sicherheitsanforderungen gemacht ist.
Es fehlt der Schutz, den man inzwischen von sicheren Fernzugriffen erwartet. Deshalb wurde Telnet in vielen Bereichen längst durch SSH ersetzt.
Trotzdem lebt Telnet stellenweise weiter. Nicht, weil es jemand liebt. Sondern weil Legacy-Systeme manchmal die Hartnäckigkeit eines Kaugummis unter dem Konferenztisch haben.
Die Schwachstelle CVE-2026-32746 betrifft den GNU InetUtils telnetd. Laut den aktuellen Berichten handelt es sich um eine kritische Sicherheitslücke mit einem CVSS-Wert von 9,8 von 10.
Ursache ist ein Out-of-Bounds-Write im LINEMODE-SLC-Handler. Also ein Speicherfehler, der in einen Buffer Overflow führen kann.
Der Fehler lässt sich während des Verbindungsaufbaus auslösen — noch vor dem Login-Prompt.
Ein Angreifer braucht also keine gültigen Zugangsdaten, keine Benutzerinteraktion und oft nur eine einzige Verbindung zu Port 23, um den Fehler anzustoßen.
Wenn telnetd mit Root-Rechten läuft, kann das im schlimmsten Fall zur kompletten Systemübernahme führen.
Weil diese Lücke drei unangenehme Eigenschaften kombiniert:
Die Bewertung der Schwachstelle zeigt: Netzwerkbasiert, geringe Komplexität, keine Rechte nötig, keine Benutzeraktion nötig.
Das ist aus Sicht von Angreifern ungefähr so charmant wie ein offen stehendes Fenster im Erdgeschoss.
Telnetd läuft nicht unbedingt auf den Servern, über die täglich gesprochen wird.
Genau das macht solche Dienste gefährlich: Sie sind oft Altlasten, schlecht dokumentiert oder „nur noch für dieses eine System“ aktiv.
Wer Root-Rechte auf einem System bekommt, hat im Zweifel freie Bahn für Nachladen weiterer Schadsoftware, Seitwärtsbewegung im Netzwerk, Datenabfluss oder Sabotage.
Hacker News nennt genau diese möglichen Folgeschäden: Backdoors, Datenexfiltration und laterale Bewegung.
Nach den veröffentlichten Informationen betrifft die Lücke GNU InetUtils telnetd bis einschließlich Version 2.7.
In der Debian-Sicherheitsübersicht ist bereits sichtbar, dass inetutils 2.7-4 in sid/forky als fixed geführt wird, während mehrere ältere Debian-Zweige noch als verwundbar markiert waren.
Das ist ein wichtiger Punkt für die Praxis:
Es reicht nicht, nur allgemein zu sagen „wir nutzen kein Telnet mehr“.
Entscheidend ist, ob irgendwo in deiner Umgebung doch noch ein betroffener Dienst aktiv ist — direkt, indirekt oder eingebettet in ältere Systeme und Appliances.
Hier nicht lange philosophieren. Prüfen, priorisieren, handeln.
Finde heraus, ob Port 23 oder telnetd irgendwo noch aktiv ist.
Gerade in älteren Serverlandschaften, Laboren, Produktionsumgebungen oder bei Spezialgeräten gibt es gerne Überraschungen.
Wenn ein verwundbarer telnetd-Dienst aus dem Netzwerk erreichbar ist, gehört das Thema ganz nach oben auf die To-do-Liste.
Besonders kritisch sind Systeme, die von außen erreichbar sind oder in sensiblen Netzsegmenten stehen.
Wo möglich, sollte auf eine gefixte Version aktualisiert werden.
Ist das kurzfristig nicht machbar, gilt: Dienst deaktivieren, Port 23 blockieren, Zugriff einschränken und Telnet nach Möglichkeit komplett durch sicherere Verfahren ersetzen.
Wenn Telnet aus historischen Gründen doch noch gebraucht wird, dann wenigstens so eng wie möglich absichern: per Firewall begrenzen, segmentieren, überwachen und Privilegien minimieren.
Ein Dienst, der mit Root läuft und direkt ausnutzbar ist, ist kein guter Kandidat für „läuft halt so mit“.
Die eigentliche Frage lautet nicht nur: „Haben wir Telnet irgendwo noch an?“
Sondern auch: „Was passiert, wenn ein Angreifer tatsächlich draufkommt?“
Und damit sind wir bei einem Thema, das oft erst dann ernst genommen wird, wenn es knallt.
Mehr, als man auf den ersten Blick denkt.
Solche aktuellen Fälle zeigen, wie schnell aus einer technischen Schwachstelle eine echte Unternehmenskrise werden kann.
Ein belastbarer IT-Notfallplan schafft dann klare Verantwortlichkeiten, technische Sofortmaßnahmen, Recovery-Prozesse und sichere Kommunikation. Genau diese Brücke zwischen Schwachstelle und Handlungsfähigkeit ist entscheidend.
Denn bei einer Lücke wie dieser reden wir nicht über ein kosmetisches Update. Wir reden über ein Szenario, in dem Angreifer potenziell mit Root-Rechten auf Systeme kommen können. Dann brauchst du nicht nur gute Technik, sondern auch Antworten auf ganz praktische Fragen:
Wer entscheidet?
Wer informiert wen?
Welche Systeme werden isoliert?
Wie läuft die Wiederherstellung?
Wie kommunizierst du intern, mit Kunden oder mit Partnern?
Wenn diese Fragen erst im Krisenfall gestellt werden, ist das ungefähr so effizient wie Feuerlöscher-Shopping während des Brandes.
CVE-2026-32746 ist ein gutes Beispiel dafür, warum alte Dienste in moderner IT schnell zum Risiko werden.
Die Schwachstelle ist kritisch, vor der Anmeldung ausnutzbar und potenziell mit vollständiger Systemübernahme verbunden.
Für IT-Entscheider heißt das: nicht abwarten, sondern jetzt prüfen, ob Telnetd irgendwo noch lebt — und falls ja, sofort gegensteuern.
Gleichzeitig zeigt der Fall noch etwas anderes: Technische Schwachstellen sind nie nur Technikthemen. Sie werden zum Business-Risiko, wenn im Ernstfall niemand genau weiß, was zu tun ist.
Du willst nicht erst im Krisenfall herausfinden, wie gut dein Unternehmen vorbereitet ist?
Dann ist jetzt der richtige Zeitpunkt für einen IT-Notfallplan, der nicht nur auf dem Papier gut aussieht, sondern im Ernstfall auch funktioniert.
Wir helfen dir dabei, klare Abläufe, Verantwortlichkeiten und Maßnahmen zu definieren — damit aus einer Schwachstelle nicht automatisch eine Unternehmenskrise wird.
Melde dich bei uns, wenn du deinen IT-Notfallplan erstellen, prüfen oder modernisieren willst.