What Happened

Israeli cybersecurity firm Dream disclosed CVE-2026-32746 on March 11, 2026 — a critical pre-authentication remote code execution vulnerability in the GNU inetutils telnet daemon. The bug has a CVSS score of 9.8 and allows an unauthenticated attacker to achieve arbitrary code execution with root privileges by sending a crafted packet during the initial Telnet handshake, before any login prompt is displayed.

The vulnerability has existed in the codebase for approximately 32 years. A public proof-of-concept exploit is already available on GitHub. As of April 2, 2026, no official upstream release includes a fix — users must manually apply a commit from the Git repository and recompile.

Technical Details

The flaw sits in the LINEMODE Set Local Characters (SLC) suboption handler within telnetd. The add_slc() function writes three bytes per SLC triplet into slcbuf, a fixed 108-byte static buffer, without performing bounds checking. An attacker who sends more than 35 SLC triplets with function codes greater than 18 can overflow the buffer boundary.

The overflow corrupts adjacent memory on the stack, including a pointer that is later dereferenced for a write operation. By controlling this pointer, an attacker achieves an arbitrary write primitive. From there, standard exploitation techniques (overwriting GOT entries or return addresses) lead directly to code execution.

The attack requires no authentication, no user interaction, and no special privileges. A single malicious packet sent to port 23 during the Telnet option negotiation phase is sufficient.

CVE: CVE-2026-32746 CVSS 3.1: 9.8 (Critical) CWE: CWE-787 (Out-of-bounds Write) Affected versions: GNU inetutils through 2.7 (all versions) Attack vector: Network / Pre-auth / Port 23

Impact Assessment

Telnetd typically runs as root, so successful exploitation gives the attacker full system control immediately. Censys data from March 18 shows approximately 3,362 hosts with telnetd directly exposed to the internet.

That number understates the real exposure. Telnet remains widely deployed in environments where it is not internet-facing but still reachable from internal networks:

  • ICS/OT environments — Industrial control systems, SCADA interfaces, and operational technology gear frequently ship with telnet enabled by default and operate on slow upgrade cycles. Dream Security specifically flagged ICS and OT exposure in their advisory.
  • Network appliances — Managed switches, routers, and out-of-band management interfaces from multiple vendors bundle GNU inetutils telnetd or derivatives.
  • NAS devices — Synology issued a notice confirming their DSM is affected. QNAP confirmed they are not affected.
  • Legacy government and enterprise systems — Environments where SSH migration is incomplete still rely on telnet for administrative access.

Any host running GNU inetutils telnetd is vulnerable regardless of distribution. An attacker with internal network access — through phishing, VPN compromise, or lateral movement — can exploit this against systems that never appear in internet-facing scans.

Patch Status

The patch situation is fragmented:

  • Upstream (GNU inetutils): No official release includes the fix. A patch commit exists in the Git repository but has not been cut into a versioned release as of April 2.
  • Debian unstable: Fixed in inetutils source package version 2:2.7-4. Debian stable has not yet received the update.
  • Ubuntu: Listed as “Needs evaluation” across supported releases as of mid-March. No patched package available.
  • RHEL/CentOS: No advisory issued yet.

The April 1 target date for a coordinated fix has passed without a formal upstream release.

What To Do Right Now

1. Identify exposure. Scan your networks for anything listening on port 23. Don’t limit this to internet-facing assets — check internal networks, OT segments, and management VLANs.

1
2

# Quick scan for telnet listeners
nmap -p 23 --open -sV <your-ranges>

2. Disable telnetd where possible. If the service is not operationally required, shut it down immediately. For systems managed via inetd or xinetd, comment out the telnet entry and restart the super-daemon.

1
2
3
4
5
6
7

# Disable via systemctl if running standalone
sudo systemctl stop telnetd
sudo systemctl disable telnetd

# Or remove from inetd.conf
sudo sed -i 's/^telnet/#telnet/' /etc/inetd.conf
sudo systemctl restart inetd

3. Apply the manual patch. If you must keep telnetd running, pull the fix commit from the upstream Git repository, rebuild, and redeploy. This is the only option until your distro ships a patched package.

4. Network-level mitigation. If disabling or patching is not immediately feasible, restrict port 23 access at the firewall to only the specific management hosts that require it. This does not fix the vulnerability but limits the attack surface.

5. Monitor for exploitation. Watch for unusual Telnet option negotiation traffic, particularly oversized LINEMODE SLC suboption sequences. IDS signatures for CVE-2026-32746 are available from multiple vendors.

Sources