Ancient telnet bug happily hands out root to attackers

A recently disclosed critical vulnerability in the GNU InetUtils telnet daemon (telnetd) has been quietly present for nearly 11 years, allowing attackers to trivially gain root access to affected systems. The bug, tracked as CVE-2026-24061 with a CVSS score of 9.8, was introduced in a May 2015 update and was disclosed on January 20, 2026. GreyNoise data indicates that attacks are already underway, with 15 unique IP addresses attempting to exploit the vulnerability in the past 24 hours.

The Vulnerability: A Simple Argument Injection

The flaw is an argument injection vulnerability in how telnetd handles the USER environment variable. According to the GNU security advisory authored by contributor Simon Josefsson, the telnetd server invokes /usr/bin/login (normally running as root) and passes the value of the USER environment variable received from the client as the last parameter.

The exploit is straightforward. An attacker crafts a USER environment value as the string -f root and connects using the telnet client with the -a or --login parameter to send this environment variable to the server. This causes the login program to interpret -f root as a command-line argument, automatically logging the attacker in as the root user and completely bypassing all normal authentication processes.

Stephen Fewer, senior principal researcher at Rapid7, explained the severity: "Exploiting this vulnerability is straightforward: as documented in the disclosure, simply running a specific telnet command to connect to a remote server can trigger the issue and grant an attacker root access. Rapid7 Labs has verified the vulnerability, confirming that exploitation is trivial and results in full root access on the target."

Why This Matters: The Persistence of Legacy Protocols

While telnet has been largely abandoned in favor of secure alternatives like SSH, its continued presence in modern infrastructure is concerning. The protocol transmits all data, including passwords, in plaintext, making it vulnerable to packet sniffing and man-in-the-middle attacks. Despite this, many organizations still maintain telnet services for legacy equipment, industrial control systems, or internal tools.

The French national cybersecurity authority (CERT-FR) issued an advisory stating, "many telnet services are accessible on the internet, which is contrary to good practices. CERT-FR therefore recommends decommissioning all telnet services." Similar warnings were echoed by cybersecurity authorities in Canada and Belgium, all urging the immediate retirement of telnetd services.

Technical Analysis: How the Exploit Works

To understand the exploit mechanism, consider the normal flow of a telnet login:

1. Client connects to telnetd on port 23
2. telnetd spawns login as a child process
3. login prompts for username/password
4. Credentials are verified
5. User session is established

The vulnerability occurs because telnetd passes the USER environment variable directly to login without proper sanitization. When the client sends USER=-f root, the login program receives this as a command-line argument, where -f tells login to skip authentication and -f root specifies the username to authenticate as.

This is a classic argument injection flaw, which differs from memory corruption vulnerabilities in several ways:

• Reliability: Unlike buffer overflows or use-after-free bugs, argument injection doesn't depend on specific memory layouts or compiler versions
• Simplicity: The exploit requires no complex payload construction or ROP chains
• Portability: Works across different architectures and operating systems
• Detection: May not trigger traditional intrusion detection systems that look for shellcode or exploit patterns

Impact Assessment

The vulnerability affects all versions of GNU InetUtils telnetd from 1.9.4 (released May 2015) through 2.5.0. The CVSS 9.8 rating reflects:

• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H)
• Integrity Impact: High (I:H)
• Availability Impact: High (A:H)

The combination of no authentication required, trivial exploitability, and full system compromise makes this one of the most dangerous vulnerabilities in legacy services.

Mitigation Strategies

Immediate Actions

1. Patch Management: Update to the latest version of GNU InetUtils. The fix involves proper sanitization of the USER environment variable before passing it to login.
2. Network Isolation: Restrict telnet port (23/TCP) access to trusted clients only using firewall rules or network ACLs.
3. Service Disabling: Stop and disable the telnetd service entirely if not absolutely required.

Long-term Solutions

1. Protocol Migration: Replace telnet with SSH for all remote access needs. SSH provides encryption, authentication, and integrity protection.
2. Legacy System Isolation: For systems that cannot be upgraded, place them in isolated network segments with strict access controls.
3. Monitoring and Detection: Implement network monitoring to detect telnet exploitation attempts. Tools like Snort or Suricata can be configured with rules to detect suspicious telnet traffic.

Homelab Considerations

For homelab builders and enthusiasts running telnetd for legacy equipment or specific use cases:

• Test Environments: If you must run telnetd for testing, ensure it's only accessible from isolated test networks
• Containerization: Consider running telnetd in a container with minimal privileges and no network access to production systems
• Logging: Enable verbose logging on telnetd to monitor for exploitation attempts
• Regular Audits: Periodically scan your network for exposed telnet services using tools like Nmap or Masscan

Broader Implications

This vulnerability underscores several critical points about security in modern infrastructure:

1. Legacy Code Persistence: Software that has been "end-of-life" for years continues to exist in production environments
2. Supply Chain Complexity: GNU InetUtils is a fundamental component of many Linux distributions, meaning the vulnerability could affect countless systems
3. Security Through Obscurity Fails: The bug remained hidden for 11 years, not because it was secure, but because few were looking at telnetd code
4. The Cost of Backward Compatibility: Maintaining compatibility with legacy protocols often introduces security risks

Conclusion

The CVE-2026-24061 vulnerability in GNU InetUtils telnetd represents a perfect storm of factors: a trivial exploit, a decade-long undetected presence, and active exploitation in the wild. For anyone still running telnetd in 2026, this should be the final wake-up call to decommission the service entirely.

The vulnerability serves as a stark reminder that in security, what isn't monitored can't be protected, and legacy services that have been "quietly working" for years may be hiding critical flaws. As homelab builders and system administrators, our responsibility is to continuously audit our infrastructure, question the necessity of every running service, and prioritize security over convenience.

For those interested in the technical details, the full advisory is available on the GNU mailing list, and the patch can be reviewed in the GNU InetUtils git repository.