GNU InetUtils Telnetd Flaw Lets Attackers Log In as Root

A researcher found a vulnerability in GNU InetUtils telnetd that could let remote attackers gain root access without a password, putting any exposed Telnet service at risk of full system compromise. 

The flaw requires no user interaction and can be exploited over the network with a crafted login request.

If the vulnerability is exploited, it allows the client to be “… automatically logged in as root bypassing normal authentication processes,” said the researcher.

Inside the Telnetd Authentication Bypass

The authentication bypass affects GNU InetUtils versions 1.9.3 through 2.7, exposing any system running the InetUtils telnetd service to potential remote compromise. 

While Telnet is considered a legacy protocol, it still appears in older Linux and Unix environments, embedded devices, and segmented networks — making this flaw especially dangerous when telnetd is reachable from untrusted hosts.

The root cause lies in how GNU InetUtils telnetd invokes the system’s /usr/bin/login program when handling incoming connections. 

During a Telnet session, telnetd can receive a USER environment variable from the remote client and then pass it directly to login without sanitizing the input. 

That unsafe handoff creates an opportunity for parameter injection, allowing an attacker to supply a crafted USER value containing -f root. 

On many Unix-like systems, login interprets the -f option as a trusted login flag that can bypass normal authentication checks under certain conditions. 

Because telnetd forwards the user-supplied value as-is, an attacker may be able to bypass authentication entirely and gain immediate root access, without being prompted for a password.

This issue is considered critical because it is remote and unauthenticated, requires minimal effort to exploit, and results in full system compromise with root privileges. 

The flaw was introduced in a code change made in March 2015 and first shipped in GNU InetUtils 1.9.3, persisting across all subsequent releases through version 2.7.

How to Reduce Telnet Exposure 

Because this flaw enables unauthenticated root access, exposed Telnet services should be treated as an urgent security risk. 

The best defense is to remove Telnet entirely, but many organizations still rely on it for legacy systems and operational workflows. 

• Disable telnetd wherever possible and migrate remote administration to SSH or other secure alternatives.
• Patch or upgrade GNU InetUtils to a fixed version to eliminate the authentication bypass risk.
• Restrict Telnet exposure with strict allowlisting, segmentation, and firewall rules that block untrusted access.
• Require VPN or jump-host access for any remaining Telnet use to keep it off general user and internet-facing networks.
• Enforce host-based controls such as local firewalls and mandatory access policies to limit what Telnet sessions can reach.
• Monitor and alert on suspicious Telnet activity, including unexpected root logins, abnormal session volume, or new persistence artifacts.
• Regularly test incident response plans for legacy access services to validate containment, credential rotation, and recovery steps.

Taken together, these measures reduce Telnet exposure and help protect against this vulnerability from becoming a full root compromise. 

This vulnerability is a reminder that legacy services like Telnet can turn minor coding flaws into major security incidents — especially when they remain externally or broadly reachable.  

Even if Telnet is only used for limited operational needs, unauthenticated root access is a risk that requires action, starting with disabling telnetd or patching affected systems and reinforcing access controls and monitoring. 

That’s one reason why organizations are adopting zero-trust solutions that minimize implicit trust and tightly control access to every system, legacy or not.