Two Critical Telnet Flaws in 2026 Allow Unauthenticated Root Access

If your organization is still running Telnet anywhere in its infrastructure, 2026 has been a rough year. Two separate critical vulnerabilities in telnetd have surfaced, both allowing unauthenticated attackers to gain full root access. As a penetration tester, I’ve come across Telnet on client networks more than I expected over the past year. It tends to show up on IoT devices, legacy appliances, and internal network segments that haven’t been reviewed in a long time. These two CVEs make that a much more urgent finding to bring to the table.

CVE-2026-24061: Argument Injection in GNU InetUtils Telnetd Grants Root Access Without a Password

CVE-2026-24061 was discovered in January 2026, but it had been sitting in the codebase for over ten years. The vulnerability was accidentally introduced in a March 2015 patch meant to fix an auto-login issue. A developer modified the way telnetd passed login information to /usr/bin/login, adding a placeholder that injected the client-supplied USER environment variable directly into command arguments without any sanitization.

Because telnetd trusts the USER variable without validation, an attacker can set it to -f root before connecting. The -f flag instructs the login utility to treat the session as pre-authenticated. The system skips the password prompt entirely and returns a root shell with no credentials required.

The exploit works with a standard Telnet client and no additional tooling. This vulnerability is actively being exploited against exposed Telnet servers in the wild.

CVE-2026-32746: Buffer Overflow in Telnetd SLC Handler Enables Pre-Authentication RCE

Weeks later, researchers at Dream Security disclosed CVE-2026-32746, carrying a CVSS score of 9.8. Where the first vulnerability was an injection flaw, this one is a classic buffer overflow.

The bug is in the telnetd LINEMODE Set Local Characters (SLC) handler, triggered during Telnet protocol negotiation before authentication occurs. A fixed 108-byte buffer is used to build SLC responses, but the function appending data to it never checks whether the buffer is full. After roughly 35 SLC triplets, the buffer overflows and corrupts adjacent memory. That corrupted pointer is then used to write an attacker-controlled value elsewhere in memory, enabling arbitrary code execution.

Because telnetd runs with root privileges, successful exploitation results in full system compromise from a single connection to TCP port 23. Affected systems include embedded and IoT devices with exposed Telnet interfaces, servers using the vulnerable codebase, and Linux distributions shipping inetutils with telnetd enabled, including Debian, Ubuntu, RHEL, and SUSE. A patch from GNU Inetutils was released last week and will make its way to various downstream projects in the near future.

How to Mitigate Telnetd Vulnerabilities: Patching, Port Blocking, and SSH Migration

• Migrate to SSH. Encrypted, well-supported, and available on virtually every platform. There is no modern use case that justifies Telnet over SSH.
• Disable telnetd now. If migration requires time, take the service offline in the interim.
• Block TCP port 23 at the perimeter. Telnet should not be reachable from untrusted networks under any circumstances.
• Restrict to trusted hosts only. If Telnet must remain temporarily, use firewall rules to limit access to specific hosts.
• Audit for port 23 across your environment. Legacy equipment, IoT devices, and network appliances are common findings that often fall outside standard patch cycles.
• Monitor for patches on both CVEs. Watch the GNU Inetutils project and your distribution’s security advisories.

Two CVEs, One Protocol, Zero Authentication Required

Both vulnerabilities require no special tooling, no credentials, and no user interaction. Just a connection to port 23. CVE-2026-24061 went undetected for over a decade, and CVE-2026-32746 followed within weeks with a CVSS of 9.8. This is also the third Telnet-related vulnerability disclosure of 2026, following a separate authentication bypass in January.

Telnet transmits everything in plaintext, runs with root privileges by default, and its implementations receive far less security scrutiny than modern protocols. That combination makes it a consistent target. SSH has been the established replacement for over two decades. If Telnet is still in your environment, migration belongs at the top of the priority list.