Telnet's Undead Threat: CVE-2026-32746 — A Critical Pre-Auth Buffer Overflow in GNU Inetutils

Overview

In what is becoming the "year of the legacy protocol," a second critical vulnerability has been unearthed in the GNU Inetutils suite. Just months after the disclosure of a trivial authentication bypass (CVE-2026-24061), security researchers have identified a remote, pre-authentication buffer overflow in the telnetd daemon.

Tracked as CVE-2026-32746, this flaw allows an unauthenticated attacker to achieve Remote Code Execution (RCE) with root privileges on systems running affected versions of GNU Inetutils.

The Technical Breakdown: LINEMODE SLC

The vulnerability resides in how telnetd handles the LINEMODE SLC (Set Local Characters) suboption. LINEMODE is an extension to the Telnet protocol (RFC 1184) that allows the client to perform local line editing before sending data to the server. The SLC suboption is used to negotiate special characters (like Ctrl+C or Ctrl+Z).

According to the original report on the bug-inetutils mailing list, the function add_slc fails to perform any bounds checking on the pointer used to store these characters.

The Vulnerable Code Snippet

In the affected codebase, the add_slc function adds a triplet of values (function, flag, and value) to a buffer without verifying if there is enough space left.

void
add_slc (char func, char flag, cc_t val)
{
  /* The buffer overflow occurs here: no bounds check on slcptr */
  if ((*slcptr++ = (unsigned char) func) == 0xff)
    *slcptr++ = 0xff;
  if ((*slcptr++ = (unsigned char) flag) == 0xff)
    *slcptr++ = 0xff;
  if ((*slcptr++ = (unsigned char) val) == 0xff)
    *slcptr++ = 0xff;
}

By crafting a malicious Telnet session that sends an excessive number of SLC commands during the initial protocol negotiation, an attacker can overflow the internal buffer and overwrite adjacent memory. Because this happens during the negotiation phase—before a user is ever prompted for credentials—this is a pre-authentication exploit.

Risk Assessment

While Telnet is widely considered a "dead" protocol in modern enterprise environments, it remains a staple in Operational Technology (OT), Industrial Control Systems (ICS), and legacy embedded devices. Shodan scans still reveal hundreds of thousands of devices listening on port 23 globally. A critical overflow in a fundamental tool like GNU Inetutils means that any device utilizing this suite for remote management is now a high-priority target.

Echoes of the Past

Interestingly, this vulnerability mirrors security issues found in BSD-based telnet daemons over two decades ago (such as CVE-2001-0554). Its reappearance in 2026 highlights a common "vulnerability drift" where legacy codebases that lack active security auditing continue to harbor decades-old bugs that were patched in other branches of the Unix family tree long ago.

Mitigation and Recommendations

The most effective defense against this vulnerability is to stop using Telnet. However, if your infrastructure requires it, follow these steps:

1. Disable Telnetd: If the service is not strictly necessary, disable the telnetd daemon immediately.
2. Network Segmentation: Restrict access to TCP port 23 via firewalls or ACLs. Ensure that Telnet is only accessible from trusted administrative subnets and never exposed directly to the internet.
3. Patching: Monitor the GNU Inetutils repository and your Linux distribution's security advisories for a patched version (expected to be versions 2.8 and higher).
4. Migration: Accelerate the transition to SSH (Secure Shell) for all remote management tasks. SSH provides encrypted communication and has undergone significantly more rigorous security scrutiny over the last twenty years.

For organizations tracking their threat landscape, this serves as a reminder that "legacy" does not mean "stable"—it often means "forgotten."