SafeBreach Labs Releases Root Cause Analysis & Proof-of-Concept Exploit for CVE-2026-24061: Telnetd RCE as Root Vulnerability

In January 2026, the GNU telnetd service from GNU InetUtils was found to be vulnerable to authentication-bypass by Kyu Neushwaistein (aka Carlos Cortes Alvarez). Tracked as CVE-2026-24061, this flaw allows an attacker to establish a Telnet session without providing valid credentials, granting unauthorized access to the target system. The vulnerability exists all the way up to version 2.7-2 of the GNU telnetd service and looks like it was taken right out of the 90s. It is highly dangerous and easy to exploit—the fact that it has remained undiscovered and exploitable for more than a decade is quite shocking.

Although Telnet is widely regarded as a legacy protocol used for remote connection and command execution, it remains enabled in some Unix/Linux environments, embedded systems, network appliances, and OT-adjacent infrastructure. According to Shodan—a search engine for internet-connected devices, firewalls, and servers—there are 212,396 devices across the globe currently running a Telnet server, although all of them may not be using the vulnerable GNU telnetd.

According to Censys, a website similar to Shodan, there are 1 million devices listening on port 23, a default port for Telnet that indicates these devices likely have the Telnet service open. Again, the service being used may not specifically be the vulnerable GNU telnetd, but it does give some indication of potential impact.

Based on this data, the implications of this vulnerability could be significant and far-reaching. And, with a critical CVSS score of 9.8, this vulnerability represents a direct initial-access risk, particularly for systems exposing their Telnet service to untrusted networks. The SafeBreach Labs team set out to explore the root cause of this vulnerability and, as part of its research process, developed a proof-of-concept (PoC) exploit for it. 

In the blog below, we first provide an overview of SafeBreach Lab’s analysis of the root cause of CVE-2026-24061 and how it can be exploited. Next, we share how our research process uncovered another level of control as a result of this vulnerability, enabling us to set arbitrary environment variables for Telnet service processes and child processes. Finally, we explain how we are sharing this information with the broader security community to help organizations protect themselves, including sharing a GitHub repository with the PoC exploit we developed.

The Research Process for CVE-2026-2406

Root Cause Analysis

The root cause of this vulnerability was introduced in this commit from 2015. Let’s take a look at the problematic lines of code that were added:

• We see a construction of a string that looks like a command-line that executes /usr/bin/login with arguments. It appears:
  • The commit added a “%U” to the constant
  • The variable PATH_LOGIN is equal to “/usr/bin/login”

• In this change, we don’t see any modification but only new code. What we see here is an insertion of a new switch case, which appears to correspond to the character “U”.

In order to understand why this change is problematic, we will examine how Telnet operates. When a user uses Telnet remotely, it must start by authenticating. To accomplish this authentication, telnetd utilizes an already existing executable in Linux that implements this logic – /usr/bin/login, which is responsible for authenticating the user and creating a session that gives them an interactive shell.

The insertion of %U is located in the file telnetd.c from lines 49 to 63 and adds a new option (%U) to the “formatting template” of a constant named “login_invocation”.

If you search for the usage of “login_invocation”, you will notice that it appears in the start_login function. The function start_login is where the main login flow happens, and it is located inside the file pty.c. The image below shows how the “login_invocation” variable is used:

The first line expand_line accepts “login_invocation” as a parameter. And, after a lot of hoops, it arrives at the function _var_short_name.

The switch case addition is located inside this very same function: _var_short_name.

A short examination of the line reveals the purpose of the “%U” in the “command-line” string. The purpose is to replace the %U placeholder with the value of an environment variable named USER. This specific environment variable can be controlled by the user through the Telnet protocol.

The Telnet protocol enables the user to send a sequence of Telnet commands, which results in the setting of the USER environment variable, this environment variable is used to pre-fill the username used in the authentication (autologin). The marked SUBOPTION packets are the final exchange of the user-supplied environment data:

But why does setting the environment variable result in authentication-bypass? Let’s take a look at the same code block from start_login again:

So, this means we can supply new flags or arguments for the /usr/bin/login executable.Looking at the flags available for use in the login binary, there seems to be a very powerful option that we can leverage:

The -f flag skips the interactive authentication and just drops us into a root shell, providing us with an extremely powerful RCE on any server that runs GNU telnetd up to version 2.7-2.

Next Steps: A Powerful Environment Variable Control

Analyzing this vulnerability led us to successfully create its exploit. However, that’s not the only thing that this analysis was beneficial for. While we performed our research, as we mentioned previously in this blog post, we understood that a victim remote telnetd server provides us with the ability to set arbitrary environment variables in its process. At least this is what we assumed.

By default, in Linux, environment variables are inherited by child processes. Therefore, this means that as clients of the Telnet service, we can set any environment variables that we want for any child processes that the telnetd service runs.

To verify that this is really the case, we tested with other environment variables other than the “USER” environment variable. We tested with the “PATH” variable, which may be one that affects processes most. We ran our tests and were extremely surprised to find we could change the PATH variable of any child process (including /usr/bin/login) that telnetd runs to whatever we want:

Conclusion

CVE-2026-24061 is a critical vulnerability, is easy to exploit, and may expose a significant number of devices across the globe. To help mitigate the potential impact, SafeBreach has: 

• Shared our analysis of the root cause of the vulnerability to help other cybersecurity professionals better understand the associated risks and support additional research within the larger cybersecurity community. To protect themselves against the vulnerabilities presented by CVE-2026-24061, we recommend that organizations:
  • Update to the patched version of GNU telnetd which is 2.7-2.
  • Minimize the usage of Telnet and replace it with more modernized protocols like SSH.
• Provided a GitHub research repository with a public PoC exploit of the vulnerability, which simulates the Telnet negotiation mechanism and is implemented in Python.
• Released an attack simulation within the SafeBreach platform to help our customers quickly validate their security posture in regards to this threat.
  • From the SafeBreach homepage, customers can select “Go to Attack” in the CVE-2026-24061 New Coverage pop-up.

For more in-depth information about this research, please: 

• Contact your customer success representative if you are a current SafeBreach customer
• Schedule a one-on-one discussion with a SafeBreach expert
• Contact Kesselring PR for media inquiries