Critical GNU InetUtils telnetd Flaw Lets Attackers Bypass Login and Gain Root Access

A critical security flaw has been disclosed in the GNU InetUtils telnet daemon (telnetd) that went unnoticed for nearly 11 years. The vulnerability, tracked as CVE-2026-24061, is rated 9.8 out of 10.0 on the CVSS scoring system. It affects all versions of GNU InetUtils from version 1.9.3 up to and including version 2.7.

The vulnerability allows for a complete authentication bypass. According to the NIST National Vulnerability Database (NVD), "Telnetd in GNU Inetutils through 2.7 allows remote authentication bypass via a '-f root' value for the USER environment variable."

How the Exploit Works

The attack leverages a specific interaction between the telnetd server and the system's login program. In a post on the oss-security mailing list, GNU contributor Simon Josefsson explained the technical details:

"The telnetd server invokes /usr/bin/login (normally running as root) passing the value of the USER environment variable received from the client as the last parameter. If the client supply [sic] a carefully crafted USER environment value being the string '-f root', and passes the telnet(1) -a or --login parameter to send this USER environment to the server, the client will be automatically logged in as root bypassing normal authentication processes."

The root cause is twofold: the telnetd server does not sanitize the USER environment variable before passing it to the login program, and the login program uses the -f parameter to bypass normal authentication. This combination creates a dangerous authentication bypass.

Historical Context and Discovery

What makes this vulnerability particularly concerning is its age. According to Josefsson, the vulnerability was introduced as part of a source code commit made on March 19, 2015, which eventually made it to the version 1.9.3 release on May 12, 2015. This means the flaw has been present in production systems for approximately 10 years and 8 months.

Security researcher Kyu Neushwaistein (aka Carlos Cortes Alvarez) discovered and reported the flaw on January 19, 2026, bringing this long-standing issue to light.

Current Threat Landscape

Data from threat intelligence firm GreyNoise indicates that attackers are already actively probing for this vulnerability. Over the past 24 hours, 21 unique IP addresses have been observed attempting to execute a remote authentication bypass attack by leveraging the flaw.

The IP addresses originate from multiple countries including Hong Kong, the U.S., Japan, the Netherlands, China, Germany, Singapore, and Thailand. All of these addresses have been flagged as malicious by GreyNoise's analysis systems.

Mitigation Strategies

Immediate Actions

1. Apply Patches: The most effective mitigation is to apply the latest patches from GNU InetUtils. Users should update to a patched version as soon as it becomes available.

2. Network Access Controls: Restrict network access to the telnet port (typically port 23) to trusted clients only. Consider implementing firewall rules that block telnet access from untrusted networks.

Temporary Workarounds

If immediate patching isn't possible, consider these temporary measures:

1. Disable telnetd: The simplest workaround is to disable the telnet daemon entirely. Most modern systems should use SSH for remote access instead of telnet, which transmits data in plaintext.

2. Use a Custom Login Tool: As suggested by Simon Josefsson, configure the InetUtils telnetd to use a custom login(1) tool that does not permit the use of the -f parameter. This requires modifying the system's login program or creating a wrapper that sanitizes environment variables.

3. Network Segmentation: Isolate systems running telnetd from the broader network, especially if they must remain active for legacy applications.

Broader Implications

This vulnerability highlights several important security lessons:

1. Legacy Protocol Risks

Telnet is an outdated protocol that transmits all data, including passwords, in plaintext. Despite this well-known security weakness, it remains in use in some legacy systems and embedded devices. This vulnerability adds another critical reason to migrate away from telnet to encrypted alternatives like SSH.

2. Environment Variable Sanitization

The vulnerability demonstrates the importance of proper input sanitization, even for environment variables. When passing data between programs, especially when privilege escalation is involved, all inputs must be carefully validated.

3. Long-Lived Vulnerabilities

The 11-year lifespan of this vulnerability underscores how security flaws can persist undetected in widely used software. Regular security audits, fuzzing, and code reviews are essential for catching such issues before they can be exploited.

4. Defense in Depth

Even if you don't use telnetd, this vulnerability serves as a reminder to implement defense in depth. Network segmentation, proper firewall rules, and limiting services to only what's necessary can reduce the attack surface.

Affected Platforms

The vulnerability affects any system running GNU InetUtils telnetd versions 1.9.3 through 2.7. This includes:

• Many Linux distributions that package GNU InetUtils
• Embedded systems and IoT devices that use telnetd
• Legacy Unix systems
• Some network equipment that uses GNU InetUtils components

Recommended Actions for System Administrators

1. Inventory Systems: Identify all systems in your environment running telnetd. Check package versions to determine if they're vulnerable.

2. Test Patches: When patches become available, test them in a staging environment before deploying to production.

3. Update Documentation: Update system documentation to reflect the removal or replacement of telnet services.

4. Monitor Logs: Implement enhanced monitoring for telnet connections, especially from unexpected sources or with unusual environment variables.

5. Consider Migration: Use this vulnerability as an opportunity to migrate any remaining telnet-dependent systems to SSH or other encrypted alternatives.

Conclusion

The discovery of CVE-2026-24061 serves as a stark reminder that even well-established, widely-used software can harbor critical vulnerabilities for extended periods. The combination of a high CVSS score (9.8), the potential for root access, and the active exploitation attempts make this a priority for any organization still using GNU InetUtils telnetd.

The path forward is clear: patch immediately, implement network controls, and begin planning for the complete removal of telnet services from your infrastructure. In an era where encrypted communication is the standard, continuing to use plaintext protocols like telnet introduces unnecessary risk.

For organizations with legacy systems that cannot immediately migrate away from telnet, the temporary workarounds provide a critical stopgap while more permanent solutions are developed. However, these should be viewed as temporary measures only—the long-term solution must be the complete deprecation of telnet in favor of secure alternatives.