Ein Daemon aus der Vergangenheit mit einem Fehler der Gegenwart

Telnet gilt seit Jahrzehnten als veraltetes Protokoll – unverschlüsselt, längst durch SSH abgelöst, und dennoch hartnäckig in vielen Umgebungen aktiv. Genau dieser Umstand macht eine neue Schwachstelle besonders brisant: Mit CVE-2026-32746 wurde im GNU InetUtils Telnet-Daemon (telnetd) eine kritische Sicherheitslücke entdeckt, die unauthentifizierte Angreifer aus dem Netz heraus zur vollständigen Systemkontrolle befähigt. Der CVSS-Score beträgt 9,8 von 10. Das Besondere: Ein offizieller Patch existiert bislang nicht.

Das israelische Sicherheitsunternehmen Dream entdeckte die Schwachstelle am 11. März 2026 und machte sie am 18. März öffentlich bekannt. Seitdem läuft die Uhr: Angreifer weltweit haben Kenntnis von der Lücke – Exploit-Code ist zwar noch nicht öffentlich verfügbar, aber bei einem CVSS-Score von 9,8 und einem simplen Angriffsmechanismus ist die Frage nicht ob, sondern wann ein Proof-of-Concept erscheint.

Was steckt hinter der Schwachstelle? Technische Analyse

Die Lücke liegt im LINEMODE-Handler des Telnet-Daemons – konkret im Verarbeitungsmodul für Set Local Characters (SLC) Suboptions. Das SLC-Protokoll ist Teil der Telnet-Option LINEMODE (RFC 1116) und ermöglicht die Aushandlung von Zeichenzuordnungen zwischen Client und Server beim Verbindungsaufbau.

In GNU InetUtils durch Version 2.7 verarbeitet der SLC-Handler eingehende Triplets in einer Schleife ohne ausreichende Längenprüfung. Übersteigt die Anzahl der gesendeten Triplets einen bestimmten Grenzwert, schreibt der Handler Daten über die Puffergrenzen hinaus – klassischer Stack-basierter Pufferüberlauf (Out-of-bounds Write) mit den bekannten Konsequenzen: Kontrolle über den Instruction Pointer und damit Remote Code Execution mit den Rechten des telnetd-Prozesses.

Das Entscheidende: Diese Verarbeitung findet vor jeder Authentifizierung statt. Ein Angreifer muss lediglich eine TCP-Verbindung auf Port 23 aufbauen und ein speziell präpariertes SLC-Paket senden. Keine gültigen Zugangsdaten, keine Voraussetzungen, keine komplexe Exploit-Chain – ein einziger Netzwerkpaket reicht aus.

# Schematische Darstellung des Angriffsvektors
# Angreifer sendet an Port 23:

IAC SB LINEMODE SLC [überlange Triplet-Sequenz] IAC SE

# Resultat: Pufferüberlauf im telnetd-Prozess
# → Arbitrary Code Execution als Daemon-Benutzer (oft root)

In vielen Standardkonfigurationen läuft telnetd mit Root-Rechten oder erhöhten Privilegien, was eine vollständige Systemkompromittierung ermöglicht. Selbst in eingeschränkten Kontexten bietet ein initialer Foothold erheblichen Spielraum für Lateral Movement und Privilege Escalation im internen Netzwerk.

Angriffsfläche: Größer als erwartet

Man könnte annehmen, Telnet-Dienste seien 2026 kaum noch anzutreffen. Die Realität zeigt ein anderes Bild. Das Attack Surface Management-Unternehmen Censys identifizierte am 18. März 2026 rund 3.362 öffentlich erreichbare Hosts weltweit, die verwundbare Instanzen betreiben. Diese Zahl erfasst ausschließlich öffentlich zugängliche Systeme – die tatsächliche Angriffsfläche in internen Netzwerken ist wesentlich größer.

Besonders gefährdet sind folgende Systemkategorien:

  • Eingebettete Systeme und IoT-Geräte mit Linux-basierten Firmware-Stacks, die keine Over-the-Air-Updates unterstützen
  • Legacy-Infrastruktur in industriellen Steuerumgebungen (ICS/OT) – Fertigungsanlagen, SCADA-Systeme, Prozessleitsysteme
  • Netzwerkgeräte (Router, Switches, Firewalls älterer Generationen) mit aktiviertem Telnet-Management
  • Ältere Serverinstallationen, die noch nicht auf SSH migriert wurden oder bei denen telnetd als "nur intern" betrachtet wird
  • Container- und VM-Images, die telnetd als Debugging-Werkzeug oder für Legacy-Kompatibilität beinhalten

Für den deutschen Mittelstand ist besonders der OT-Bereich relevant. Fertigungsunternehmen, Maschinenbauer und Anlagenbetreiber arbeiten häufig mit Equipment, das über Jahrzehnte gewachsen ist. Telnet-Zugänge für Wartung und Konfiguration sind in solchen Umgebungen keine Seltenheit – und oft liegt das entsprechende System im selben Netzwerksegment wie kritische Produktionssysteme. Eine Kompromittierung über CVE-2026-32746 könnte hier weitreichende Folgen haben, die weit über den direkten Schaden am angegriffenen System hinausgehen.

Kein Patch – aber wirksame Sofortmaßnahmen

Stand 20. März 2026 ist kein offizieller Patch für GNU InetUtils verfügbar. Die Entwickler haben einen Fix für den 1. April 2026 angekündigt. Bis dahin sind Unternehmen auf Interim-Maßnahmen angewiesen. Die gute Nachricht: Diese Maßnahmen sind klar definiert und in der Praxis effektiv umsetzbar.

Maßnahme 1: Telnet deaktivieren

Die einfachste und wirksamste Maßnahme ist das Abschalten des telnetd-Dienstes – überall dort, wo er nicht zwingend benötigt wird. In den meisten Umgebungen kann Telnet problemlos durch SSH ersetzt werden:

# systemd-basierte Systeme
systemctl stop telnetd
systemctl disable telnetd

# Überprüfung
systemctl status telnetd  # Sollte "inactive (dead)" zeigen

# xinetd-basierte Systeme: /etc/xinetd.d/telnet bearbeiten
# disable = yes setzen, dann xinetd neu starten

Maßnahme 2: Port 23 auf Netzwerkebene sperren

Wenn telnetd aus Kompatibilitätsgründen weiterhin betrieben werden muss, sollte Port 23 durch Firewall-Regeln auf bekannte Quell-IP-Adressen eingeschränkt werden:

# iptables (IPv4) – nur internes Management-Netz erlauben
iptables -A INPUT -p tcp --dport 23 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 23 -j DROP

# nftables
nft add rule inet filter input tcp dport 23 ip saddr != 10.0.0.0/8 drop

# Persistenz sicherstellen (iptables-persistent / nftables service)

Maßnahme 3: Ohne Root-Rechte betreiben

Falls eine vollständige Abschaltung nicht sofort möglich ist, sollte der Daemon unter einem unprivilegierten Benutzerkonto betrieben werden. Dies begrenzt den Explosionsradius eines erfolgreichen Angriffs erheblich und gibt IT-Teams Zeit für eine geordnete Migration.

Maßnahme 4: Netzwerksegmentierung und Isolation

Systeme, die zwingend auf Telnet angewiesen sind (z.B. bestimmte Legacy-OT-Systeme ohne Update-Möglichkeit), sollten in isolierten Netzwerksegmenten ohne direkten Internet- und idealerweise ohne direkten Intranet-Zugang betrieben werden. Administrativer Zugriff kann über Jump-Server oder VPN-Verbindungen in das Isolationssegment erfolgen.

Bin ich betroffen? Schwachstellenerkennung im eigenen Netz

Die Überprüfung auf verwundbare telnetd-Instanzen lässt sich mit gängigen Mitteln durchführen:

# Auf einzelnen Hosts: Läuft telnetd?
systemctl status telnetd
ps aux | grep telnetd

# GNU InetUtils Version prüfen (verwundbar: alle Versionen durch 2.7)
telnetd --version
inetutils-telnetd --version

# Interner Netzwerk-Scan nach offenen Telnet-Ports
nmap -sV -p 23 --open 10.0.0.0/8
nmap -sV -p 23 --open 192.168.0.0/16

# Schnell-Scan mit masscan (große Netzwerke)
masscan -p23 10.0.0.0/8 --rate=1000

Kommerzielle Schwachstellenscanner wie Tenable Nessus, Qualys VMDR und Rapid7 InsightVM haben bereits Erkennungsregeln für CVE-2026-32746 bereitgestellt. Definition-Updates sollten sofort eingespielt und ein Scan des gesamten Netzwerks gestartet werden.

Warum Telnet 2026 noch immer ein Problem ist

Die Existenz aktiver Telnet-Dienste in modernen Unternehmensnetzen ist kein Zufall und kein Versagen einzelner Administratoren. Sie ist das Ergebnis systemischer Faktoren, die IT-Sicherheitsteams täglich begegnen:

  • Legacy-Hardware ohne Update-Mechanismus: Viele Industrieanlagen, medizinische Geräte und spezialisierte Netzwerkkomponenten haben feste Firmware-Versionen. Eine Telnet-Abhängigkeit kann de facto nicht ohne Hardware-Austausch beseitigt werden.
  • Fehlende Asset-Inventarisierung: In gewachsenen IT-Umgebungen fehlt häufig ein aktuelles und vollständiges Inventar aller laufenden Dienste. Telnet-Instanzen auf vergessenen VMs oder embedded Devices entgehen der Aufmerksamkeit.
  • Fehlgeleitetes Vertrauen in interne Netze: "Das System ist ja nur intern erreichbar" ist eine weit verbreitete, aber gefährliche Annahme. Im Falle eines initialen Kompromisses über einen anderen Angriffsvektor werden intern exponierte Dienste zu Pivoting-Zielen.
  • Kompatibilitätsanforderungen: Ältere Software und Protokolle erfordern bisweilen Telnet-Unterstützung, und eine Migration ist aufwändig.

Der dritte Punkt verdient besondere Aufmerksamkeit. Eine vollständige Asset-Inventarisierung ist nicht nur eine technische Best Practice – sie ist unter NIS2 für betroffene Unternehmen eine regulatorische Anforderung. Wer nicht weiß, welche Dienste wo laufen, kann weder gezielt patchen noch den Aufsichtsbehörden gegenüber darlegen, dass die eigene Infrastruktur sicher ist. Mehr zur strategischen Informationssicherheit und wie Sie Ihre IT-Umgebung systematisch absichern können, erfahren Sie auf unserer Themenseite.

Regulatorische Einordnung: NIS2, CISA und die Pflicht zum Handeln

Die US-Behörde CISA hat CVE-2026-32746 zum Zeitpunkt der Veröffentlichung noch nicht in den Known Exploited Vulnerabilities (KEV) Katalog aufgenommen, da bislang keine aktive Ausnutzung in freier Wildbahn bestätigt wurde. Dies kann sich jedoch innerhalb von Stunden ändern. Bei CVEs mit einem CVSS-Score von 9,8 und simplem Angriffsmechanismus ist die Veröffentlichung eines öffentlichen Exploits meist nur eine Frage von Tagen.

Für Unternehmen unter NIS2 oder DORA gilt: Sicherheitslücken mit kritischem CVSS-Score in exponierten Diensten müssen innerhalb der geltenden Fristen dokumentiert, bewertet und adressiert werden. Die BSI-Prüfteams, die seit Dezember 2025 auf Basis des novellierten BSIG aktiv sind, erwarten nachvollziehbare Prozesse für Vulnerability Management und Patch-Deployment. Wer jetzt keine Maßnahmen ergreift und später mit einem CVE-2026-32746-Incident konfrontiert wird, hat schlechte Karten in der Nachbereitung. Mehr zu den aktuellen Compliance-Anforderungen und deren praktischer Umsetzung auf unserer Website.

Fazit: Alte Dienste, neue Gefahr – jetzt handeln

CVE-2026-32746 ist kein theoretisches Szenario. Es ist eine kritische, derzeit ungepatchte Schwachstelle mit maximalem Angriffspotenzial, die in Tausenden von Systemen lauert – möglicherweise auch in Ihrem Netzwerk. Die Kombination aus CVSS 9.8, Pre-Authentication-Angriff, fehlenden Patch und öffentlicher Bekanntheit schafft ein erhebliches Risikofenster bis Anfang April.

Die Handlungsempfehlungen sind klar:

  • Asset-Inventar sofort auf laufende telnetd-Instanzen prüfen (intern und extern)
  • Telnet deaktivieren, wo nicht zwingend erforderlich
  • Port 23 an Firewalls und Perimeter-Geräten sperren
  • Betroffene Systeme aus öffentlich erreichbaren Netzen nehmen
  • Schwachstellenscanner mit aktuellen Definitionen ausführen
  • Patch vom 1. April 2026 sofort nach Erscheinen einspielen und testen
  • OT/IoT-Systeme ohne Update-Möglichkeit in Netzwerkisolation nehmen

Benötigen Sie Unterstützung bei der Schwachstellenanalyse, einem internen Netzwerkscan oder der Härtung Ihrer IT-Infrastruktur? Die Spezialisten von pleXtec sind für Sie da. Kontaktieren Sie uns jetzt – wir helfen Ihnen, Risiken zu identifizieren und gezielt zu beseitigen.