Telnet is a protocol that most enterprise IT security teams treat as a solved problem — disabled, blocked, and replaced by SSH years ago. In OT environments, that assumption has not held. PLCs, SCADA remote terminal units, industrial embedded systems, and connected building equipment frequently expose telnet interfaces because they were built before SSH was standard, because the vendor never implemented SSH, or because operations teams continue to use telnet for legacy equipment management.

CVE-2026-32746 makes that continued telnet exposure acutely dangerous. It is a pre-authentication remote code execution vulnerability in GNU Inetutils telnetd — the telnet server daemon present in a wide range of Linux-based systems, embedded devices, and OT equipment. The CVSS 3.1 score is 9.8 Critical. An attacker with network access to a telnet port can execute code as root before the login prompt ever appears.

The Vulnerability Explained

GNU Inetutils is the GNU project’s collection of common network utilities and servers, including telnetd — the daemon that handles incoming telnet connections. It is present in many Linux distributions as part of the base package set, and it is included in the firmware of a substantial number of embedded systems and OT devices that run Linux internally.

CVE-2026-32746 is classified as CWE-120: buffer copy without proper bounds checking. During the initial connection handshake — the sequence of protocol negotiation messages that occurs before any authentication challenge is presented — telnetd fails to properly validate the size of incoming data. An attacker can craft a malicious connection sequence that overflows a buffer and achieves code execution.

The critical aspect of this vulnerability is its position in the connection lifecycle. Authentication has not yet been evaluated when the vulnerable code executes. There is no credential check to bypass, no session token to steal, no privileged function to reach through an injection. The exploit fires at connection establishment, before the server has had any opportunity to authenticate the connecting client.

The result is root-level code execution on the affected system. On a general-purpose Linux server, that is a serious but familiar type of vulnerability. On a PLC or SCADA component running an embedded Linux environment, it means an unauthenticated attacker with network access to port 23 controls the device.

All versions of GNU Inetutils up to and including 2.7 are affected.

Where This Matters in OT and Smart Building Environments

The categories of OT and industrial equipment that run telnet interfaces — and that may be running GNU Inetutils or embedded Linux telnetd implementations with similar vulnerabilities — include several that are common in smart office and industrial deployments:

PLCs with remote management interfaces. Some PLC models include telnet-accessible management consoles for configuration and diagnostic purposes. These interfaces are frequently left enabled because they are used by maintenance personnel and system integrators who rely on them for remote access. In plants where engineering access is conducted over telnet by established practice, disabling telnet breaks workflows that have been in place for years.

SCADA remote terminal units (RTUs). RTUs in field deployments — utility substations, water treatment facilities, pipeline monitoring — often run embedded Linux with telnet enabled for remote configuration access. The assumption has historically been that the OT network provides sufficient isolation; direct internet exposure was not considered part of the threat model when these devices were deployed.

Serial-to-IP converters and protocol gateways. These devices, which appear on the 2026 riskiest connected device list, frequently run embedded Linux with management interfaces accessible via telnet. They bridge legacy serial protocols to IP networks and sit in architecturally sensitive positions.

Building automation controllers. Smart building systems including HVAC controllers, energy management systems, and lighting controllers that run embedded Linux may include telnet management capabilities.

IoT devices with embedded Linux. The broader category of IoT devices that run embedded Linux — environmental sensors, connected cameras, industrial monitoring equipment — potentially includes devices with GNU Inetutils telnetd in their firmware.

No Confirmed Active Exploitation — But the Risk Horizon Is Short

As of the time of publication, there is no confirmed evidence of active in-the-wild exploitation of CVE-2026-32746. That is meaningful context — this is not a currently weaponized threat in the same category as the Four-Faith router exploitation or the Cisco FMC zero-day.

However, the characteristics of this vulnerability make the exploitation timeline a planning concern rather than a long-term comfort. A CVSS 9.8 pre-authentication RCE with publicly disclosed technical details has a short runway before exploitation begins. The history of high-severity vulnerabilities in network-facing services is consistent: when a technically straightforward exploit exists for a widely deployed service, weaponized versions appear quickly.

For OT environments specifically, the relevant planning horizon is not the same as for enterprise IT. Patching a Linux server typically takes hours to days. Patching embedded firmware on industrial equipment — PLCs, RTUs, building controllers — typically takes weeks to months, involves vendor coordination, requires maintenance windows that may be months away, and in some cases is not possible because the vendor has ended support for the affected hardware.

Organizations that identify telnet-enabled OT equipment in their environments today need to begin that remediation process now, because if active exploitation follows the typical pattern for this class of vulnerability, the window between disclosure and widespread exploitation may close before the remediation cycle completes.

Assessing and Remediating Exposure

Step 1: Identify telnet exposure. Conduct a network scan to identify all devices in the OT and corporate network environments that have port 23 open. This should include the OT network segments that may have been excluded from prior vulnerability scans. Passive traffic analysis can also identify telnet sessions if active scanning is undesirable in OT environments.

Step 2: Inventory affected systems. For each device with port 23 open, determine whether it is running GNU Inetutils telnetd or an embedded telnet daemon with similar characteristics. Linux-based systems running Inetutils can be checked via package management tools; embedded systems require firmware identification.

Step 3: Apply patches. GNU Inetutils patches are available. For Linux distributions that package Inetutils, distribution-level updates should be applied. For embedded systems, check with the device vendor for firmware updates that address CVE-2026-32746.

Step 4: Disable telnet where SSH is available. For any system that supports SSH, disable telnet entirely. SSH provides equivalent management access with encryption and authentication that telnet lacks. On systems where operations teams have been using telnet by habit rather than necessity, this requires workflow changes but not functional capability loss.

Step 5: Network-level controls for systems that cannot be immediately patched. For OT equipment where patching or disabling telnet is not immediately possible, implement network-level controls that restrict telnet access to specific management IP addresses. Firewall rules that limit port 23 access to known management workstations significantly reduce the attack surface, even if the underlying vulnerability remains unpatched.

Step 6: Segment OT telnet traffic. Telnet-enabled OT equipment should not be reachable from the corporate IT network or from the internet. If network architecture currently allows telnet access to OT devices from broader network segments, segmentation changes that isolate that access are a priority remediation.

The Persistent Problem of Legacy Protocols in OT

CVE-2026-32746 is a specific vulnerability, but it represents a general problem: OT environments run legacy protocols and services that would be unacceptable in enterprise IT environments, for reasons that are understandable but that create significant security exposure.

Telnet persists in OT because the alternative — migrating to SSH — requires firmware updates or hardware replacement across device fleets that have long lifecycles and operational continuity constraints. The mathematics of that migration are genuinely challenging: a utility operating field equipment with planned lifecycle of 15-20 years cannot simply replace devices that don’t support SSH on a schedule driven by IT security policy.

The appropriate response to that challenge is not to accept telnet exposure indefinitely. It is to apply network-level controls that compensate for the vulnerability while longer-term migration planning proceeds, to accelerate firmware update cycles where vendors provide patches, and to include protocol modernization in capital planning for OT equipment replacement.

CVE-2026-32746 makes the urgency of that planning concrete. A 9.8 CVSS pre-authentication RCE in telnetd is not a theoretical risk to OT environments that still run telnet — it is an active capability in the hands of any attacker who reaches port 23.