CVE-2026-24061: Der Telnetd-Fehler, der „sichere“ Netze in Root-Zugriff verwandelt

Wenn „alles gepatcht“ ist und es trotzdem zu Root kommt

Viele Sicherheitsprogramme sehen auf dem Papier stark aus.

• Perimeter gehärtet.
• Passwörter rotiert.
• Tools aktualisiert.
• Scanner grün.
• Policies vorhanden.

Und doch kann ein vergessener Dienst oder ein Fehler in einer vertrauenswürdigen Komponente alles in Sekunden zunichtemachen.

Genau deshalb ist CVE-2026-24061 so relevant.

Die Schwachstelle erinnert daran: „Sicher“ heißt nicht „nicht kompromittierbar“. Es heißt nur „schwerer zu kompromittieren“. Angreifer wählen den leichtesten Weg.

Was ist CVE-2026-24061, kurz erklärt

CVE-2026-24061 ist eine kritische Authentifizierungsumgehung in GNU InetUtils telnetd. Betroffen sind Versionen 1.9.3 bis 2.7, die Bewertung liegt bei CVSS 9,8.

Vereinfacht gesagt: Der Telnet-Daemon übergibt einen vom Angreifer beeinflussbaren USER-Wert an den Login-Prozess, ohne ihn sauber zu sanitizen. Das ermöglicht Argument-Injection und kann zu Root-Zugriff ohne gültige Authentifizierung führen.

Die Schwachstelle wurde über ein Sicherheitsadvisory von Simon Josefsson veröffentlicht; entdeckt und verantwortungsvoll gemeldet wurde sie von Kyu Neushwaistein (Carlos Cortes Alvarez).

Kurz nach der Veröffentlichung wurden bereits Aktivitäten in der Praxis beobachtet, und es gibt Berichte über eine große Telnet-Exposure weltweit.

Warum es sich wie eine „Backdoor“ anfühlt (obwohl es keine ist)

Niemand hat hier absichtlich eine Hintertür eingebaut. Es ist ein Bug.

Aus Angreifer-Sicht sieht das Ergebnis aber ähnlich aus: ein Root-Pfad, der Kontrollen umgeht, auf die man sich verlässt.

Die unbequeme Erkenntnis: Selbst legitime, weit verbreitete und aktuell gepflegte Software kann einen Fehler enthalten, der eine Tür öffnet, von der Sie nichts wussten.

Und wir wissen nicht, wie viele ähnliche Schwächen täglich von kriminellen Gruppen oder staatlich unterstützten Akteuren ausgenutzt werden, ohne jemals öffentlich zu werden.

Das „sichere Client“-Szenario, das trotzdem scheitert

Stellen Sie sich einen Kunden vor mit:

• Sauber segmentiertem Netzwerk.
• Starkem Perimeter und gehärteten Internet-Diensten.
• Regelmäßigem Patchen und modernem Endpoint-Schutz.
• Sicherem Passwort-Lifecycle und MFA.
• Aktuellen Tools auf Servern und Netzwerkgeräten.

Und dann kommt eine Realität, die häufig ist:

Irgendwo existiert noch ein Legacy-Managementdienst – ein altes Appliance, Embedded Linux, ein Lab Segment, OT-Netz oder eine „temporäre“ Admin-Abkürzung, die nie entfernt wurde. Telnet ist der Klassiker, weil es in Vergessenheit gerät.

Wenn ein Angreifer irgendeinen Foothold bekommt – gestohlene Credentials, kompromittierter VPN, Phishing oder ein Lieferanten-Vorfall – ist der Perimeter nicht mehr das Hauptproblem.

Im Inneren wird ein vergessenes Telnet plus CVE-2026-24061 dann zum kürzesten Weg für Privilegieneskalation und laterale Bewegung.

Warum Assumed-Breach-Tests so wichtig sind

Traditionelle Penetrationstests fragen oft: „Kommen wir rein?“

Assumed Breach dreht die Frage um: „Was passiert, wenn jemand bereits drin ist?“

Dieser Unterschied zählt, weil Angriffe selten dauerhaft am Perimeter scheitern. Angreifer testen viele Wege – Identitäten, Lieferketten, Endpoints – bis einer funktioniert.

Ein Assumed-Breach-Test prüft Dinge, die Ihnen kein Patch-Dashboard zeigt:

• Kann ein Angreifer zwischen VLANs und Segmenten pivotieren?
• Erreicht er Management-Planes und Admin-Services?
• Kann er Domain- oder Root-Rechte erlangen?
• Kann er Daten exfiltrieren, ohne entdeckt zu werden?
• Sieht das SOC die Angreifer-Pfade rechtzeitig?

CVE-2026-24061 ist ein ideales Beispiel, weil es zeigt, wie ein einziger Dienst internen Zugriff in vollständige Kontrolle verwandeln kann.

Was Unternehmen jetzt tun sollten

Konkrete Maßnahmen gegen Telnet-Klassenprobleme und ähnliche „unerwartete Root-Türen“:

• Telnet eliminieren, wo möglich: Durch SSH oder moderne Management-Kanäle ersetzen. Wenn Telnet bleiben muss, strikt isolieren.
• Finden, was vergessen wurde: Asset-Inventar inklusive Dienste und Ports. Regelmäßig prüfen, ob Port 23 und andere Legacy-Ports nicht durch Rebuilds, Vendor-Images oder Notfalländerungen wieder auftauchen.
• Schnell patchen – aber mit „kein Patch“-Realität planen: Wenn Updates nicht sofort möglich sind, braucht es Kompensationsmaßnahmen: Dienst deaktivieren, IP-restrict, Firewalling, Segmentgrenzen.
• Managementzugriff wie Produktionsdaten behandeln: Jump Hosts, MFA, minimale Routen und Zugriffswege.
• Detektion für Legacy-Protokolle: Alerts auf Telnet-Verbindungen, ungewöhnliche Root-Logins und anomale Auth-Flows.

Wie Haxoris helfen kann

Wenn Sie diese Lektion in messbare Verbesserungen übersetzen wollen, unterstützt Haxoris mit:

• Assumed-Breach-Penetrationstests.
• Internen Netzwerk- und Active-Directory-Tests.
• Externem Attack-Surface- und Perimetertesting.
• Purple-Team-Übungen.
• Security-Hardening-Reviews.

Schlussgedanke

CVE-2026-24061 ist nicht nur eine Telnet-Geschichte.

Es ist eine Geschichte über Sichtbarkeit, Testing und Demut.

Die unbequeme Wahrheit in der Infrastruktur-Sicherheit: Man kann vieles richtig machen und dennoch an einem übersehenen Detail scheitern.

Assumed Breach findet dieses Detail, bevor es der Angreifer tut.