CVE-2026-32746: A 32-Year-Old Buffer Overflow in GNU Telnetd Exposes ICS and OT Systems to Root RCE

On March 11, 2026, Dream Security's research team reported a vulnerability in a piece of software most modern administrators assume is long dead. The target was GNU Inetutils telnetd — the Telnet daemon bundled with GNU's network utilities suite — and the bug was a stack-based buffer overflow sitting undetected in the codebase since approximately 1994. That is thirty-two years of exposure across every major Linux distribution that ships or enables the package. The vulnerability is tracked as CVE-2026-32746, classified under CWE-120 (buffer copy without bounds checking), and carries a CVSS 3.1 base score of 9.8. It has not yet received an official patch from the upstream GNU Inetutils project.

The timing compounds the risk. Less than two months before Dream's disclosure, a separate critical flaw in the same daemon — CVE-2026-24061, an authentication bypass rated CVSS 9.8 — was added to the U.S. Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog after confirmed active exploitation in the wild. That precedent matters: GNU Inetutils telnetd has become an active target, and two back-to-back critical disclosures in the same codebase signal to threat actors that the attack surface is fertile and under-audited.

The Vulnerability: What Breaks and Why

Telnet is not simply a raw TCP connection to a shell. The protocol, defined across a family of RFCs dating to the early 1970s, supports an in-band negotiation system for features such as terminal control, window-size exchange, and — critically for this vulnerability — the LINEMODE extension defined in RFC 1184. LINEMODE allows the Telnet client to perform local line editing before sending data to the server, reducing per-character round trips on high-latency links. Within LINEMODE, the SLC (Set Local Characters) suboption lets the server and client negotiate which control characters — backspace, interrupt, suspend, and others — map to which byte values.

The negotiation works through three-byte triplets, each encoding a function code, a modifier flag, and a character value. When a client sends an SLC suboption list back to the server, the daemon processes it by calling the function add_slc() inside telnetd/slc.c. The problem is straightforward and devastating: add_slc() writes each triplet into a fixed-size 108-byte buffer called slcbuf without ever checking whether space remains.

After 35 such triplets carrying function codes above 18, the buffer overflows into adjacent memory. Watchtowr Labs researchers, who published independent analysis on March 19, 2026, describe it as a BSS-based buffer overflow capable of corrupting roughly 400 bytes of adjacent variables. That corruption includes a pointer subsequently used for an arbitrary write — a primitive powerful enough to redirect program execution.

"An unauthenticated remote attacker can exploit this by sending a specially crafted message during the initial connection handshake — before any login prompt appears. Successful exploitation can result in remote code execution as root. A single network connection to port 23 is sufficient to trigger the vulnerability." — Dream Security advisory, March 2026

Dream Security researcher Adiel Sol elaborated in technical documentation: the attacker connects to port 23 and sends a crafted SLC suboption containing many triplets. No authentication credential is required. The overflow happens during Telnet option negotiation, before the login prompt is issued. The attack is therefore entirely pre-authentication and requires no user interaction on the target system.

Because GNU Inetutils telnetd is typically launched by inetd or xinetd as root, successful exploitation delivers a root shell directly. No privilege escalation step is required. The attacker transitions from anonymous network access to full system control in a single connection.

Scope: What Is Actually Affected

The upstream GNU Inetutils project is the canonical source, but the affected code has propagated widely through decades of copying. Watchtowr Labs confirmed the vulnerability exists in at minimum the following codebases, verified by examining the relevant slc.c source files in public repositories:

• GNU inetutils-telnetd — all versions through 2.7 (confirmed upstream)
• Ubuntu and Debian (all active releases except Debian sid/forky, which carries a fix as of the research date)
• FreeBSD 13 and the FreeBSD 15 port
• NetBSD 10.1
• Citrix NetScaler
• Apple Mac Tahoe
• TrueNAS Core
• Haiku
• uCLinux (common in embedded and OT devices)
• DragonFlyBSD
• libmtev

Watchtowr Labs summarized the ecosystem situation pointedly in their March 19 analysis: because inetutils has not made a new release, most Linux distributions have no updated package to ship, leaving the majority of affected systems without a straightforward upgrade path. The researchers note this reflects a familiar pattern — when upstream maintainers do not treat a vulnerability as release-worthy, the downstream ecosystem stalls.

Why ICS and OT Environments Are Particularly Exposed

The framing of this vulnerability as primarily an enterprise Linux concern misses where the real blast radius concentrates. Telnet was never fully replaced in Operational Technology environments. In many industrial facilities, Telnet remains the only supported remote management protocol for PLCs, SCADA components, serial gateways, CNC machines, and legacy embedded controllers. The economics are straightforward: a $250,000 CNC machine running an 8-bit microcontroller with firmware last updated in 2008 does not get retrofitted with an SSH client. The vendor may no longer exist. The integrator is no longer contracted. The machine is too expensive to halt for a security upgrade.

Dream Security Labs made this context explicit in their advisory:

"Although obsolete and insecure as it transmits data in cleartext, Telnet remains particularly prevalent in Industrial Control Systems (ICS), operational technology (OT) environments, and certain government networks, where aging infrastructure is common and modernization cycles are slow." — Dream Security Labs advisory, March 2026

The exposure is measurable. Attack surface management platform Censys counted approximately 3,362 internet-exposed hosts running telnet services as of March 18, 2026, in their rapid response advisory. Shodan figures from other researchers cite over 212,000 devices globally with Telnet port 23 openly accessible. The discrepancy reflects different scan methodologies and scope, but both figures confirm that Telnet exposure is not a theoretical edge case. It is a live, scannable attack surface that threat actors have automated tooling to enumerate in minutes.

OT and ICS environments introduce additional risk factors beyond mere exposure. Devices in these environments frequently lack modern memory protection mechanisms. ASLR (Address Space Layout Randomization) and PIE (Position-Independent Executables) — mitigations that significantly complicate reliable exploitation on modern systems — are often absent on embedded controllers, older SCADA servers, and industrial gateways. On systems without these protections, the overflow-to-arbitrary-write-to-root-shell path is substantially more deterministic for an attacker.

Post-exploitation on an OT-connected system is especially consequential. An attacker with root access to a device bridging IT and OT networks can deploy persistent backdoors, exfiltrate configuration data and process parameters, pivot laterally into the OT network, and in adversarial scenarios, issue control commands to connected equipment. The 2025 Claroty report noted that 82 percent of cyber-physical system attacks used remote access protocols as an entry vector — CVE-2026-32746 fits that attack pattern precisely.

A Vulnerability Born in 1994

The code containing this overflow dates to approximately 1994 — the same year the film Hackers was released, as Watchtowr Labs noted with dry precision. At that time, bounds checking in network daemons was inconsistent, memory protection mechanisms did not yet exist as operating system features, and Telnet was a primary remote administration protocol. The bug went undetected across three decades and dozens of major Linux releases.

This is not without precedent in the Telnet ecosystem. The vulnerability closely mirrors CVE-2001-0554, a similar SLC handler overflow in BSD-based telnet daemons that was disclosed and patched in 2001. The BSD code was fixed; the GNU implementation was not. The parallel codebases diverged in their security posture, and the GNU branch quietly accumulated 25 more years of exposure after the BSD fix.

Watchtowr Labs researchers note that the same vulnerable pattern exists in the Telnet client as well, not only the server daemon — meaning a malicious server could potentially trigger the overflow in a connecting client. The research team published a detection artifact with a "probe mode" that connects to a target, checks whether LINEMODE is advertised, and exits without sending an exploit payload — enabling defenders to audit their environments without causing harm to fragile legacy equipment.

# Check whether telnetd is installed and listening
which telnetd || dpkg -l | grep inetutils-telnetd || rpm -qa | grep inetutils
ss -lntp | grep ':23' || netstat -lntp | grep ':23'

# Disable via systemd if applicable
sudo systemctl stop telnet.socket telnet.service
sudo systemctl disable telnet.socket telnet.service

# Block at host firewall (iptables)
sudo iptables -A INPUT -p tcp --dport 23 -j DROP
sudo iptables -A OUTPUT -p tcp --sport 23 -j DROP

Mitigation and Response

Because no official patched release existed as of March 20, 2026, defenders have four actionable paths. The appropriate response depends on whether the Telnet service can be removed entirely or whether operational requirements mandate it remain running.

Option 1 — Disable telnetd entirely. This is the correct answer for any system where Telnet is not an operational requirement. Telnet transmits all data including credentials in plaintext, has no modern security baseline, and now carries two CVSS 9.8 vulnerabilities disclosed within two months. The service should be stopped, disabled, and the package removed where possible.

Option 2 — Block port 23 at the network perimeter and host firewall. For environments where the service cannot immediately be disabled, blocking inbound TCP port 23 from untrusted networks prevents exploitation from internet-facing vectors. This does not protect against insider threats or attacks originating from an already-compromised network segment.

Option 3 — Build from the patched git commit. The GNU Inetutils Codeberg repository contains a committed fix. Organizations capable of building from source can compile and deploy the patched version ahead of an official release. The relevant commit applies a bounds check to the add_slc() function, preventing the overflow entirely.

Option 4 — Monitor for exploitation indicators. For environments where none of the above is immediately feasible, network defenders should watch for inbound connections to port 23 from unexpected sources, anomalous volumes of SLC suboption data during Telnet handshakes, and unexpected process spawning from telnetd. IDS/IPS rules targeting LINEMODE SLC traffic with high triplet counts can flag active exploitation attempts if the security tooling supports Telnet protocol decoding.

The Broader Pattern: Legacy Protocol Risk in 2026

CVE-2026-32746 is not an isolated incident. It is one data point in a documented trend of critical vulnerabilities surfacing in legacy network protocol implementations that were once considered too old to be relevant attack surfaces. The GNU Inetutils suite has now produced two CVSS 9.8 vulnerabilities in under two months. CISA's ICS advisory program tracked 2,155 CVEs in 508 advisories in 2025 alone — 82 percent rated high or critical severity. The average CVSS score across ICS advisories crossed 8.0 for the first time in 2024 and held there through 2025.

The pattern Threat Landscape researchers describe as vulnerability drift is visible here: a bug is patched in one branch of a Unix family tree (BSD, in 2001) and quietly persists in another (GNU) for decades, undetected because the codebase is assumed to be stable and because the protocol is assumed to be irrelevant. Both assumptions proved wrong simultaneously in 2026.

The combined effect of CVE-2026-24061's active exploitation and CVE-2026-32746's disclosure creates an uncomfortable window. Defenders managing ICS environments with Telnet exposure face an unpatched critical RCE against a background of confirmed active exploitation of a related flaw in the same software. Threat actors — including APT groups historically documented targeting ICS infrastructure through remote access protocols — have both the motivation and, increasingly, the tooling to act quickly after technical details are published.

"While Telnet is widely considered a dead protocol in modern enterprise environments, it remains a staple in OT, ICS, and legacy embedded devices. 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." — Threat Landscape Blog, March 2026

The practical takeaway for security teams is that the age of a protocol is not a proxy for the safety of its implementation. Telnet has survived in production environments specifically because it has been ignored — which also means its codebase has gone unaudited for security issues that more actively maintained software would have caught long ago. CVE-2026-32746 is evidence of what that neglect accumulates to.

Key Takeaways

1. Pre-authentication, CVSS 9.8, no patch yet: CVE-2026-32746 combines the worst possible characteristics — no credentials needed, root-level impact, trivial exploitation complexity, and no official patched release from GNU Inetutils as of March 20, 2026. Any exposed system should be treated as a priority remediation item today.
2. ICS and OT carry the highest risk: Embedded devices without ASLR or PIE face more reliable exploitation. Systems where Telnet cannot be replaced due to vendor constraints require immediate network-layer isolation and compensating controls.
3. The blast radius extends beyond GNU Inetutils: The vulnerable add_slc() code was copied into at least a dozen other codebases including FreeBSD, NetBSD, Citrix NetScaler, TrueNAS Core, and Apple Mac Tahoe. Each requires independent patching by its respective maintainer.
4. Active exploitation context is already established: CVE-2026-24061 in the same daemon is on CISA's KEV catalog and under active exploitation. Threat actors are already targeting GNU Inetutils telnetd. CVE-2026-32746 expands that window significantly.
5. Immediate mitigations exist even without a patch: Disabling telnetd or blocking port 23 at the network perimeter fully eliminates the attack surface. There is no reason for any internet-facing host to have port 23 open in 2026.

Organizations running GNU Inetutils telnetd should audit their asset inventories for exposure today. Check for port 23 accessibility from untrusted networks, verify whether any OT or embedded systems rely on Telnet for remote management, and establish a timeline for either service removal or network segmentation. The expected patch release date of April 1, 2026 is less than two weeks away — but an unpatched CVSS 9.8 pre-auth RCE in an actively-targeted codebase is not a situation that warrants waiting. The mitigations are available now.