CVE-2026-24061 Analysis: Critical Telnet Vulnerability

At the beginning of 2026, a critical vulnerability was identified in the telnetd service, which is part of GNU InetUtils. This vulnerability is a Remote Code Execution (RCE) issue with root privileges, registered as CVE-2026-24061 and assigned a CVSS score of 9.8.

Although Telnet is a highly outdated protocol, it is unfortunately still widely used for management purposes in various systems, including IoT devices and other embedded devices.

Remote Code Execution vulnerabilities often arise when user input is directly used in system commands, and this Telnet vulnerability is no exception. CVE-2026-24061 exists in GNU inetutils telnetd because user input is passed to /bin/login as an argument without proper filtering. This allows argument injection, which can lead to authentication bypass and root login.

Vulnerable code

The vulnerability can be traced back to a code change introduced in 2015. At that time, the developers added a new placeholder to the login_invocation constant in telnetd.c.

During a standard Telnet handshake, the server invokes the /usr/bin/login binary to handle authentication. The logic added in 2015 was intended to allow the server to pre-fill the username based on the USER environment variable supplied by the client. The 2015 commit can be viewed at the following link:

https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c288b87139a0da8249d0a408c4dfb87

The commit that introduced the telnetd code leading to CVE-2026-24061.

The commit that introduced the telnetd code leading to CVE-2026-24061.

When a client initiates a session, the start_login function calls the expand_line function to construct the command string used to execute the login process. The login command does not use a fixed value, but instead relies on a placeholder that is populated based on user input (specifically the %U placeholder). The %U placeholder is replaced with the value of the USER environment variable, which is defined through client-supplied input.

As a result, the value of the USER environment variable is passed to the binary specified by PATH_LOGIN. By default, this is the /usr/bin/login binary, which is responsible for handling authentication. The screenshot below shows the reference to this binary.

The critical issue in CVE-2026-24061 is the absence of input validation on the contents of the %U placeholder in the telnetd code. Because the Telnet protocol allows a remote client to send arbitrary environment variables, this results in a critical authentication bypass vulnerability that ultimately leads to Remote Code Execution.

CVE-2026-24061 in IoT devices

A notable category of devices that still frequently rely on Telnet services are IoT devices. Over the past several years, I have conducted numerous security assessments on IoT devices for the Virtual Hacking Labs IoT Penetration Testing course. On a significant portion of the tested devices, Telnet services were present and, in some cases, configurable via a management interface for administrative purposes.

It is important to note that CVE-2026-24061 only affects the telnetd service that is part of GNU InetUtils. Many IoT devices use alternative Telnet implementations, such as the BusyBox telnetd implementation, which does not use dynamic login arguments and is therefore not vulnerable to CVE-2026-24061.

The BusyBox 1.37.0 telnetd codebase is available at the following link:

https://elixir.bootlin.com/busybox/1.37.0/source/networking/telnetd.c

CVE-2026-24061 Telnet Exploit

Exploiting the CVE-2026-24061 Telnet vulnerability is extremely straightforward and can be performed using a simple command. In the following exploit command, the USER environment variable, which normally contains the username, is set to -f root.

This causes the parameter to be passed directly to the /usr/bin/login binary. When reviewing the man pages for the login binary, the following explanation is provided for the -f option:

The -f option causes authentication to be skipped, as the program assumes authentication has already been performed. As a result, the user is authenticated as root without ever providing a password, effectively resulting in an authentication bypass.

https://man7.org/linux/man-pages/man1/login.1.html

The screenshot below shows that after executing the command, no further authentication takes place, yet a root shell is obtained on the Linux system running the vulnerable Telnet service.

CVE-2026-24061 Recommendations

The CVE-2026-24061 vulnerability is extremely easy to exploit, but it is also relatively simple to mitigate. The following recommendations are provided for completeness:

  1. Update GNU InetUtils to version 2.7-2 or later.
  2. Analyze where and in what context Telnet is used across devices and networks, and disable the service on systems connected to the network. If disabling Telnet is not immediately possible, ensure isolation through strict firewall rules.
  3. Migrate to secure management protocols wherever possible.

The following commit patches the CVE-2026-24061 vulnerability:

https://codeberg.org/inetutils/inetutils/commit/fd702c02497b2f398e739e3119bed0b23dd7aa7b

Why is Telnet still dangerous?

Telnet transmits all data, including usernames and passwords, in plaintext and lacks modern security controls, making it easy to intercept and abuse. Therefore it is recommended to replace telnet with other services that are more secure, such as SSH.

How to detect Telnet on your network?

Exposed Telnet services can be identified using internal network scan tools like Nmap, or by using internet-wide scanning platforms such as Shodan and Censys to locate systems that are reachable from the public internet on port 23. Regular audits help ensure that legacy services are not unintentionally exposed. Also keep in mind that you can monitor IP addresses for open ports with tools like Shodan to discover newly opened ports.

Is BusyBox telnetd vulnerable to CVE-2026-24061?

No, CVE-2026-24061 applies to GNU InetUtils telnetd ≥ 1.9.4 and < 2.7-2. BusyBox telnetd is not vulnerable to CVE-2026-24061 because it does not construct the login command using user-controlled placeholders. Instead, it invokes the login process using fixed arguments, which prevents argument injection and authentication bypass in this context.

CVE-2026-24061 Telnet Lab

If you want to test and analyze the CVE-2026-24061 Telnet exploit yourself and you have a Virtual Hacking Labs (VHL) membership for the PT01 course, be sure to check out the new lab machine that will be added to the Virtual Hacking Labs PT01 lab environment today.

If you do not have a VHL membership, you can install the telnetd service on a recent Ubuntu system using the following commands:

sudo apt update

sudo apt install inetutils-telnetd

 

Edit the inetd configuration:

sudo nano /etc/inetd.conf

 

Add or uncomment the following line:

telnet  stream  tcp  nowait  root  /usr/sbin/tcpd  /usr/sbin/in.telnetd

 

Restart inetd:

sudo systemctl restart inetd

An Nmap port scan will now show that the Telnet service is available on port 23.

Be sure not to expose this port to untrusted networks due to the critical RCE and authentication bypass vulnerability.

Conclusion

The fact that CVE-2026-24061 remained unnoticed for such an extended period is striking, yet not uncommon for high-impact vulnerabilities that persist silently in widely deployed software. History has shown similar cases, such as Dirty COW (CVE-2016-5195) in the Linux kernel, BlueKeep (CVE-2019-0708) in Windows RDP, and Log4Shell (CVE-2021-44228) in Log4j, where long-standing flaws only came to light years after their introduction.

CVE-2026-24061 once again highlights the inherent risks of legacy protocols and services that were never designed with modern security principles in mind. Telnet, in particular, lacks fundamental security controls such as encryption and robust input handling, making it an increasingly dangerous choice in today’s threat landscape.

Organizations that still rely on Telnet for management or administrative access should treat this vulnerability as a clear signal to reassess their exposure. Where possible, Telnet should be fully retired in favor of secure alternatives such as SSH, which provide encrypted communication channels and stronger authentication mechanisms by default. For environments where Telnet cannot be immediately removed, strict isolation and compensating controls are essential to reduce risk.

Ultimately, CVE-2026-24061 serves as a reminder that outdated technology can quietly introduce severe security risks and that proactive auditing, timely patching, and modernization of management protocols remain critical components of a robust security posture.