Vulnerability advisory: Pre-Auth Remote Code Execution via Buffer Overflow in telnetd LINEMODE SLC Handler

This advisory is published in the public interest to enable defenders to assess exposure and apply mitigations. Responsible disclosure practices apply.

Advisory ID: VULN-TELNETD-SLC-2025

Date: 2026-03-13

CVE ID: CVE-2026-32746

Severity: Critical

CVSS 3.1 Score: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

CWE Classification: CWE-120 (Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’))

Affected Product: GNU InetUtils telnetd

Affected Versions: all versions through 2.7

Attack Vector: Network (TCP port 23)

Authentication Required: None

Exploitation Complexity: Low

Active Exploitation: No confirmed exploitation at time of publication

Summary

Dream Security uncovered a new buffer overflow vulnerability (CVE-2026-32746) in the GNU Inetutils telnetd daemon, specifically in the code that handles LINEMODE SLC (Set Local Characters) option negotiation. 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. An initial report was sent to the GNU Inetutils security team following the discovery. 

Given the trivial exploitation requirements and the complete system compromise this enables,  service disablement is required, until a fix will be released.

Relevance

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. 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 — power grids, water treatment, manufacturing lines — or handle sensitive government data, meaning a successful exploit can have consequences far beyond a typical IT breach.

Affected Components

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.
  • Embedded systems and IoT devices that expose a TELNET interface for management or console access.
  • Industrial and operational technology (OT) environments where telnet is still used for legacy equipment or serial redirection.
  • 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.

Impact

Because  telnetd  typically runs as root (via  inetd  or  xinetd ), successful exploitation yields complete host compromise, including but not limited to:

  • Arbitrary remote code execution as root
  • Persistent backdoor installation
  • Sensitive data exfiltration
  • Use of the host as a pivot point for further network intrusion

A single network connection to port 23 is sufficient to trigger the vulnerability. No credentials, no user interaction, and no special network position are required.

Recommended Mitigations

Immediate (Workarounds)

  • Disable telnetd if not strictly required. Telnet transmits credentials in plaintext and has no role in a modern security posture; replace with SSH.
  • Block port 23 at the network perimeter and host-based firewall to restrict access to trusted hosts only.
  • Run telnetd without root privileges where operationally required and possible, to limit the impact of exploitation.
  • Isolate Telnet access

Detection and logging

  • Enable and retain logs for all inbound connections to port 23. Because exploitation occurs during option negotiation — before any login attempt — standard authentication logs (e.g.,  /var/log/auth.log ) will not capture it. Recommended measures:

    • Network-level logging: Use firewall rules (e.g.,  iptables, nftables, pf ) to log all new connections to port 23, capturing source IP, timestamp, and connection state.
    • Packet capture: 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.
    • Intrusion Detection: Deploy a network IDS signature to alert on LINEMODE SLC suboptions ( IAC SB LINEMODE 0x03 ) that carry an unusually large payload (e.g., > 90 bytes in the suboption data). Suricata and Snort both support Telnet option inspection.
    • Centralize and retain logs in a SIEM or log aggregator outside the target host, so that a successful root-level compromise does not allow the attacker to tamper with evidence.

How the Dream platform can help

Using the Dream Platform can identify Telnet exposure across the environment and enforce least-privilege network access to affected services. 

Timeline

March 11, 2026 – Vulnerability report submitted to GNU Inetutils (bug – inetutils list). [Initial report] (https://lists.gnu.org/archive/html/bug-inetutils/2026-03/msg00031.html).

March 12, 2026 – Maintainer (Collin Funk) confirms the finding and submits pull request with fix. PR [#17] (https://codeberg.org/inetutils/inetutils/pulls/17).

March 12, 2026 – Owner (Simon Josefsson) approves, release planned no later than April 1st, 2026.

March 13, 2026 – CVE-2026-32746 assigned and published.

About Dream

Dream was founded in January 2023 on the realization that governments and critical infrastructure need stronger solutions to protect against modern warfares. 
By leveraging deep expertise in cyber intelligence, Dream provides nations and critical infrastructure with advanced, real-time protection against evolving cyber threats. Our Cyber Security platform offers instant threat visibility, proactive risk mitigation, and full-spectrum defense to safeguard national security.

The Dream team consists of world-leading cybersecurity experts and AI professionals who have developed a new standard of digital protection. 

Our mission: Empowering governments and critical infrastructure with the AI tools and intelligence to defend against nation-state cyber threats and secure digital resilience end-to-end.

CONTACT US

Fill out the form to get in touch with our Expert Team.