Critical Telnet Vulnerability Grants Root Access - CVE-2026-24061

A critical vulnerability discovered in GNU InetUtils telnetd (CVE-2026-24061) is being actively exploited in the wild. The flaw, which has existed undetected for 11 years, allows remote attackers to completely bypass authentication and gain root access to affected systems with a single command.

If you have telnet enabled on any systems, disable it immediately and switch to SSH.

Vulnerability Overview

How the Exploit Works

The vulnerability exploits how telnetd handles environment variables during connection negotiation. When a client connects, telnet's NEW-ENVIRON mechanism (RFC 1572) allows passing environment variables to the server.

The flaw occurs because telnetd passes the USER environment variable directly to the system's login program without sanitization. An attacker can set:

USER=-f root

The -f flag tells the login program to skip authentication for the specified user - in this case, root. The login program interprets this as "this user is already authenticated," granting immediate root shell access.

According to Rapid7's Stephen Fewer: "Exploiting this vulnerability is straightforward: simply running a specific telnet command to connect to a remote server can trigger the issue and grant an attacker root access."

Who Is Affected

Systems running GNU InetUtils telnetd version 2.7 or earlier are vulnerable. This includes:

• Debian and derivatives (Ubuntu, Kali Linux, etc.)
• Trisquel
• Many embedded systems and IoT devices using telnet for management
• Legacy servers still using telnet for remote access
• Network equipment with telnet enabled

A Shodan search found over 214,000 internet-exposed hosts responding to telnet, with the highest concentrations in China, Brazil, Canada, Argentina, and the United States.

Active Exploitation

This vulnerability is being actively exploited. Security researchers have observed:

• Over 20 unique IP addresses attempting exploitation within 24 hours of disclosure
• Three distinct attack waves since January 22, 2026
• Attacks have evolved from probing to active weaponization
• Proof-of-concept exploit code is publicly available on GitHub

How to Check If You're Vulnerable

Check if telnetd is running:

# Check for running telnet daemon
ps aux | grep telnetd

# Check if telnet port (23) is listening
netstat -tlnp | grep :23
# or
ss -tlnp | grep :23

Check your inetutils version:

# Debian/Ubuntu
dpkg -l | grep inetutils

# Check telnetd version directly
telnetd --version

Immediate Mitigation Steps

1. Disable Telnet Immediately

The safest action is to disable telnetd entirely:

# Stop the service
sudo systemctl stop inetutils-telnetd
sudo systemctl disable inetutils-telnetd

# Or if using inetd/xinetd, comment out telnet in config
sudo nano /etc/inetd.conf
# Comment out the telnet line

# Restart inetd
sudo systemctl restart inetd

2. Block Port 23 at the Firewall

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

# Using ufw (Ubuntu)
sudo ufw deny 23/tcp

3. Switch to SSH

SSH provides encrypted, secure remote access and should replace telnet in all cases:

# Install OpenSSH server if not present
sudo apt install openssh-server

# Enable and start SSH
sudo systemctl enable ssh
sudo systemctl start ssh

4. Update If You Must Keep Telnet

If you absolutely cannot disable telnet (legacy systems, specific requirements), update to a patched version of GNU inetutils when available, and restrict access to trusted IPs only:

# Restrict telnet to specific IP (example using iptables)
sudo iptables -A INPUT -p tcp --dport 23 -s 192.168.1.100 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 23 -j DROP

Why Telnet Should Have Been Retired Long Ago

This vulnerability is a reminder of why telnet should not be used:

• No encryption: All traffic, including passwords, is sent in plain text
• No integrity checking: Traffic can be modified in transit
• Legacy codebase: Old code with potential undiscovered vulnerabilities
• Better alternatives exist: SSH has been the standard for secure remote access for over 25 years

For Network Administrators

Scan your network for exposed telnet services:

# Using nmap to find telnet servers on your network
nmap -p 23 --open 192.168.1.0/24

Check firewall logs for exploitation attempts targeting port 23, especially connections with unusual USER environment variables.

Timeline

• May 2015: Vulnerability introduced in GNU inetutils
• January 19, 2026: Discovered by security researcher Kyu Neushwaistein (Carlos Cortes Alvarez)
• January 20, 2026: CVE-2026-24061 assigned
• January 22, 2026: First exploitation attempts observed
• January 25, 2026: Over 214,000 exposed hosts identified via Shodan

Need Help Securing Your Systems?

If you're unsure whether your organization has telnet exposed or need assistance migrating to secure alternatives, contact TechNet New England. We can help audit your systems, disable legacy services, and implement secure remote access solutions.