A decade-old authentication bypass buried in GNU InetUtils telnetd has come back to bite defenders in 2026. Tracked as CVE-2026-24061, the flaw lets any unauthenticated attacker drop straight into a root shell on a vulnerable host with one command — no password, no user interaction, no multi-stage chain. With more than 200,000 Telnet servers reachable on the public internet and CISA reporting active in-the-wild abuse, anyone still running legacy telnetd should treat this as an emergency.
Vulnerability overview
CVE-2026-24061 is a critical authentication bypass in GNU InetUtils telnetd, affecting versions 1.9.3 through 2.7-2. The root cause traces back to a 2015 commit that added a %U placeholder to the template telnetd uses to build the login command line. That placeholder is filled directly from the attacker-controlled USER environment variable — with no sanitization whatsoever — allowing arbitrary command-line flags to be injected into the login subprocess and authentication to be skipped entirely.
Key facts:
- CVE ID: CVE-2026-24061
- Severity: Critical
- CVSS: 9.8
- EPSS: 29%
- Published: January 19, 2026
- Impact: Remote code execution as root
- Authentication required: None
- Affected versions: GNU InetUtils telnetd 1.9.3 through 2.7-2
References: NVD — CVE-2026-24061, CVE.org record.
How the flaw works
GNU InetUtils telnetd doesn't authenticate users itself — it hands that job off to /usr/bin/login, which it launches as a subprocess. While setting up an incoming connection, telnetd assembles a command line for login, splicing in client-supplied values to convey context like the remote hostname and the requested username.
The problem is unsafe string interpolation of data the client fully controls. The %U token in the login command template is swapped out for whatever sits in the USER environment variable. Crucially, the Telnet protocol's NEW_ENVIRON option lets a client push environment variables across during the negotiation handshake — before any authentication happens. That means an attacker can dictate the value of USER ahead of time.
Since telnetd never validates or escapes that value, an attacker simply sets USER to -f root. The command telnetd then constructs looks like this:
/usr/bin/login -h [hostname] "-f root"
The -f flag tells login to treat the named account as pre-authenticated and hand over a shell immediately. Point it at root and you get an instant, unauthenticated root session.
The vulnerable code path
The bug lived in telnetd/utility.c, inside the format-string substitution routine. The case 'U' branch pulled the USER environment variable and returned it as-is, with no filtering.
Upstream fixed it across two commits by adding a sanitize() helper that rejects values starting with a dash (-) or containing shell metacharacters. The second commit is the more complete fix: it routes every substitution point through the sanitizer — not just USER, but also the hostname, terminal type, and line — closing off the whole class of injection rather than a single field.
Proof of concept
What makes CVE-2026-24061 so dangerous is that no exploit framework, shellcode, or privilege-escalation chain is needed — a stock Telnet client is enough. The entire PoC is a one-liner:
USER='-f root' telnet -a <target-ip>
Exporting USER before invoking the client causes that value to be sent over the wire via the NEW_ENVIRON option during the handshake. The -a flag requests automatic login using the current environment, which feeds the injected -f root argument straight into telnetd's login command construction. A public PoC is available at Chocapikk/CVE-2026-24061.
Impact and real-world exposure
The danger goes well beyond how easy the exploit is to run:
- Huge attack surface: Internet-wide scans show over 212,000 devices running Telnet servers, and roughly 1 million hosts listening on port 23.
- Active exploitation: CISA has added CVE-2026-24061 to its Known Exploited Vulnerabilities (KEV) catalog, and the threat group rwxrwx, among others, has been seen exploiting it.
- Zero prerequisites: With no account, credentials, or existing foothold required, the flaw is trivial for automated scanners and opportunistic attackers to weaponize.
- Full compromise: A successful hit yields an immediate root shell, opening the door to data theft, backdoors, lateral movement, and service disruption.
- Eleven years of exposure: The vulnerable code shipped in 2015, so affected systems have been quietly exploitable for over a decade.
Affected systems
Telnet is widely considered obsolete, yet it lingers in plenty of environments. CVE-2026-24061 specifically puts the following at risk:
- Legacy Unix and Linux servers running older GNU InetUtils packages
- Embedded systems and IoT devices that ship with
telnetdenabled for management - Network appliances (routers, switches, firewalls) that bundle GNU InetUtils
- Operational Technology (OT) and Industrial Control Systems (ICS) environments where legacy protocols persist
- Any host running GNU InetUtils telnetd 1.9.3 through 2.7-2, including the
telnetdpackage on Debian, Ubuntu, and their derivatives
Detection and mitigation
Given confirmed active exploitation, this warrants same-day action:
- Upgrade GNU InetUtils: Move to a release past 2.7-2 that includes the upstream sanitization fix. On Debian/Ubuntu, once the patched package lands in your repos:
apt upgrade inetutils-telnetd
- Disable Telnet outright: If you don't strictly need it, remove
telnetdnow and standardize on SSH for remote access. - Block port 23 at the edge: As immediate containment, drop inbound connections to TCP port 23 from untrusted networks.
- Audit exposed services: Scan internal and external hosts for live Telnet listeners. Tools like Shodan help map internet-facing exposure.
- Follow KEV timelines: Federal agencies and CISA-aligned organizations should remediate within the KEV catalog deadlines for CVE-2026-24061.
Bottom line
CVE-2026-24061 is a textbook example of legacy-protocol debt turning into a critical-severity liability. A single unsanitized environment variable, introduced in a 2015 commit, silently granted unauthenticated root access for more than ten years across hundreds of thousands of devices. The barrier to exploitation is effectively nil — one line from any standard Telnet client. With a public PoC circulating and known threat groups already exploiting it, the time to patch, remove the service, and firewall port 23 is right now.