Hidden Daemons: A Telnet mystery

We live in a wild time – or at least I think we do. Cyber security is one of the most important domains in the technology industry and this reality has only become more evident in the last decade as cyber attacks become more impactful, more costly and simply more frequent. This increase is caused in part by the increased complexity of IT systems, leading to a higher attack surface, and more opportunities for defences to leave gaps.

But one thing is also true, the flip side of the coin; hacking has become much more difficult.

In 2010, SQL injection was common, much more so than it is now. Frameworks hadn’t matured to implement-as-default counter coding practices to thwart such attacks. Defensive technologies were not as sophisticated or pervasive, and exploitation of binaries was, simply, more easily done. While mitigations were present, they were nowhere near as impactful or widespread as they are now. The security industry as a whole was much less mature and aware - something that seemingly has been fixed in the current day, at least to some degree.

It is therefore absolutely crazy that, even in the current ecosystem of cyber security, vulnerabilities such as CVE-2026-24061 (reported 19th January 2026) which is trivially easy to exploit, are still being discovered. In spite of the advancement in testing techniques, and the overall higher technical demand for offensive security personnel, a simple one liner, that can completely takeover a vulnerable system, has remained undetected for nearly 11 years.

One might argue that any RCE critical risk issue is a ‘pop for pleasure’ type situation, but the pre-work that goes into such things is often deep and involved. In this case, it really isn’t.

I am of course talking about the TelnetD vulnerability that is affecting thousands of systems, with over 200,000 available telnet servers currently facing the internet. 

This of course is not a comprehensive or exhaustive list, and it’s likely that not every one of these services is vulnerable. Needless to say, though, it’s a significant number. It also does not consider those devices that are on internal networks.

With the release of this CVE, and the simplicity of the exploit (which is demonstrated below), it’s unsurprising that the issue is being exploited in the wild and it is likely the vulnerability has long been exploited by real world threat actors. It has quickly fallen into CISA’s KEV as shown below.

Exploitation

So, let’s get onto the cool stuff. We’ll walk through the process of setting up a vulnerable server and then demonstrate how trivial this vulnerability is to exploit (you may also want to have a go yourself). It’s safe to infer that the likelihood of compromise is very high and organisations should be scrambling to get telnet services removed from their networks – or urgently patched.

Step 1: Get a Telnet server

This can be done by installing with apt (or your package manager of choice) inetutils-telnet. Upon installation, start the server, then configure the inetd.conf file located at: /etc/inetd.conf to add the following line:

Finally, start the service with the command below and you should have telnet up and running:

-          systemctl start inetd

That’s it. Setup done. Thanks, Linux, for making life easy for us (specifically ubuntu/Debian – although most have package managers that are just as simple: dnf, pacman, etc.).

Now, onto the attacker’s perspective.  A quick port scan of the affected system shows telnet running.

The next step is just a single command. The CVE states that environment variables passed to the telnet command can be used to bypass authentication and gain a root shell. So, with that in mind we consider the following:

-          USER=’-f root’ telnet -a <IP ADDRESS>

Let’s see this in action below:

And that’s it. Root.

I wish I could give more technical insight or a bit more meat around this. But as mentioned, the vulnerability is very simple to exploit. If your organisation has Telnet available on the internet or internal network, and it has not been patched/updated as of January 2026, then compromise of that system is going to be trivial.

What to do now?

I would recommend identifying any of your external facing infrastructure (as a matter of priority) for telnet and then take measures to block any access. Then, I would patch all systems using telnet or just disable it where it’s not needed.

Obviously, telnet shouldn’t be used anyway - it’s a clear-text protocol. In almost all cases, for remote shell to administrate any device/system, SSH is likely to be available. But it’s important to acknowledge that attack surfaces take many forms, and can include even well known, mature services and systems. Regular patching and minimum exposure policies can help to minimise your risk.