← Back to Feed CACHED · 2026-09-25 03:51:48 · CACHE_KEY tenable:42263
tenable:42263 · CWE-319

Unencrypted Telnet Server

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Leaving your front door wide open in a neighborhood where burglars carry master keys

Tenable plugin 42263 detects any host running a Telnet server that transmits traffic — including authentication credentials, commands, and session data — in cleartext over TCP/23. This is not a specific CVE but an architectural weakness classified under CWE-319 (Cleartext Transmission of Sensitive Information). Every version of every Telnet daemon is affected by definition; the protocol has no native encryption. Tenable assigns CVSS v3 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) and labels the finding MEDIUM.

The vendor MEDIUM is defensible in a vacuum — credential interception *does* require a man-in-the-middle position. But that framing ignores 2026 reality. Shodan shows 800K–1.2M internet-exposed Telnet services. GreyNoise observed an average of ~914,000 daily non-spoofable Telnet scan sessions before the January 2026 traffic anomaly. Mirai-family malware accounts for ~40% of all IoT malware payloads (Zscaler 2025), with Telnet credential brute-force as the primary propagation vector. Worse, running any telnetd in 2026 also exposes you to daemon-level bugs: CVE-2026-24061 (GNU inetutils auth bypass, KEV-listed Jan 26 2026) and CVE-2026-32746 (pre-auth RCE as root). The MEDIUM label treats this as a theoretical eavesdropping risk; the ground truth is that Telnet-enabled hosts face continuous automated attack and compound vulnerability exposure.

"Telnet in 2026 is a standing invitation: cleartext creds, botnet fodder, and a magnet for daemon-level RCE."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Service discovery

Attacker scans TCP/23 using masscan, Shodan, or Censys. Telnet banners are trivially fingerprinted — most daemons announce their OS, hostname, and login prompt in cleartext. No authentication or interaction is needed to confirm the service exists.
Conditions required:
  • Target host has TCP/23 open and reachable
Where this breaks in practice:
  • If Telnet is internal-only and behind a firewall, external discovery requires prior network access
Detection/coverage: Any vulnerability scanner (Nessus plugin 42263, Qualys QID 38118, Rapid7) flags this. Shodan/Censys provide passive exposure monitoring.
STEP 02

Credential brute-force (direct path)

Attacker launches automated credential stuffing against the Telnet login prompt using tools like Hydra, Medusa, or Mirai-family scanners. Default/factory credentials for IoT, network gear, and legacy systems are compiled in well-known wordlists (e.g., mirai-botnet/passwords.txt). Many embedded devices ship with admin/admin, root/root, or blank passwords.
Conditions required:
  • Telnet service accepts password-based authentication
  • Target uses weak, default, or guessable credentials
Where this breaks in practice:
  • Hosts with strong, unique passwords resist brute-force
  • Account lockout policies (rare on embedded/OT devices) slow attacks
Detection/coverage: IDS/IPS rules for Telnet brute-force (Suricata SID 2001219). SIEM correlation on repeated auth failures on port 23. GreyNoise tags for Telnet scanners.
STEP 03

Credential interception (MitM path)

If a legitimate admin sessions into the Telnet host, an attacker with network adjacency can passively capture the full session using Wireshark, tcpdump, or Ettercap. ARP spoofing (arpspoof, bettercap) or DHCP spoofing positions the attacker inline. All keystrokes, credentials, and command output are visible in the packet capture — zero cryptographic protection.
Conditions required:
  • Attacker has Layer 2 adjacency or controls a network tap/span port
  • A legitimate user actively logs in via Telnet during the capture window
Where this breaks in practice:
  • Requires internal network position — implies post-initial-access for external attackers
  • Modern switched networks require active ARP poisoning, which 802.1X and DAI can mitigate
  • Timing dependency: attacker must be capturing while a real session occurs
Detection/coverage: ARP spoofing detection (Dynamic ARP Inspection). Network anomaly detection for unexpected ARP traffic. Passive DNS/NetFlow analysis.
STEP 04

Authenticated command execution

With valid credentials obtained from step 2 or 3, the attacker has an interactive shell on the target. On Linux/Unix hosts, this is typically a full shell as the authenticated user. On network equipment (Cisco IOS, Juniper JUNOS), this is the CLI with the privilege level of the captured account. On OT/ICS controllers, this may provide direct process control.
Conditions required:
  • Valid credentials obtained
  • Telnet service grants shell or CLI access
Where this breaks in practice:
  • Privilege level depends on the captured account — may need privilege escalation for full impact
Detection/coverage: Session logging (if enabled). Anomalous login time/source IP detection. SIEM correlation on Telnet auth events.
STEP 05

Lateral movement or fleet impact

Captured credentials are reused across the environment — credential reuse is endemic in network equipment and OT environments. On network gear, the attacker reconfigures ACLs, mirrors traffic, or pivots deeper. On OT, the attacker manipulates process variables. On servers, the attacker harvests additional credentials, deploys persistence, or joins the host to a botnet (Mirai, Tengu, Aisuru).
Conditions required:
  • Credential reuse across multiple hosts
  • Compromised host has network adjacency to additional targets
Where this breaks in practice:
  • Segmented networks limit lateral movement
  • Unique credentials per device prevent credential reuse pivots
Detection/coverage: Behavioral analytics on lateral Telnet connections. NetFlow analysis for unusual port-23 traffic patterns between internal hosts.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationActive and continuous. Mirai-family botnets use Telnet brute-force as their *primary* propagation vector, accounting for ~40% of all IoT malware (Zscaler 2025). The Tengu botnet (July 2026) and Aisuru botnet (29.7 Tbps DDoS, 2025) both propagate via Telnet credential brute-force. GreyNoise observed ~914K daily Telnet scan sessions before the Jan 2026 anomaly.
Related CVEs (Daemon-Level)CVE-2026-24061 — GNU inetutils telnetd authentication bypass via -f USER variable tampering (CVSS 9.8, KEV-listed 2026-01-26). CVE-2026-32746 — GNU inetutils telnetd pre-auth RCE (CVSS 9.8, disclosed March 2026). Running *any* telnetd compounds this finding with daemon-level RCE risk.
PoC / Exploit AvailabilityNo PoC needed — Telnet cleartext is by design. For brute-force: Hydra, Medusa, Ncrack, Mirai scanner source code (public since 2016). For MitM: Ettercap, bettercap, Wireshark. For CVE-2026-24061: sa7bnb/Telnet-Security-Scanner-Port-23.
EPSSN/A — this is a protocol-level weakness (no CVE), not scored by EPSS. However, associated daemon CVEs (CVE-2026-24061) have EPSS in the 97th+ percentile.
CISA KEVThe cleartext issue itself is not KEV-listed (no CVE). CVE-2026-24061 was added to KEV on 2026-01-26, directly affecting hosts running telnetd.
CVSS Vector (Tenable)CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N → 6.5 MEDIUM. The C:L/I:L underscores the vendor's framing as eavesdropping risk. In practice, captured admin credentials yield C:H/I:H outcomes on infrastructure targets.
Affected VersionsAll versions of all Telnet server implementations, by protocol design. Includes: GNU inetutils telnetd, BusyBox telnetd, utelnetd, BSD telnetd, Windows Telnet Server, Cisco IOS/NX-OS Telnet, and embedded firmware telnet daemons.
Fix / MitigationDisable Telnet; use SSH. No patch can fix the protocol — encryption is not part of the Telnet specification (RFC 854). For devices that only support Telnet, wrap in a VPN or SSH tunnel. Cisco: no service telnet or transport input ssh. Linux: systemctl disable telnet.socket.
Exposure DataShodan: ~1.2M hosts with port 23 open; ~800K confirmed Telnet service banners. Censys: ~1M devices on port 23. The January 2026 GreyNoise anomaly saw scanning drop 59% in one hour (from ~74K to ~11K sessions/hr), possibly linked to ISP-level filtering.
Disclosure / AgeTelnet's cleartext nature has been a known weakness since the protocol's creation in 1969 (RFC 15). SSH was created in 1995 specifically to replace it. This is a 57-year-old known issue. Tenable plugin 42263 has been active since 2009-10-27.

Sources.

  1. Tenable Plugin 42263 — Unencrypted Telnet Server
  2. GreyNoise Labs — The Day Telnet Died (Jan 2026 Traffic Anomaly)
  3. GreyNoise Labs — 18 Hours of Unsolicited Telnet Houseguests
  4. rConfig — Nearly 800,000 Exposed Telnet Servers
  5. PortVigil — Hidden Risks of FTP and Telnet Ports in 2026
  6. MITRE CWE-319 — Cleartext Transmission of Sensitive Information
  7. Stingrai — IoT Attack Statistics 2026: Botnets and OT Risks
  8. CISA KEV Catalog
04 · The Call

Final Verdict
↑ UPGRADED to HIGH (7.5/10)

Why this verdict

  • Active mass exploitation: Telnet brute-force is the #1 propagation vector for IoT/OT botnets in 2025–2026. Mirai-family malware alone accounts for ~40% of IoT malware payloads. GreyNoise observed ~914K daily scan sessions targeting port 23. This is not theoretical — it is the most actively exploited cleartext protocol on the internet.
  • Compound daemon risk: Running Telnet in 2026 doesn't just expose you to credential sniffing — it exposes you to CVE-2026-24061 (auth bypass, KEV-listed) and CVE-2026-32746 (pre-auth RCE as root). The act of having telnetd running is itself a critical attack surface beyond the cleartext issue.
  • Role multiplier: Telnet in 2026 disproportionately survives on high-value-role infrastructure: (a) *Network edge appliances* — Cisco IOS, Juniper, legacy switches/routers where Telnet is often the only management protocol. Captured credentials yield ACL changes, traffic mirroring, and network-wide pivot capability. Blast radius: fleet-scale. Chain succeeds: yes, brute-force path has near-zero friction on devices with default/factory creds. (b) *OT/ICS/SCADA controllers* — PLCs, HMIs, and RTUs from Schneider, Siemens, Rockwell where Telnet is hardwired into firmware. Blast radius: safety/operational impact. Chain succeeds: yes, many OT devices lack account lockout or strong auth. (c) *IoT devices* — cameras, printers, embedded Linux. Blast radius: botnet recruitment (Aisuru produced 29.7 Tbps DDoS). These high-value roles represent a majority of the remaining Telnet installed base — consumer/enterprise IT has largely migrated to SSH. The floor is HIGH.
  • Massive exposure surface: 800K–1.2M internet-facing Telnet services per Shodan/Censys. The brute-force path against internet-exposed instances has zero friction — no authentication bypass needed, just default credential lists.
  • MitM friction is real but not dispositive: The credential interception path requires Layer 2 adjacency, which is genuine friction for external attackers. This prevents the upgrade from reaching CRITICAL for the cleartext finding alone. But the brute-force path bypasses this requirement entirely.

Why not higher?

The cleartext *interception* path (MitM) requires internal network position and active session timing — real friction that limits the eavesdropping scenario. The finding itself is an architectural weakness, not a directly weaponizable exploit with guaranteed RCE. The daemon-level CVEs (which *would* justify CRITICAL) are separate findings. For a generic IT server on an internal network with strong unique passwords and no internet exposure, the realistic risk from this finding alone is moderate.

Why not lower?

Telnet hosts face continuous automated attack — ~914K daily scan sessions observed by GreyNoise. The brute-force path on internet-exposed or poorly-credentialed hosts has near-zero friction. The affected installed base is heavily concentrated in high-value roles (network infrastructure, OT/ICS) where compromise yields fleet-scale or safety-impacting outcomes. Two KEV-listed daemon CVEs in 2026 alone demonstrate that the attack surface of running telnetd extends far beyond cleartext — MEDIUM does not capture compound risk.

05 · Compensating Control

1
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Disable Telnet and enable SSH on all capable devices — The only real fix. On Cisco IOS: line vty 0 15 → transport input ssh. On Linux: systemctl disable telnet.socket && systemctl stop telnet.socket. On Windows: Disable-WindowsOptionalFeature -Online -FeatureName TelnetServer. This is a HIGH finding under the noisgate mitigation SLA — deploy within 30 days. Eliminates the entire attack surface: cleartext exposure, brute-force vector, and daemon-level CVE exposure.
2
HIGH 7.5→MEDIUM 5.5
SEVERITY REDUCED
Block TCP/23 at the perimeter firewall immediately — If you cannot disable Telnet today, ensure it is not internet-reachable. Add explicit deny rules for inbound TCP/23 on all perimeter firewalls and cloud security groups. Verify with external scan. This eliminates the zero-friction brute-force path from the internet but does NOT protect against internal MitM or lateral movement. Deploy within 48 hours as an emergency compensating control.
3
HIGH 7.5→MEDIUM 4.5
SEVERITY REDUCED
Wrap Telnet in an SSH tunnel or VPN for devices that lack SSH support — For legacy network gear and OT devices where Telnet cannot be disabled, require all management access through an SSH jump host or site-to-site VPN. This encrypts the transport layer retroactively. Use ssh -L 2323:target:23 jumphost for ad hoc tunneling. Adds encryption but does not eliminate the daemon attack surface.
4
HIGH 7.5→MEDIUM 5.0
SEVERITY REDUCED
Enforce unique, strong credentials on all Telnet-accessible devices — Change all default and factory credentials immediately. Use a PAM/credential vault to generate and rotate unique passwords per device. This breaks the brute-force path but does NOT prevent cleartext credential capture via MitM. Prioritize network equipment and OT controllers.
5
HIGH 7.5→MEDIUM 5.0
SEVERITY REDUCED
Enable Dynamic ARP Inspection (DAI) and 802.1X on network segments with Telnet hosts — DAI prevents ARP spoofing, which is the primary technique for positioning a MitM on switched networks. 802.1X ensures only authorized devices connect to the segment. Together they significantly raise the bar for the credential interception attack path.
What doesn't work
  • Network segmentation alone — Segmenting Telnet hosts into a management VLAN does not encrypt the traffic. An attacker who compromises any device on that VLAN can still sniff credentials. Segmentation reduces exposure but does not eliminate the vulnerability.
  • IDS/IPS signatures for Telnet brute-force — These detect attacks but do not prevent credential capture from successful logins. Alert fatigue from the massive volume of Telnet scanning (~914K daily sessions) makes these rules noisy without automated response.
  • Changing the Telnet port from 23 to a non-standard port — Security through obscurity. Scanners like masscan and Shodan discover services on all ports. Mirai variants scan non-standard ports. The traffic is still cleartext regardless of port number.
06 · Verification

Crowdsourced verification payload.

Run this script on each target host or from a network auditor workstation with nmap installed. Invoke as: bash check_telnet.sh 192.168.1.1 or with a subnet: bash check_telnet.sh 10.0.0.0/24. Requires no special privileges for remote checks. For local daemon checks, run as root.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_telnet.sh — Detect unencrypted Telnet service (Tenable 42263)
# Usage: bash check_telnet.sh <target_ip_or_cidr>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <target_ip_or_cidr>"
  exit 2
fi

# --- Local check (if running on the target itself) ---
if [[ "$TARGET" == "localhost" || "$TARGET" == "127.0.0.1" ]]; then
  # Check for listening telnet daemon
  if ss -tlnp 2>/dev/null | grep -qE ':23\b'; then
    echo "VULNERABLE — Telnet daemon listening on port 23 (local check)"
    # Identify the process
    ss -tlnp | grep -E ':23\b'
    exit 1
  elif systemctl is-active telnet.socket &>/dev/null; then
    echo "VULNERABLE — telnet.socket is active (systemd socket activation)"
    exit 1
  else
    echo "PATCHED — No Telnet service detected locally"
    exit 0
  fi
fi

# --- Remote check via nmap ---
if ! command -v nmap &>/dev/null; then
  echo "UNKNOWN — nmap not installed; install it or use local check mode"
  exit 2
fi

echo "[*] Scanning $TARGET for Telnet (TCP/23)..."
RESULT=$(nmap -Pn -sV -p 23 --open -oG - "$TARGET" 2>/dev/null)

if echo "$RESULT" | grep -q '23/open'; then
  HOSTS=$(echo "$RESULT" | grep '23/open' | awk '{print $2}')
  echo "VULNERABLE — Unencrypted Telnet detected on:"
  for h in $HOSTS; do
    echo "  - $h:23"
  done
  echo ""
  echo "Recommendation: Disable Telnet, enable SSH."
  exit 1
else
  echo "PATCHED — No open Telnet service found on $TARGET"
  exit 0
fi
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously