GNU InetUtils telnetd through version 2.7 contains an authentication bypass that gives an unauthenticated remote attacker a root shell in a single command. NIST scored it 9.8 Critical. CISA added it to the Known Exploited Vulnerabilities catalog on January 26, 2026. Active exploitation was confirmed before the advisory was public. If you're running GNU InetUtils telnetd anywhere — patch to 2.7-2, or turn it off.
The vulnerability
CVE: CVE-2026-24061
CVSS: 9.8 Critical
Affected: GNU InetUtils telnetd ≤ 2.7
Fixed in: inetutils 2.7-2
Attack vector: Network — no authentication, no user interaction required
The flaw is argument injection. During telnet option negotiation, telnetd reads the USER environment variable and constructs a call to the system's login(1) binary by appending USER directly to the command line. There is no validation that USER contains a valid username, or that it doesn't contain flags.
Set USER to -f root before connecting:
USER="-f root" telnet -a [target]
telnetd builds this:
login -h [hostname] -f root
The -f flag in login(1) signals that the specified user is pre-authenticated — skip the password check. It exists for legitimate callers (display managers, PAM modules) that have already verified the user through another path. telnetd is not a legitimate caller. It just passes along whatever value the client supplied.
The injection chain:
Attacker supplies: USER = "-f root"
│
telnetd constructs: login -h [host] -f root
│
login reads -f: "pre-authenticated — skip credentials"
│
Root shell granted, no password required
SafeBreach's root cause analysis traced this to 2015 in the GNU InetUtils codebase.
Affected systems
GNU InetUtils is the telnetd implementation bundled with Debian, Ubuntu, and many derivative distributions. It is not a niche or standalone package — it comes along for the ride in a large number of standard Linux installations. Shodan data compiled by CyCognito shows approximately 1 million devices currently listening on port 23, with around 212,000 actively serving telnet sessions.
Telnet persists in production for a few predictable reasons: legacy IoT and embedded devices that shipped with telnet as the management interface and have no firmware update path; end-of-life network appliances where SSH cipher negotiation breaks with modern clients; OT and ICS environments that chose telnet for latency determinism and never revisited the decision. Notably, telnet usage has reportedly been increasing in some government and enterprise networks despite NIST guidance against it.
Any system running GNU InetUtils telnetd through version 2.7 with port 23 reachable from untrusted networks is directly exploitable.
Exploitation status
GreyNoise documented 18–21 unique IP addresses running automated exploitation scans within 24 hours of the January 20 advisory. Attack traffic originated from Hong Kong, the US, Japan, the Netherlands, China, Germany, Singapore, and Thailand. 83% of observed attempts targeted root specifically. The campaign peaked at approximately 2,600 sessions per day in early February 2026. Threat group 'rwxrwx' was confirmed among the active actors.
GreyNoise telemetry also recorded a 59% drop in global telnet traffic on January 14 — six days before public disclosure — with 18 ASNs going silent and five countries disappearing from the data. This is consistent with pre-disclosure exploitation activity: attackers who had already discovered the flaw taking compromised systems off the telnet grid before defenders had a CVE number to act on.
For context on how this pattern repeats across infrastructure software, the Fortinet SSO bypass from earlier this year followed the same profile: critical authentication bypass, exploited before broad awareness, in infrastructure organizations assumed was secured.
Mitigation
Step 1 — Check if you're exposed
Confirm whether GNU InetUtils telnetd is running:
# Look for an active telnetd process
ps aux | grep telnetd
# Confirm whether anything is listening on port 23
ss -tlnp | grep :23
If either returns a real result (not just the grep process itself), act now.
Step 2a — Patch
Upgrade to inetutils 2.7-2, which contains the fix. On Debian/Ubuntu:
sudo apt-get update && sudo apt-get install inetutils-telnetd
Verify the installed version:
dpkg -l inetutils-telnetd
Look for 2.7-2 or later in the version column. If your package manager returns something older, your distribution may not have backported the patch yet — check your distro's security advisories and consider whether you're on a supported release.
Step 2b — Disable (recommended if telnet is not operationally required)
If you cannot name a specific current reason telnet needs to be running, the right call is to turn it off. SSH handles every remote shell use case with actual encryption and modern authentication.
On systemd-based systems:
sudo systemctl disable --now telnetd
If telnetd is managed through inetd or xinetd:
# For inetd — comment out or remove the telnet line in /etc/inetd.conf, then:
sudo systemctl restart inetd
# For xinetd — remove or disable /etc/xinetd.d/telnet, then:
sudo systemctl restart xinetd
After disabling, re-run the ss check above to confirm port 23 is no longer listening. For environments thinking through the broader shift from telnet to encrypted remote access protocols, this comparison of overlay networks and traditional VPN/tunnel approaches is a useful reference.
