telnetd in GNU inetutils through 2.7

CVE-2026-32746 is a BSS-based buffer overflow in the LINEMODE SLC suboption handler of GNU inetutils telnetd, affecting all versions through 2.7. The vulnerable add_slc() function in telnetd/slc.c writes 3-byte SLC triplets into a fixed 0x6C-byte (108-byte) buffer with zero bounds checking. An unauthenticated attacker on port 23 can send a crafted subnegotiation packet during option negotiation — before any login prompt — to corrupt ~400 bytes of adjacent BSS variables, including a pointer (slcptr / def_slcbuf) later passed to free(). Because telnetd typically runs as root, successful exploitation yields full system compromise. Affected platforms span Debian, Ubuntu, FreeBSD, NetBSD, macOS, Citrix NetScaler, TrueNAS Core, DragonFlyBSD, and embedded Linux distributions.

The vendor CVSS 9.8 treats this as trivially exploitable (AC:L), but that overstates real-world risk significantly. The watchtowr/DREAM research team who discovered the bug explicitly stated they *"didn't find a direct route to exploitation on any of the systems we observed"* on modern 64-bit distributions. On 64-bit x86, pointer alignment constraints and NULL bytes in addresses make the overflow extremely difficult to weaponize. On 32-bit targets exploitation is more feasible, but modern heap hardening (glibc chunk validation) still blocks naive approaches. Public PoCs achieve crash and pointer-leak primitives — not reliable RCE. Meanwhile, telnet itself is a legacy protocol with a tiny internet footprint (~3,362 exposed hosts per Censys). The 9.8 is defensible on paper but misleading for anyone managing a modern fleet.

Why this verdict

• Exploitation gap: The vendor CVSS assumes AC:L but the researchers who discovered the bug could not achieve RCE on any modern 64-bit system. Public PoCs achieve crash and pointer leaks only. This is a significant downward pressure — the theoretical worst-case is not the practical reality.
• Tiny exposure population: Only ~3,362 internet-facing hosts per Censys. In a typical 10,000-host enterprise, telnetd is likely running on zero to single-digit hosts. The protocol has been deprecated in favor of SSH for over two decades.
• Modern mitigations compound: ASLR, glibc safe-unlinking, and 64-bit pointer alignment each independently raise the exploitation bar. Combined, they make reliable weaponization a research-grade challenge, not a script-kiddie exercise.
• Role multiplier: telnetd can run on (a) *low-value:* dev boxes, lab systems — crash only, no RCE, minimal impact; (b) *typical:* legacy servers with telnet for management — crash = DoS, no proven RCE; (c) *high-value:* Citrix NetScaler (network edge appliance), embedded OT/ICS devices, TrueNAS (storage). On NetScaler, telnet is management-plane access typically restricted to internal/OOB networks — not data-plane exposed. On 32-bit embedded/OT devices, exploitation is more plausible and blast radius could be operational/safety-impacting, but these represent a minority of the GNU inetutils installed base. The high-value role outcome (network appliance compromise) is plausible on 32-bit embedded targets, which floors the verdict at HIGH. It does not reach CRITICAL because telnetd is not canonically a high-value-role component — it is a deprecated utility that happens to ship on some appliances.
• No active exploitation: Not on CISA KEV, no attributed campaigns, no ransomware adoption. EPSS at 23.7th percentile reflects moderate — not urgent — exploitation probability.

Why not higher?

A CRITICAL rating would require either proven reliable RCE on modern systems or active in-the-wild exploitation, and this CVE has neither. The discovering researchers themselves could not complete the exploitation chain on 64-bit, which directly contradicts the AC:L assumption underpinning the 9.8 score. The internet-facing exposure of ~3,362 hosts is far too small to justify fleet-wide emergency response.

Why not lower?

The vulnerability is pre-authentication, requires no user interaction, and targets a service that runs as root. On 32-bit embedded targets (network appliances, OT/ICS devices, TrueNAS), exploitation is more feasible and the blast radius includes network edge compromise. Public PoCs exist and lower the barrier for further research. A MEDIUM rating would understate the risk to organizations with legacy telnet-enabled infrastructure or embedded appliances.

1. Disable telnetd immediately on all systems where it is not business-critical — The most effective mitigation is eliminating the attack surface entirely. Run systemctl disable --now telnetd.socket or remove from /etc/inetd.conf. For any enterprise in 2026, SSH should be the only remote shell protocol. Deploy within the noisgate mitigation SLA of 30 days for HIGH.
2. Firewall port 23 at the perimeter and internal segment boundaries — If telnetd cannot be disabled (legacy systems, OT devices), restrict port 23 access to specific management VLANs and jump hosts via ACLs. No internet-facing telnet should exist. Implement within 30 days.
3. Apply the upstream patch commit manually where vendor packages are unavailable — Cherry-pick commit 6864598a from the inetutils repository and rebuild the package. Debian unstable users can upgrade to 2:2.7-4. OpenEmbedded backports exist for 2.5–2.7. This is the definitive fix.
4. Deploy IDS/IPS signatures for CVE-2026-32746 — Suricata ET Open and Snort signatures detect the anomalous LINEMODE SLC subnegotiation pattern. This provides detection-in-depth for hosts where telnetd must remain running. Tune to alert-and-block mode.
5. Migrate legacy telnet consumers to SSH — Identify all systems and automation scripts using telnet for management and migrate them to SSH with key-based authentication. This is the long-term remediation that eliminates the entire class of telnet vulnerabilities.

Run this script on each target host where telnetd may be installed. No special privileges required — it checks the installed package version. Example: chmod +x check_cve_2026_32746.sh && ./check_cve_2026_32746.sh

#!/usr/bin/env bash
# CVE-2026-32746 Checker — GNU inetutils telnetd BSS overflow
# Checks: (1) whether telnetd is installed, (2) version, (3) whether service is active
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

RED='\033[0;31m'; GREEN='\033[0;32m'; YELLOW='\033[1;33m'; NC='\033[0m'

# Check if telnetd binary exists
TELNETD_BIN=$(command -v in.telnetd 2>/dev/null || command -v telnetd 2>/dev/null || true)

if [[ -z "$TELNETD_BIN" ]]; then
    # Check if package is installed even if binary not in PATH
    if dpkg -l inetutils-telnetd 2>/dev/null | grep -q '^ii'; then
        TELNETD_BIN=$(dpkg -L inetutils-telnetd 2>/dev/null | grep telnetd$ | head -1)
    elif rpm -q inetutils 2>/dev/null | grep -q inetutils; then
        TELNETD_BIN=$(rpm -ql inetutils 2>/dev/null | grep telnetd$ | head -1)
    fi
fi

if [[ -z "$TELNETD_BIN" ]]; then
    echo -e "${GREEN}[PATCHED]${NC} telnetd is not installed on this system. Not affected."
    exit 0
fi

echo "[*] Found telnetd binary: $TELNETD_BIN"

# Check if service is actively listening
LISTENING=false
if ss -tlnp 2>/dev/null | grep -q ':23 '; then
    LISTENING=true
    echo -e "${RED}[!] telnetd is ACTIVELY LISTENING on port 23${NC}"
elif netstat -tlnp 2>/dev/null | grep -q ':23 '; then
    LISTENING=true
    echo -e "${RED}[!] telnetd is ACTIVELY LISTENING on port 23${NC}"
else
    echo "[*] telnetd is installed but NOT currently listening on port 23"
fi

# Attempt version detection
VERSION=""
if dpkg -l inetutils-telnetd 2>/dev/null | grep -q '^ii'; then
    PKG_VER=$(dpkg -l inetutils-telnetd 2>/dev/null | awk '/^ii/{print $3}')
    echo "[*] Debian package version: $PKG_VER"
    # Debian patched version is 2:2.7-4 or later
    if dpkg --compare-versions "$PKG_VER" ge "2:2.7-4" 2>/dev/null; then
        echo -e "${GREEN}[PATCHED]${NC} Installed version ($PKG_VER) contains the fix for CVE-2026-32746."
        exit 0
    else
        echo -e "${RED}[VULNERABLE]${NC} Installed version ($PKG_VER) is affected by CVE-2026-32746."
        if $LISTENING; then
            echo -e "${RED}[CRITICAL] Service is actively listening — immediate action required.${NC}"
        fi
        exit 1
    fi
elif rpm -q inetutils 2>/dev/null | grep -q inetutils; then
    RPM_VER=$(rpm -q inetutils 2>/dev/null)
    echo "[*] RPM package: $RPM_VER"
    echo -e "${YELLOW}[UNKNOWN]${NC} Cannot determine patch status for RPM-based install. Check vendor advisory."
    exit 2
fi

# Fallback: check binary for patched signature via strings
if strings "$TELNETD_BIN" 2>/dev/null | grep -q 'slcbuf.*bound\|SLC_MAX_TRIPLETS'; then
    echo -e "${GREEN}[PATCHED]${NC} Binary appears to contain bounds-checking fix."
    exit 0
fi

# If we got here, telnetd is installed but we can't confirm patch status
if $LISTENING; then
    echo -e "${RED}[VULNERABLE]${NC} telnetd is installed and listening. Assume vulnerable (inetutils <= 2.7)."
    exit 1
else
    echo -e "${YELLOW}[UNKNOWN]${NC} telnetd is installed but not listening. Cannot confirm patch status. Verify manually."
    exit 2
fi

Sources

1. watchtowr Labs — Full Technical Writeup
2. Censys Advisory — Exposure Data
3. The Hacker News — CVE-2026-32746 Coverage
4. ExploitDB — PoC #52556
5. Debian Security Tracker
6. CyCognito — Emerging Threat Analysis
7. GNU bug-inetutils Mailing List — Original Report
8. NVD Entry