CVE-2026-32746: Unpatched GNU InetUtils Telnetd Flaw Gives Root Before Login

A critical, unpatched buffer overflow in GNU InetUtils telnetd — tracked as CVE-2026-32746 with a CVSS score of 9.8 — allows an unauthenticated remote attacker to execute arbitrary code as root before a login prompt ever appears. The flaw affects all versions through 2.7. No patch is available as of March 18, 2026.

On March 13, 2026, Israeli cybersecurity firm Dream Security published a vulnerability advisory disclosing CVE-2026-32746, a pre-authentication remote code execution flaw in the GNU InetUtils telnet daemon. The timeline is unambiguous: Dream reported the issue to the GNU InetUtils security team on March 11, maintainer Collin Funk confirmed it and submitted a pull request with a fix on March 12, project owner Simon Josefsson approved it the same day, and the CVE was assigned on March 13. A patched release is planned no later than April 1, 2026. Until that release ships and distributions package it, every system running GNU InetUtils telnetd version 2.7 or earlier with port 23 reachable over the network is exposed.

This is not a theoretical or complex-to-exploit vulnerability. The attack requires a single network connection to port 23 and a specially crafted packet sent during the initial Telnet handshake. No credentials are needed. No user interaction is required. No special network position is necessary. The attacker sends one message before the daemon has even shown a login prompt, and if conditions are right, the system is theirs.

What the Vulnerability Is and How It Works

CVE-2026-32746 is classified as CWE-120 — a classic buffer overflow caused by copying input data without checking its size against the destination buffer. The specific location is the LINEMODE SLC (Set Local Characters) suboption handler inside the telnetd daemon.

To understand the flaw, it helps to know what LINEMODE SLC actually does. When a Telnet client connects to a server, the two sides negotiate how line editing will work. The LINEMODE option, defined in RFC 1116, allows the client to indicate that it will handle line-by-line input locally rather than sending each character one at a time. As part of this negotiation, the client sends SLC (Set Local Characters) data — a list of triplets that map control characters to specific terminal functions (like interrupt, erase, or end-of-file). Each triplet is three bytes: the function ID, flags, and the character value.

The vulnerability is in how telnetd receives and processes this list. An attacker can send an SLC suboption containing an abnormally high number of triplets — far more than the internal buffer was allocated to hold. The daemon copies this data without verifying the count against the buffer boundary, resulting in a write beyond the end of the allocated memory. That out-of-bounds write corrupts adjacent memory, and with sufficient control over what gets written and where, an attacker can redirect execution flow.

"No login is required. This bug occurs during option negotiation before the login prompt. An overflow can corrupt memory and can be turned into arbitrary writes. In practice, this can lead to remote code execution. Because telnetd usually runs as root (e.g., under inetd or xinetd), a successful exploit would give the attacker full control of the system." — Dream Security advisory, March 13, 2026

The CVSS 3.1 vector string for this vulnerability is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network-accessible, low attack complexity, no privileges required, no user interaction, with high impact across confidentiality, integrity, and availability. That combination produces the maximum practical score of 9.8.

The attack path operates entirely before authentication. The vulnerable code path executes as soon as a client completes the initial Telnet handshake and negotiates LINEMODE. There is no login prompt gate, no session establishment, no session token — just a raw TCP connection to port 23 and a crafted suboption payload.

No public proof-of-concept exploit code has been officially released as of this writing. Dream Security stated that responsible disclosure practices apply and withheld technical details that would accelerate weaponization. That said, the advisory contains enough technical specificity — CWE-120, the LINEMODE SLC handler, the abnormally high triplet count as the trigger — that skilled attackers with knowledge of Telnet protocol internals will be able to reconstruct the attack path independently. The window between disclosure and working exploit code is typically short for vulnerabilities of this severity and simplicity.

Who Is Affected

The vulnerability affects any system running GNU InetUtils telnetd version 2.7 or earlier where the daemon is reachable over the network. Dream Security's advisory explicitly confirmed a broad affected version range, listing versions 1.9.3, 1.9.4, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, and 2.7 as vulnerable. Linux distributions that ship inetutils and leave telnetd enabled or installable — including Debian, Ubuntu, RHEL, and SUSE Linux Enterprise Server — are in scope. So are embedded systems and IoT devices that expose a Telnet interface for management or console access, and industrial and operational technology (OT) environments where Telnet remains in use for legacy equipment or serial redirection.

The OT and ICS angle deserves particular attention. Dream Security's advisory notes that Telnet persists in these environments because programmable logic controllers (PLCs), SCADA systems, and network devices manufactured before SSH became the standard were designed with Telnet as their sole remote management interface. Replacing or upgrading such systems is often prohibitively expensive, operationally disruptive, or impossible without vendor support that may no longer exist. In government networks, long procurement cycles and strict change control processes mean insecure protocols can persist for years even after vulnerabilities are publicly known. This makes CVE-2026-32746 especially dangerous in critical infrastructure contexts — the systems behind exposed Telnet interfaces frequently control physical processes like power grids, water treatment plants, and manufacturing lines.

Internet-facing exposure is measurable. Shodan data cited at time of disclosure showed over 212,000 devices exposing Telnet services on port 23 to the public internet. Not all of these run GNU InetUtils telnetd specifically, but the number underscores how widely the legacy protocol remains reachable. Importantly, TXOne Networks research into the earlier CVE-2026-24061 exploitation wave found that attackers targeted Telnet services on non-standard ports as well as the default port 23, meaning firewall rules that block only port 23 may not be sufficient on their own if the daemon is accessible elsewhere on the network.

The Bigger Picture: A Pattern of Telnet Failures

CVE-2026-32746 did not emerge in isolation. It arrives less than two months after another critical vulnerability in GNU InetUtils telnetd — CVE-2026-24061 — was disclosed and subsequently added to CISA's Known Exploited Vulnerabilities (KEV) catalog.

CVE-2026-24061 is a different class of flaw: an argument injection vulnerability rather than a buffer overflow. It stems from unsafe handling of the USER environment variable passed through the Telnet protocol's NEW_ENVIRON option. During connection negotiation, an attacker sets USER to the string -f root. The daemon forwards this value unsanitized to /usr/bin/login as a command-line argument, and the -f flag instructs login to skip password verification entirely and grant a shell for the specified user — in this case, root. The result is an instant, unauthenticated root shell with no buffer corruption required.

"The telnetd server invokes /usr/bin/login (normally running as root) passing the value of the USER environment variable received from the client as the last parameter. If the client supplies a carefully crafted USER environment value being the string '-f root' ... the client will be automatically logged in as root bypassing normal authentication." — Simon Josefsson, GNU InetUtils maintainer, oss-security mailing list, January 2026

CVE-2026-24061 was added to CISA's KEV catalog on January 26, 2026, six days after disclosure, after active exploitation was confirmed in the wild. Federal Civilian Executive Branch (FCEB) agencies were required to apply patches by February 16, 2026. Research from TXOne Networks documented three distinct waves of exploitation beginning January 22, involving 52 distinct source IPs across 16 countries. Attack patterns ranged from simple probe payloads validating vulnerability to stager scripts that attempted curl, then wget, then raw TCP to fetch and execute payloads in memory — a pattern consistent with organized exploitation campaigns rather than individual opportunistic actors.

Two critical CVSS 9.8 vulnerabilities in the same daemon within two months, one already under active exploitation, and another with no patch yet available. This is not a coincidence born from one researcher's curiosity — it reflects the structural reality of a legacy codebase that was never designed with adversarial network conditions in mind, deployed on millions of devices that were never designed to be updated, in environments that lack the operational flexibility to patch quickly even when updates exist.

The GNU InetUtils maintainer Simon Josefsson has previously stated that users should avoid running telnetd entirely and restrict network access to the Telnet port to trusted clients. That position, stated in the context of CVE-2026-24061, applies with even greater force now. Two back-to-back critical flaws in the same component are a signal, not a coincidence.

Why Telnet Still Runs in 2026

The question defenders and executives legitimately ask is: why does Telnet persist at all? The protocol transmits all data — including credentials — in plaintext, has no encryption, and predates modern threat models by decades. SSH has been the standard for encrypted remote access since the late 1990s. The answer is almost entirely operational rather than technical. In industrial environments, programmable logic controllers and SCADA components shipped with Telnet as the only remote interface because that was the standard of the era. Vendors may no longer support or certify firmware updates. Operational disruption from taking a production line offline to replace a controller can cost more than many organizations' annual security budgets. In government and regulated industries, change management processes require extensive testing and approval cycles before any modification to production systems.

None of these explanations eliminate the risk. They do explain why blanket advice to "just disable Telnet" is insufficient guidance for a significant portion of the organizations most exposed to this class of vulnerability. For those environments, the relevant mitigations are network-layer controls, not software replacement — at least on the timescale of this vulnerability's patch window.

Detection and Mitigation

Dream Security's advisory and subsequent analysis from GBHackers and Rescana identify several concrete mitigation and detection steps that organizations should implement immediately, prioritized by how quickly they can be applied.

Disable telnetd. If the service is not operationally required, disable it. This eliminates the attack surface entirely. Telnet has no place in a modern security posture, and the bar for keeping it running must now be explicit operational necessity with documented compensating controls.

Block port 23 at network perimeters and host-based firewalls. If disabling the service is not immediately feasible, restrict access to port 23 to a defined set of trusted source IPs. This does not eliminate the risk on the local network but removes internet-facing exposure. Apply the same restriction to any non-standard ports where telnetd may be listening.

Run telnetd without root privileges where operationally required. Because telnetd typically runs as root via inetd or xinetd, a successful exploit yields complete system control. Running the daemon as an unprivileged user limits blast radius, though it does not prevent code execution from occurring.

Isolate Telnet-accessible systems. Network segmentation — separating systems that require Telnet access from those that do not — limits lateral movement opportunities if a system is compromised.

Detection is more complex for CVE-2026-32746 than for CVE-2026-24061. The earlier authentication bypass vulnerability left artifacts in authentication logs — root login events via telnetd without corresponding password prompts. CVE-2026-32746 triggers during option negotiation, before any login attempt, which means standard authentication logs such as /var/log/auth.log will not capture exploitation attempts at all.

Dream Security's advisory specifies three detection approaches that account for this gap. First, use firewall rules — iptables, nftables, or pf — to log all new connections to port 23, capturing source IP, timestamp, and connection state. Second, where feasible, capture full or truncated Telnet session traffic for forensic review; a crafted SLC suboption with an abnormally high triplet count is a strong indicator of exploitation attempts. Third, deploy network IDS signatures to alert on LINEMODE SLC suboptions (IAC SB LINEMODE 0x03) carrying unusually large payloads — specifically, payloads exceeding approximately 90 bytes in the suboption data. Both Suricata and Snort support Telnet option inspection and can be configured to alert on these patterns.

Log centralization is critical for post-compromise forensics. A successful root-level compromise gives the attacker the ability to tamper with or delete logs on the target system. Shipping logs to a SIEM or external aggregator in real time — before exploitation can occur — ensures that evidence survives even if the host is fully compromised.

# Example iptables rule to log all new inbound connections on port 23
iptables -A INPUT -p tcp --dport 23 -m state --state NEW -j LOG --log-prefix "TELNET-NEW: " --log-level 4

# Example Suricata rule concept for oversized LINEMODE SLC suboption
# alert tcp any any -> $HOME_NET 23 (msg:"Potential CVE-2026-32746 LINEMODE SLC overflow"; \
#   content:"|ff fa 22 03|"; depth:4; isdataat:90,relative; \
#   classtype:attempted-admin; sid:9999001; rev:1;)

Key Takeaways

1. Pre-authentication, single-packet exploitation: CVE-2026-32746 requires no credentials, no user interaction, and no special network position. A single crafted TCP connection to port 23 during the Telnet handshake is sufficient to trigger the overflow. If telnetd is reachable, it must be treated as immediately at risk.
2. Root-level impact with no privilege escalation needed: Because GNU InetUtils telnetd typically runs as root via inetd or xinetd, a successful exploit yields complete host compromise — arbitrary code execution as root, persistent backdoor installation, data exfiltration, and full network pivot capability — without any additional escalation step.
3. No patch available yet: The fix exists in source form and is approved, but no released version of GNU InetUtils incorporates it as of March 18, 2026. The planned release date is April 1, 2026. Until a patched release ships and distributions package it, mitigations are the only available controls.
4. This is the second critical CVSS 9.8 telnetd flaw in two months: CVE-2026-24061 reached CISA's KEV catalog and was under active exploitation within days of disclosure. CVE-2026-32746 follows the same disclosure pattern in the same codebase. Organizations that did not disable Telnet after the first vulnerability should treat this second disclosure as a definitive signal.
5. Standard authentication logs will not catch exploitation: Because the vulnerable code path runs before any login attempt, auth.log and similar sources will not record exploitation. Detection requires network-layer logging, packet capture, and IDS signatures tuned specifically for oversized LINEMODE SLC suboptions.

The core obligation for any organization running GNU InetUtils telnetd is straightforward: audit exposure now. Identify every system running telnetd, verify whether it is reachable — including on non-standard ports — and either disable the service or apply compensating network controls immediately. The patch window is short, the exploit complexity is low, and the preceding exploitation of CVE-2026-24061 demonstrates that threat actors are actively scanning for and weaponizing GNU telnetd vulnerabilities. Waiting for a patch before acting is not an adequate response to a pre-authentication root RCE with no existing patch and a proven pattern of rapid weaponization in this same software.