CVE-2026-32746 — Critical Unpatched Telnetd Flaw Enables Pre-Auth Root RCE via a Single Packet to Port 23

A critical vulnerability in the GNU inetutils Telnet daemon (telnetd) allows an unauthenticated remote attacker to execute arbitrary code as root by sending a single malicious packet during the Telnet protocol handshake — before any login prompt is displayed.

The vulnerability, tracked as CVE-2026-32746, carries a CVSS 9.8 (Critical) rating and was discovered by Israeli cybersecurity firm Dream on March 11, 2026. It affects all versions of GNU inetutils telnetd through version 2.7 and is currently unpatched. A fix is expected no later than April 1, 2026.

This is the second critical pre-authentication RCE in GNU inetutils telnetd disclosed in 2026. The first — CVE-2026-24061 — is an authentication bypass that has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog after confirmed active exploitation in the wild.

Vulnerability Summary

How It Works

The vulnerability exists in the LINEMODE SLC (Set Local Characters) suboption handler — specifically in the add_slc function that processes SLC option negotiation during the Telnet protocol handshake.

The Root Cause

When a Telnet client connects to telnetd, the two parties negotiate terminal capabilities through a series of suboption exchanges. One such suboption is LINEMODE SLC, which defines how specific characters (interrupt, erase, kill, etc.) are handled locally.

The add_slc function processes incoming SLC triplets (character definition, flag, value) and writes them into a fixed-size buffer. The critical flaw: add_slc never checks whether the buffer is full before writing the next triplet.

// Simplified vulnerable code (conceptual)
static void add_slc(int func, int flag, cc_t val) {
    // NO BOUNDS CHECK — writes past end of buffer
    slc_reply.data[slc_reply.len].func = func;
    slc_reply.data[slc_reply.len].flag = flag;
    slc_reply.data[slc_reply.len].val  = val;
    slc_reply.len++;
    // When slc_reply.len exceeds buffer capacity → heap overflow
}

By sending a LINEMODE SLC suboption containing many triplets (far more than the buffer was designed to hold), an attacker triggers an out-of-bounds write that corrupts adjacent heap memory.

Pre-Authentication Trigger

The critical detail is when this code executes. The SLC handler runs during option negotiation — the protocol handshake that occurs immediately after a TCP connection is established on port 23, but before the login prompt.

This means:

• No credentials are required
• No user interaction is required
• No special network position is required
• A single TCP connection to port 23 is sufficient

Exploitation Flow

Attacker connects to port 23 (TCP)
        │
        ▼
telnetd begins option negotiation (protocol handshake)
        │
        ▼
Attacker sends crafted LINEMODE SLC suboption
with hundreds of triplets (exceeding buffer capacity)
        │
        ▼
add_slc() writes past end of buffer — heap overflow
        │
        ▼
Adjacent heap metadata is corrupted
        │
        ▼
Attacker-controlled values overwrite arbitrary memory
        │
        ▼
Execution flow redirected to attacker shellcode
        │
        ▼
Code execution as ROOT (telnetd runs under inetd/xinetd as root)

Why Root?

By convention, telnetd runs with root privileges because it needs to:

• Bind to a privileged port (23)
• Spawn login shells for connecting users
• Set up pseudo-terminals (PTYs) owned by different users

When launched by inetd or xinetd (the standard deployment model), telnetd inherits root privileges from the super-server. A successful buffer overflow exploit therefore executes the attacker's payload as root — granting complete control of the host.

CVSS v3.1 Breakdown

Every metric is at its most severe value except Scope. This is as close to a "perfect 10" as a vulnerability gets.

MITRE ATT&CK Mapping

Who Is Affected

Direct Impact

• GNU inetutils ≤ 2.7 — all versions
• Debian 11 (Bullseye), 12 (Bookworm), 13 (Trixie), 14 (Forky) — confirmed affected
• Ubuntu — any release shipping inetutils-telnetd
• RHEL / CentOS / Fedora — if telnetd from inetutils is installed
• Arch Linux, Gentoo, openSUSE — if inetutils telnetd is enabled

Extended Attack Surface

While modern Linux servers have largely moved to SSH, Telnet remains prevalent in:

Any device running GNU inetutils telnetd ≤ 2.7 with port 23 reachable is vulnerable to unauthenticated root compromise.

The Second Critical Telnetd CVE in 2026

CVE-2026-32746 is not the first critical telnetd flaw this year. In January 2026, CVE-2026-24061 was disclosed — an authentication bypass in the same GNU inetutils telnetd:

The existence of two independent CVSS 9.8 pre-auth RCE flaws in the same daemon within two months underscores a fundamental truth: telnetd was never designed for a hostile network environment and should be considered inherently unsafe for any internet-facing or production deployment.

Detection

Identify Exposed Telnet Services

# Scan internal network for open port 23
nmap -sV -p 23 --open 10.0.0.0/8 192.168.0.0/16 172.16.0.0/12

# Check if telnetd is running on the local host
ss -tlnp | grep ':23'
systemctl status inetutils-telnetd 2>/dev/null
systemctl status xinetd 2>/dev/null && grep telnet /etc/xinetd.d/*

# Check installed inetutils version
dpkg -l inetutils-telnetd 2>/dev/null    # Debian/Ubuntu
rpm -q inetutils 2>/dev/null              # RHEL/CentOS
pacman -Q inetutils 2>/dev/null           # Arch

IDS/IPS Detection — Snort / Suricata Rules

# Detect LINEMODE SLC overflow attempt on port 23
alert tcp any any -> $HOME_NET 23 (
    msg:"EXPLOIT CVE-2026-32746 telnetd LINEMODE SLC Buffer Overflow Attempt";
    flow:to_server,established;
    content:"|FF FA 22|";         # IAC SB LINEMODE
    content:"|03|";               # SLC suboption
    byte_test:1,>,100,0,relative; # Excessive SLC triplet count
    threshold:type limit, track by_src, count 1, seconds 60;
    classtype:attempted-admin;
    sid:2026327460;
    rev:1;
    reference:cve,2026-32746;
)

The rule triggers on:

• FF FA 22 — IAC (Interpret As Command) + SB (Subnegotiation Begin) + LINEMODE
• 03 — SLC suboption identifier
• More than 100 triplets — an abnormally large SLC payload indicative of exploitation

SIEM Detection (KQL — Azure Sentinel / Defender XDR)

// Detect inbound connections to Telnet port 23
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where LocalPort == 23 or RemotePort == 23
| where ActionType == "ConnectionSuccess"
| summarize
    ConnectionCount = count(),
    UniqueSourceIPs = dcount(RemoteIP),
    SourceIPs = make_set(RemoteIP, 10)
    by DeviceName, LocalPort
| where ConnectionCount > 0
| order by ConnectionCount desc

// Alert on telnetd process crashes (DoS or failed exploitation)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName in~ ("telnetd", "in.telnetd")
| where ActionType == "ProcessCrashed" or ActionType == "ProcessTerminated"
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine, AccountName

Network Forensics — pcap Analysis

# Extract Telnet sessions from packet capture
tshark -r capture.pcap -Y "tcp.port == 23" -T fields \
    -e frame.time -e ip.src -e ip.dst -e tcp.len \
    -e telnet.option_data

# Look for LINEMODE SLC suboptions with abnormally large payloads
tshark -r capture.pcap -Y "telnet.option == 34 && tcp.len > 200" \
    -T fields -e ip.src -e ip.dst -e tcp.len

YARA Rule

rule CVE_2026_32746_Telnetd_Exploit {
    meta:
        description = "Detects exploitation attempt for CVE-2026-32746 telnetd LINEMODE SLC overflow"
        author = "4nuxd.one"
        date = "2026-03-18"
        reference = "CVE-2026-32746"
        cvss = "9.8"
    strings:
        // IAC SB LINEMODE SLC
        $iac_sb_linemode = { FF FA 22 03 }

        // Large block of SLC triplets (3-byte tuples)
        // Pattern: multiple consecutive triplets following the SLC suboption
        $slc_flood = { FF FA 22 03 [100-] FF F0 }

        // Post-exploitation indicators
        $shell1 = "/bin/sh" ascii
        $shell2 = "/bin/bash" ascii
        $reverse1 = "bash -i >& /dev/tcp/" ascii
        $reverse2 = "nc -e /bin/sh" ascii
        $bindshell = "0.0.0.0" ascii

    condition:
        $iac_sb_linemode and ($slc_flood or 1 of ($shell*, $reverse*, $bindshell))
}

Immediate Mitigation

There is no patch available as of March 18, 2026. The following mitigations should be applied immediately:

1. Disable Telnet Entirely (Strongest Control)

# Stop and disable telnetd
sudo systemctl stop inetutils-telnetd 2>/dev/null
sudo systemctl disable inetutils-telnetd 2>/dev/null

# If running under xinetd
sudo sed -i 's/disable.*= no/disable = yes/' /etc/xinetd.d/telnet
sudo systemctl restart xinetd

# If running under inetd
sudo sed -i 's/^telnet/#telnet/' /etc/inetd.conf
sudo systemctl restart inetd

# Verify Telnet is no longer listening
ss -tlnp | grep ':23' && echo "WARNING: Telnet still active" || echo "OK: Port 23 is closed"

2. Block Port 23 at the Firewall

# iptables
sudo iptables -A INPUT -p tcp --dport 23 -j DROP
sudo ip6tables -A INPUT -p tcp --dport 23 -j DROP

# nftables
sudo nft add rule inet filter input tcp dport 23 drop

# firewalld
sudo firewall-cmd --permanent --remove-service=telnet
sudo firewall-cmd --reload

# UFW
sudo ufw deny 23/tcp

3. Run telnetd Without Root Privileges (If Telnet Cannot Be Disabled)

For environments where Telnet is operationally required (legacy systems, embedded devices):

# Run telnetd as unprivileged user via xinetd
# /etc/xinetd.d/telnet
service telnet
{
    disable         = no
    socket_type     = stream
    protocol        = tcp
    user            = telnetd      # NOT root
    server          = /usr/sbin/in.telnetd
    server_args     = -L /usr/sbin/login
    only_from       = 10.0.0.0/8   # Restrict to internal network
    no_access       = 0.0.0.0/0    # Block all external
}

Note: Running telnetd without root prevents the attacker from gaining root-level code execution, but the overflow itself is still exploitable. This reduces impact severity but does not eliminate the vulnerability.

4. Network Segmentation and Access Control

Telnet Access Restrictions:
  - Never expose port 23 to the internet — under ANY circumstances
  - Isolate Telnet-dependent devices on a dedicated management VLAN
  - Require VPN or jump host for Telnet access to legacy systems
  - Implement network ACLs restricting port 23 to specific management IPs
  - Deploy IDS/IPS with the Snort/Suricata rule above on all segments with Telnet

5. Migrate to SSH

The definitive fix is to replace Telnet with SSH for all remote management:

# Install OpenSSH server
sudo apt install openssh-server    # Debian/Ubuntu
sudo dnf install openssh-server    # RHEL/Fedora

# Enable and start
sudo systemctl enable --now sshd

# Disable password auth, enforce key-based
sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd

SSH provides encrypted transport, public key authentication, and a significantly smaller attack surface compared to the 40-year-old Telnet protocol.

Key Takeaways

• CVE-2026-32746 is a pre-auth root RCE with no patch. A single crafted packet to port 23 during the Telnet handshake gives an attacker root access. No credentials, no user interaction, no complexity.
• This is the second CVSS 9.8 telnetd flaw in 2026. CVE-2026-24061 (authentication bypass) is already under active exploitation per CISA. The attack surface overlap means organizations that didn't patch the first flaw are vulnerable to both.
• Telnet should not exist on any production network in 2026. The protocol transmits credentials in plaintext and has now demonstrated two independent pre-auth RCE vectors in the same codebase within two months. There is no defensible reason to run it when SSH is universally available.
• Embedded and IoT devices are at highest risk. Many routers, switches, and OT devices still expose Telnet for management. These devices often cannot be easily patched and may remain vulnerable indefinitely.
• Block port 23 at every perimeter and internal boundary. Even if you believe Telnet is not in use, verify with a port scan. Shadow IT and forgotten legacy devices are common sources of unmanaged Telnet exposure.

A patch is expected by April 1, 2026. Until then, organizations must disable telnetd or strictly limit access to port 23 via firewall rules and network segmentation. Monitor CISA's KEV catalog for any addition of CVE-2026-32746, which would indicate confirmed active exploitation.