CVE-2026-32746: Pre-Authentication Remote Code Execution via BSS Overflow in GNU Inetutils telnetd

The GNU Inetutils package provides a suite of common network administration utilities, including the telnetd server daemon. Security researchers identified a critical vulnerability within the legacy codebase originating from the 1994 BSD Telnet implementation. The flaw affects all versions of GNU Inetutils up to and including version 2.7. The widespread integration of this code means the vulnerability impacts numerous operating systems, including major Linux distributions, FreeBSD, NetBSD, macOS, and various embedded network appliances.

The vulnerability is classified as a Stack/BSS-based Buffer Overflow (CWE-120, CWE-787). The defect resides specifically in the LINEMODE Set Local Characters (SLC) suboption handler. The daemon fails to validate the size of incoming network data before copying it into a fixed-size buffer located in the uninitialized data segment (BSS). This oversight permits out-of-bounds write operations.

The telnetd service exposes a pre-authentication network interface to process incoming connections. An unauthenticated remote attacker interacts with this vulnerable code path during the initial protocol handshake. The attack requires no prior authorization or valid credentials on the target system. The network vector allows exploitation across internal networks and the public internet.

Successful exploitation results in arbitrary remote code execution. Because the telnetd daemon typically executes with elevated system privileges, the attacker gains complete control over the host OS as the root user. The vulnerability carries a CVSS v3.1 base score of 9.8, reflecting its critical severity and ease of remote exploitation.

The core vulnerability exists in the telnetd/slc.c file during the processing of LINEMODE SLC negotiation. The server maintains a statically allocated buffer named slcbuf to store SLC triplets during the protocol handshake. This buffer has a fixed capacity of 108 bytes. The server tracks the current memory offset for incoming data using a global pointer named slcptr.

The add_slc function processes incoming triplets consisting of a function code, a flag, and a value. This function sequentially writes these three bytes to the memory location indicated by slcptr and increments the pointer accordingly. The implementation completely lacks bounds checking. The function does not verify whether slcptr has exceeded the 108-byte boundary of the slcbuf array.

An unauthenticated attacker triggers this vulnerable code path by sending a LINEMODE SLC subnegotiation request with an excessive number of triplets. Because each triplet consumes three bytes, sending more than 36 triplets causes the add_slc function to write past the end of the buffer. The vulnerability constitutes a highly reliable out-of-bounds write primitive.

Both slcbuf and slcptr reside adjacent to each other in the uninitialized data segment (BSS). The sequential overflow sequentially corrupts adjacent variables stored in this memory region. The exact layout of the BSS segment dictates which application state variables an attacker can overwrite, making the exploitation mechanics specific to the target architecture and compiler optimization levels.

Reviewing the vulnerable C implementation reveals the exact mechanism of the out-of-bounds write primitive. The add_slc function accepts three parameters but lacks any bounds-checking logic. The pointer arithmetic blindly advances slcptr through memory, corrupting adjacent BSS variables.

// Vulnerable Implementation: telnetd/slc.c
static unsigned char slcbuf[108]; // Fixed size
static unsigned char *slcptr;
 
void add_slc(unsigned char func, unsigned char flag, cc_t val) {
    // Vulnerability: 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;
}

The necessary remediation introduces a strict bounds check before executing the memory write operations. The modified function calculates the current offset by determining the distance between slcptr and the base address of slcbuf. The function securely discards the input if the remaining buffer space cannot accommodate a new triplet sequence.

// Patched Implementation Concept
void add_slc(unsigned char func, unsigned char flag, cc_t val) {
    // Fix: Ensure slcptr does not exceed slcbuf bounds
    if ((slcptr - slcbuf) >= (sizeof(slcbuf) - 6)) {
        return; // Discard input to prevent overflow
    }
    if ((*slcptr++ = (unsigned char) func) == 0xff)
        *slcptr++ = 0xff;
    if ((*slcptr++ = (unsigned char) flag) == 0xff)
        *slcptr++ = 0xff;
    if ((*slcptr++ = (unsigned char) val) == 0xff)
        *slcptr++ = 0xff;
}

This fix comprehensively eliminates the specific out-of-bounds write vector within add_slc. The architectural design of the Telnet protocol necessitates rigorous bounds checking across all subnegotiation handlers. Software engineers must verify that the process_slc function and related parsing routines accurately enforce the 108-byte constraint during data deserialization.

Exploitation initiates during the unauthenticated Telnet handshake phase. The attacker establishes a TCP connection to the target daemon and transmits an IAC WILL LINEMODE command. The server acknowledges this request and enters the appropriate state machine phase. This sequence opens the code path required for SLC subnegotiation.

The attacker proceeds by transmitting an IAC SB LINEMODE LM_SLC command followed by a specifically crafted payload of triplet data. The payload contains function codes exceeding the NSLC macro value of 18. This anomalous input forces the process_slc function to generate a "not supported" reply via the vulnerable add_slc routine.

The out-of-bounds write overwrites variables residing in the BSS segment. A critical escalation occurs when the sequential overflow overwrites the slcptr variable itself. The attacker replaces the valid buffer pointer with an arbitrary memory address of their choosing, hijacking the internal state of the daemon.

The server eventually executes the end_slc() function to finalize the network response construction. This function writes the Telnet suboption end marker (IAC SE) directly to the address currently held in the corrupted slcptr. Writing this marker to the attacker-controlled memory address yields a highly reliable, arbitrary memory write primitive.

The vulnerability grants an unauthenticated remote attacker complete control over the target system architecture. Exploitation yields arbitrary code execution with the system privileges of the running telnetd process. Because this daemon typically operates as the root user, the attacker achieves total system compromise.

Security researchers documented advanced exploitation techniques effective on specific 32-bit architectures, such as Debian Bookworm i386. The BSS overflow corrupts the def_slcbuf pointer alongside other variables. This specific corruption allows the attacker to trigger an arbitrary free condition, facilitating the bypass of modern exploit mitigations like Address Space Layout Randomization (ASLR).

The vulnerability additionally functions as a reliable information disclosure primitive. Corrupting slcptr to point to internal data structures causes the server to transmit sensitive BSS or heap data back to the attacker within the SLC network response. This memory leak assists the attacker in accurately mapping the target address space prior to final payload execution.

The widespread integration of the GNU Inetutils code base drastically amplifies the operational impact. The vulnerable implementation persists in numerous modern operating systems and legacy embedded devices. Network appliances running legacy services remain highly susceptible to automated exploitation campaigns.

The following diagram illustrates the interaction between the attacker and the vulnerable telnetd service during the exploitation sequence. The chart outlines the specific protocol commands required to trigger the BSS overflow condition.

The sequence highlights the architectural dependency on the LINEMODE protocol feature. The attacker must successfully negotiate this state before transmitting the malicious payload. The final arbitrary write primitive relies on the server finalizing the network response.

The most effective remediation strategy requires the complete deprecation of the Telnet protocol across the enterprise environment. Organizations must disable the telnetd service immediately and migrate all remote administration workflows to Secure Shell (SSH). The Telnet protocol transmits all data in plaintext and fundamentally lacks modern cryptographic protections.

Systems strictly requiring Telnet for legacy industrial control systems (ICS) or operational technology (OT) must deploy rigorous network segmentation. Network administrators must implement firewall rules and access control lists (ACLs) to severely restrict access to the Telnet port (TCP/23). Only highly trusted, internal IP addresses should route traffic to the vulnerable service.

Security operations teams must actively monitor network traffic for anomalous Telnet subnegotiation sequences. Intrusion detection systems (IDS) should alert on Telnet packets containing excessively long SLC sequences exceeding 36 triplets. This specific network signature reliably identifies the initial stages of the buffer overflow attack.

Organizations must apply the official GNU Inetutils patches immediately upon their public release. The specific patch modifies the add_slc function to enforce strict bounds checking on the slcbuf array. Administrators should verify the successful application of the patch by scanning internal networks for vulnerable daemon versions using available proof-of-concept detection scripts.