11-Year-Old Telnet Bug Hands Attackers Root Access

A vulnerability hiding in GNU InetUtils since 2015 allows remote attackers to bypass authentication and gain root access to affected systems with a single command. Exploitation has already begun.

CVE-2026-24061 affects the telnetd daemon in GNU InetUtils versions 1.9.3 through 2.7. The flaw carries a CVSS score of 9.8 and requires no authentication to exploit—just network access to port 23.

How the Attack Works

The vulnerability exists because telnetd passes user-controlled environment variables directly to the login binary without sanitization. An attacker sets the USER environment variable to -f root and connects using telnet's -a flag. The -f option tells login to skip authentication entirely.

That's it. One crafted connection and the attacker has a root shell.

The source code change that introduced this vulnerability was committed in March 2015. It remained undetected for more than eleven years, affecting GNU InetUtils releases from version 1.9.3 onwards.

Affected Distributions:

• Debian and derivatives (Ubuntu, Kali Linux)
• Trisquel
• Any system running telnetd from vulnerable GNU InetUtils versions

Exploitation in the Wild

GreyNoise observed real-world exploitation within 24 hours of disclosure. Between January 21 and 22, the threat intelligence firm logged 60 Telnet sessions from 18 unique IPs, all deemed malicious.

The attacks appear largely automated, though GreyNoise noted some "human-at-keyboard" activity. In 83% of observed attempts, attackers targeted the root account directly.

The Belgium CCB has issued a warning urging immediate patching. The Canadian Centre for Cyber Security released advisory AL26-002 with similar guidance.

Immediate Mitigations

Primary fix: Update GNU InetUtils to version 2.8 or later.

If immediate patching isn't possible:

1. Disable telnetd and migrate to SSH. The telnet protocol transmits everything in plaintext anyway—there's no good reason to run it in 2026.

2. Block TCP port 23 at the firewall. No exceptions.

3. Apply the backport if you maintain custom packages. Commits fd702c02 and ccba9f74 address the vulnerability.

4. Verify login configuration to ensure the login binary handles -- delimiters correctly.

For organizations running legacy systems that depend on telnet, network segmentation becomes mandatory. Isolate these systems from internet-facing networks and implement additional access controls.

Why Telnet in 2026?

You might wonder who still runs telnet services on production systems. The answer: industrial control systems, legacy mainframes, network equipment management interfaces, and embedded devices where SSH wasn't available or wasn't implemented.

Some of these systems can't be easily upgraded. Others exist in environments where "if it works, don't touch it" prevails. The CVE-2026-24061 disclosure forces a reassessment of that position.

The CISA KEV catalog now tracks multiple critical vulnerabilities requiring federal agency remediation, and legacy protocol vulnerabilities like this one represent exactly the type of easy-win exploitation that attackers favor.

Organizations that still require telnet access should consider jump hosts, VPN requirements, or application-layer proxies that can enforce additional authentication before traffic reaches vulnerable endpoints.

The Bigger Picture

This vulnerability sat undetected for over a decade. It's a reminder that legacy code review matters, even for well-known open source projects. The attack surface of "obsolete" protocols doesn't disappear just because we've moved on to better alternatives.

GNU InetUtils maintainers patched the issue promptly after discovery. The faster organizations can apply the fix—or eliminate telnet entirely—the smaller the window attackers have to exploit it.

Security teams should audit their environments for unexpected telnet services. Network scans for open port 23 take minutes. Discovering you're running vulnerable telnetd after exploitation is considerably more expensive.