CVE-2026-24061,-32746 CRITICAL telnetd security bugs

General Privacy & Security
1

CVE: https://www.cve.org/CVERecord?id=CVE-2026-24061

You really ought not be exposing telnetd on the internet but you never know. For sure, it is used internally in some corporate networks.

1 Like
2

Telnet is old. No one use it.. we have ssh.

3

True.

This is false.

There are reports of active exploitation in the wild of this vulnerability. So this CVE must therefore be relevant. Someone is using it.

There are two related questions though:

  • Does anyone use it?
  • Does anyone use it exposed to the internet?

I absolutely guarantee you that the answer to the first question is ā€œyesā€.

There is another possible scenario though i.e. that telnet is installed and exposed but not in use (classic poor security practice) and so the only party using telnet is the intruder. (This kind of thing can happen when telnet gets installed for some temporary purpose but then noone remembers to deinstall it afterwards.)

So it doesnā€™t hurt to check all your computers to make sure that telnetd is not running or better still that it is not even installed.

Technically you can use telnet over SSL (or a range of other secure protocols to layer on or even secure extensions for telnet itself). So telnet is not necessarily insecure.

For sure, for ad hoc connection to a remote shell, SSH is vastly preferred over telnet in actual deployment.

SSH also offers additional functionality that telnet does not (e.g. port forwarding in either direction, X11 forwarding, SFTP). But then all that additional functionality is itself a potential security risk.

For what itā€™s worth, SSH has its own potential vulnerabilities with environment variables if you tinker with the configuration in unwise ways i.e. the default out-of-the-box sshd configuration should be fine.

1 Like
4

You are right. But using telnet over ssh ā€¦ you know its like using udp over tcp.

1 Like
5

There have been times when Iā€™ve basically been forced to do that e.g. some older embedded device that supports telnet but not SSH, but you still want to make the connection secure against interception of traffic. So let the device use telnet but then port forward telnet over SSH.

Edit: PS It would be my understanding that even if you run telnet over SSH, you will still be vulnerable to this CVE if you are vulnerable to it at all.

1 Like
6

irvinewade,

i am kind of a noob with a high iq, i use computers and internet and have some deeper impressions but no deep experience on computers or actual networks. What i know is that humans do some stuff - especially not update software or deactivate old services if they should.

ā€œudp over tcpā€ was hint for virtualization or vpn using. Some one use telnet for sure. But those who do, have fix it. And those who do not known should deactivate or firewall it - for more than a decade. I tried to made a joke, because i am a Noob.

A.I. will collect the unsafe not well configured systems and catch them all - for sure. Sometimes with Zero day exploits. So have backups and take care and have iron Firewall rulesā€¦ vpn is not helping, its a blind spot!

7

Another, completely unrelated, critical telnetd security bug: https://www.cve.org/CVERecord?id=CVE-2026-32746

As no patch is currently available yet, seemingly, mitigations would be needed if telnet is exposed to the internet.

8

Just for a LOL ā€¦ if you boot Jumpdrive on your Librem 5 then it most definitely runs telnetd. That is even higher risk of being a vulnerable version of telnetd because it has captured a potentially quite old version of telnetd in a monolithic ā€˜boot imageā€™ and the version of telnetd will never get automatically updated.

However it is obviously a lower risk of actual exploitation and lower effective consequences in most scenarios e.g. unless you did something really weird like route and port forward the internet all the way from your internet gateway through your PC to the Librem 5 - and, even then, thereā€™s no username and password on the login (straight into root) so apparently neither of these vulnerabilities makes a difference in this niche scenario.

9

I observe it in most internal networks.

Shodan lists 1,264,911 results for port 23 exposed to the internet.

1 Like
10

How many of those are honeypots? :wink:

11

Nobody knows but maybe that equalizes itself when taking telnet on custom ports into account, too :stuck_out_tongue:

1 Like
12

Indeed, nobody knows. I would think that only a small proportion would be honeypots. The vast majority would be people (unknowingly?) engaging in risky behaviour.

From time to time, at home, I get a port scan done from outside, which may pick up where a port has accidentally been left open (whether telnet or anything else).