A newly disclosed flaw in GNU telnetd, tracked as CVE-2026-24061 and rated CVSS 9.8, lets an unauthenticated remote attacker open a Telnet session and land directly in a root shell — no password required. The bug, an authentication bypass in GNU InetUtils, affects every release up to and including 2.7-2 and was traced back to a code change made in 2015. SafeBreach Labs published a root-cause breakdown and a working proof-of-concept, and a separate exploit is already on GitHub.

What the vulnerability is

CVE-2026-24061 is an authentication-bypass defect in the telnetd daemon shipped with GNU InetUtils. It was discovered in January 2026 by researcher Kyu Neushwaistein — who also goes by Carlos Cortes Alvarez. Despite Telnet's reputation as an obsolete protocol, it is still running in plenty of places: Unix and Linux hosts, embedded gear, network appliances, and OT-adjacent systems. Shodan currently indexes more than 212,000 internet-facing Telnet servers, and Censys reports over 1 million devices listening on TCP port 23. Only a fraction of those run the vulnerable GNU telnetd, but the exposed surface is still large.

According to NVD and CVE.org, the record was published on January 21, 2026 (NVD, CVE.org).

Root cause: a 2015 commit

The defect originates in a single change committed in 2015, meaning it has shipped silently for over a decade. The edit landed in telnetd.c and altered a command-template constant named login_invocation, introducing a new placeholder: %U.

The chain works like this:

  • login_invocation builds the command line used to launch /usr/bin/login, the standard binary that handles user authentication.
  • The %U placeholder is expanded at runtime by the _var_short_name function in pty.c.
  • During expansion, %U is substituted with the value of the USER environment variable — and that value can be supplied by the connecting client through Telnet's environment-negotiation feature.
  • Because the client-controlled value is dropped into the /usr/bin/login command line without sanitization, an attacker can inject arbitrary command-line flags.

Why -f turns this into instant root

The -f flag tells the Linux login binary to skip interactive authentication and go straight to setting up the session. By smuggling -f root into the command line via a manipulated USER variable, the attacker convinces login to grant a fully authenticated root session with no password prompt. As SafeBreach Labs put it, the -f flag "skips the interactive authentication and just drops us into a root shell," yielding remote code execution on any host running GNU telnetd up to 2.7-2.

That makes CVE-2026-24061 a direct initial-access primitive: network reach to port 23 is enough to obtain root-level RCE in seconds, with no credentials and minimal tooling.

How the Telnet protocol delivers the payload

Telnet supports an option called NEW_ENVIRON, which lets a client propose environment variables to the server before the session starts — normally used to pre-populate things like the login username for autologin. In this exploit, the attacker abuses that handshake:

  1. Connect to the target telnetd service (typically port 23).
  2. During option negotiation, the server requests NEW_ENVIRON data.
  3. The attacker responds with the USER environment variable set to -f root.
  4. The injected argument bypasses the authentication check.
  5. A root shell is handed over with no password prompt.

SafeBreach Labs confirmed the mechanism by tracing the packet exchange: the final SUBOPTION packets carry the attacker-controlled environment data, which flows straight into the vulnerable login invocation. A public exploit demonstrating exactly this is available at SystemVll/CVE-2026-24061, which describes the bug as improper validation of the USER value in the telnetd NEW_ENVIRON handler.

Beyond the bypass: arbitrary environment control

The authentication bypass is not the only consequence. Because Telnet clients can set environment variables that telnetd and its child processes inherit, a successful attacker can also define arbitrary environment variables for any process the daemon spawns. That capability can be repurposed for post-exploitation, persistence, or tampering with child-process behavior — widening the blast radius well past a single shell.

Why the severity is so high

  • CVSS 9.8 (Critical) — no authentication, no user interaction, full system compromise.
  • Network-exposed service — Telnet listens on port 23, frequently reachable from untrusted networks in legacy deployments.
  • Broad version coverage — all GNU InetUtils telnetd builds through 2.7-2 are affected.
  • Wide deployment — embedded systems, OT networks, and aging Linux servers often leave Telnet enabled.
  • Public exploit — a working PoC is published, dropping the bar for exploitation.

Detection and mitigation

Treat this as a priority fix:

  • Disable Telnet wherever it is not strictly required, and use SSH for remote administration instead.
  • Patch GNU InetUtils to a release beyond 2.7-2 once an upstream fix is available.
  • Audit firewall rules so port 23 is not reachable from untrusted networks or the public internet.
  • Scan your own ranges with Shodan or Censys queries scoped to your IPs to find exposed Telnet services.
  • Watch for exploitation — flag unexpected inbound Telnet connections and anomalous child processes spawned by telnetd.

The following are generic, illustrative examples (not facts specific to this incident) showing how those steps typically look on a Linux host:


# Stop and disable an inetd/xinetd-style telnet service
sudo systemctl stop telnet.socket telnetd 2>/dev/null
sudo systemctl disable telnet.socket telnetd 2>/dev/null

# Confirm nothing is still listening on TCP 23
sudo ss -ltnp | grep ':23' || echo "no telnet listener"

# Block inbound port 23 at the host firewall
sudo iptables -A INPUT -p tcp --dport 23 -j DROP

A generic Shodan/Censys-style search to locate exposed Telnet in your own address space would scope on port:23 together with your owned CIDR ranges.

Takeaway

CVE-2026-24061 is a reminder that legacy protocols carry legacy risk, and that one careless commit can plant a critical flaw that survives undetected for years. An authentication bypass sitting in one of Linux's most basic remote-access services since 2015 makes the case for continuous security research and aggressive attack-surface reduction. With SafeBreach's analysis and a public PoC now circulating, any environment exposing GNU telnetd should remediate immediately.