Dream Security Labs published a vulnerability advisory detailing a pre-authentication remote code execution flaw caused by a buffer overflow in the telnetd LINEMODE SLC handler. The research uncovered a critical buffer overflow vulnerability, CVE-2026-32746, in the GNU Inetutils telnetd daemon, specifically within the LINEMODE SLC option negotiation handler. An unauthenticated remote attacker can exploit the flaw by sending a specially crafted message during the initial connection handshake, before any login prompt appears, potentially achieving remote code execution with root privileges.
The issue was reported to the GNU Inetutils security team following its discovery.
The advisory, identified as VULN-TELNETD-SLC-2025 and released on March 13, 2026, is issued in the public interest to help defenders assess exposure and apply mitigations, in line with responsible disclosure practices. Tracked as CVE-2026-32746, the vulnerability is rated critical with a CVSS 3.1 score of 9.8. It is classified under CWE-120, which refers to a buffer copy without proper bounds checking, commonly known as a classic buffer overflow. The issue affects GNU InetUtils telnetd in all versions up to and including 2.7.
The attack vector is network-based over TCP port 23, requires no authentication, and has low exploitation complexity. While the flaw poses a high risk to confidentiality, integrity, and availability, there is no confirmed evidence of active exploitation at the time of publication.
“Although obsolete and insecure as it transmits data in clear data, 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 wrote in its recent advisory. “Many programmable logic controllers (PLCs), SCADA systems, and network devices deployed in these environments were manufactured before SSH became the standard, and were designed with Telnet as their sole remote management interface. Replacing or upgrading such systems is often prohibitively expensive, operationally disruptive, or outright impossible without vendor support — which may no longer exist for legacy equipment.”
In government contexts, long procurement cycles and strict change control processes mean that insecure protocols can persist for years even after vulnerabilities are publicly known. This makes Telnet exposure in these sectors especially dangerous: the systems behind it frequently control physical processes across power grids, water treatment, manufacturing lines, or handle sensitive government data, meaning a successful exploit can have consequences far beyond a typical IT breach.
The post noted that any organization or product that runs GNU Inetutils telnetd with the vulnerable SLC implementation is affected. This includes Linux distributions that ship inetutils (e.g., Debian, Ubuntu, RHEL, SUSE) and leave telnetd enabled or installable; and embedded systems and IoT devices that expose a TELNET interface for management or console access.
Additionally, industrial and OT environments where Telnet is still used for legacy equipment or serial redirection. Also, Servers and appliances that listen on TCP port 23 and use this codebase. The vulnerable code path runs as soon as a client completes the initial TELNET handshake and negotiates LINEMODE. Every connection that sends a crafted SLC suboption can trigger the overflow. No user interaction or credentials are required.
As telnetd typically runs with root privileges through inetd or xinetd, successful exploitation can lead to full system compromise. This includes arbitrary remote code execution as root, persistent backdoor installation, sensitive data exfiltration, and the use of the compromised host as a pivot point for further network intrusion. The GNU Inetutils vulnerability can be triggered with a single network connection to port 23. It requires no authentication, no user interaction, and no privileged network position.
Dream Security called for immediate workarounds. Telnetd should be disabled if it is not strictly required, as Telnet transmits credentials in plaintext and no longer fits within a modern security posture; it should be replaced with SSH wherever possible. Access to port 23 should be blocked at both the network perimeter and host-based firewalls, limiting connectivity to trusted hosts only. Where telnetd must remain operational, it should be run without root privileges to reduce the impact of a potential compromise, and access should be isolated as tightly as possible.
Detection and logging are equally critical. Organizations should enable and retain logs for all inbound connections to port 23, keeping in mind that exploitation occurs during option negotiation before any login attempt, meaning standard authentication logs such as /var/log/auth.log will not capture these events. Network-level logging should be configured using firewall rules such as iptables, nftables, or pf to record all new connections to port 23, including source IP addresses, timestamps, and connection states.
Where feasible, packet capture should be implemented to record full or partial Telnet session traffic for forensic analysis. A crafted SLC suboption with an unusually high triplet count can serve as a strong indicator of exploitation attempts. Intrusion detection systems should also be deployed with signatures designed to flag LINEMODE SLC suboptions, specifically IAC SB LINEMODE 0x03, that carry abnormally large payloads, for example, those exceeding 90 bytes. Tools such as Suricata and Snort support inspection of Telnet options and can be used for this purpose.
Finally, logs should be centralized and retained within a SIEM or external log aggregator to ensure that evidence remains intact even in the event of a successful root-level compromise, preventing attackers from tampering with or erasing forensic data.
