32-Year-Old Bug in GNU Telnetd Enables Pre-Auth RCE (CVE-2026-32746)
▼ Summary
– CVE-2026-32746 is a BSS-based buffer overflow vulnerability in the Telnet protocol’s LINEMODE feature, discovered in GNU inetutils but affecting many vendor implementations.
– The vulnerability, which dates back to 1994, allows an attacker to corrupt roughly 400 bytes of adjacent memory by sending crafted SLC (Set Linemode Characters) negotiation triplets.
– Exploitation is complex and highly system-dependent due to strict byte constraints in the triplets and varying memory layouts across different Telnetd builds and architectures.
– On some systems, like a 32-bit Debian build, the overflow can lead to powerful primitives such as an arbitrary free() or pointer leaks, though a direct path to reliable remote code execution was not found.
– Detection is possible by checking if a server processes SLC data that overflows the buffer, but patching is critical as many distributions have not yet shipped fixes despite the vulnerability’s wide reach.
A critical vulnerability discovered in the GNU Telnet daemon, designated CVE-2026-32746, allows for remote code execution before authentication. This security flaw is a buffer overflow that has remained undetected within the codebase for an astonishing 32 years, originating in 1994. The issue affects the LINEMODE feature’s SLC negotiation handler, enabling an attacker to corrupt adjacent memory. While the vulnerability is technically within GNU inetutils, its impact is widespread because numerous vendors have incorporated this code into their own Telnet implementations over decades. This includes all major Linux distributions, creating a significant and difficult-to-quantify attack surface across countless legacy and modern systems.
Telnet, the largely obsolete network protocol for remote command-line access, remains in use across various production environments despite its well-known security shortcomings. These range from specialized industrial equipment and embedded systems to older network infrastructure where migration to more secure alternatives like SSH is not feasible. The protocol’s continued presence underscores why this vulnerability demands attention. The flaw itself resides in how the server processes SLC triplets,three-byte structures defining special characters,during connection negotiation. The server stores these values in a fixed-size global array without performing any bounds checking, allowing data to spill over into neighboring variables.
Exploiting this vulnerability to achieve reliable remote code execution is a complex challenge, not a straightforward task. The data an attacker can send is heavily constrained by the protocol’s structure. Each SLC triplet consists of a function byte, a flag byte, and a value byte, each with specific limitations enforced by the server’s processing logic. For instance, the function byte cannot exceed a certain value, and a function byte of zero causes the entire triplet to be discarded. Furthermore, the protocol mandates that any byte with a value of 0xFF is doubled during storage. This prevents an attacker from writing single 0xFF bytes, a significant obstacle on 64-bit systems where pointer values often contain such sequences.
The overflow is also limited by the maximum size of a Telnet subnegotiation packet, which is 512 bytes. The vulnerable buffer itself is only 108 bytes. After accounting for header data, an attacker can typically corrupt roughly 400 bytes of memory that follow the buffer. What lies in that adjacent memory region is entirely dependent on how the specific Telnetd binary was compiled. The compiler’s arrangement of global variables differs with each build and architecture, making a one-size-fits-all exploit impossible. On modern 64-bit x86 systems, exploitation is particularly difficult due to pointer alignment and the constraints on writing null bytes.
Research into a 32-bit Debian environment revealed a more promising, though still nuanced, path. By manipulating the order of protocol negotiations, an attacker can trigger a scenario where a deferred buffer pointer is overwritten. This can lead to an arbitrary `free()` call on a controlled memory address, a powerful primitive. However, converting this into full code execution depends heavily on the system’s memory allocator and the availability of suitable function pointers within the application’s heap. The Telnetd codebase itself performs few dynamic allocations, limiting immediate opportunities. Systems with additional complexity, such as those using Kerberos authentication, may present more exploitable code paths.
Given the immense variability across implementations, creating a universal detection method is as challenging as crafting an exploit. However, a detection strategy can leverage the patch’s behavior. A patched server will silently discard SLC data that overflows the buffer, while a vulnerable server will store it. A detection tool can send a crafted payload designed to slightly overflow the buffer with a unique marker value. If the server’s response includes that marker, it indicates the overflow occurred and the system is vulnerable. A preliminary “probe mode” can also check if a server even advertises the vulnerable LINEMODE feature before attempting any overflow, making assessment safer for fragile legacy systems.
The sheer longevity and pervasive integration of this bug mean it will likely persist in networks for years. Unlike vulnerabilities in a single, homogeneous product, this flaw exists in a fragmented ecosystem of countless derived codebases. Successful exploitation requires deep tailoring to a target’s specific binary and environment, which generally protects against broad, automated attacks. This complexity, however, is little consolation for administrators of critical infrastructure where Telnet is still required. For them, the presence of a pre-authentication memory corruption bug is a severe threat, especially from determined, resourceful adversaries.
Patching is the unequivocal recommendation, but it is complicated by the upstream response. The GNU inetutils project had not issued an official fixed release at the time of discovery; the vulnerability persists in version 2.7. A fix must be obtained by building from a patched commit in the source repository. Consequently, most Linux distributions have been slow to provide updated packages. Only the unstable Debian ‘sid’ branch included a fix initially, leaving all stable releases exposed. This situation highlights the critical need for organizations to proactively identify and update any system running a vulnerable Telnet daemon, regardless of its official support status.
(Source: Watchtowr.com)