A maximum-severity authentication bypass in the GNU InetUtils Telnet daemon is under active exploitation, letting remote attackers drop straight to a root shell with a single crafted connection. Tracked as CVE-2026-24061 and rated CVSS v3.1 9.8, the bug needs no credentials, no user interaction, and no chaining — supplying -f root as the USER environment variable during Telnet negotiation is enough. Every host exposing a telnetd service built on GNU InetUtils 1.9.3 through 2.7 should be treated as compromised until patched, disabled, or firewalled.

The bug in one sentence

telnetd hands the value of the client-supplied USER environment variable into the command line it builds to launch the system login program — without sanitizing it first. Because login parses leading tokens as flags, an attacker who sets USER to -f root causes the daemon to effectively run:


login -f root

The -f flag tells login to trust the supplied identity and skip authentication entirely. The daemon therefore opens an authenticated root session for a remote party who never proved anything. There is no memory corruption, no shellcode, and no second-stage privilege escalation — it is pure argument injection that turns a protocol option into a root shell.

According to the NVD entry, the flaw affects "telnetd in GNU Inetutils through 2.7" and permits "remote authentication bypass via a -f root value for the USER environment variable." The record is also tracked at cve.org.

How the attack works

The injection rides on Telnet's NEW_ENVIRON option, the mechanism a client normally uses to pass environment variables (like USER) to the server at session setup. The published security-research tool SystemVll/CVE-2026-24061 documents the sequence:

  1. The attacker opens a TCP connection to the target telnetd, usually on port 23.
  2. During option negotiation, the server requests NEW_ENVIRON data.
  3. The client replies with the USER variable set to -f root.
  4. telnetd fails to validate that value and passes it through to login, where the injected argument forces authentication to succeed for root.
  5. A root shell is returned with no password prompt.

The only prerequisite is network reachability to a vulnerable telnetd instance. That trivially low bar means everyone from opportunistic scanners to organized intrusion crews can run it identically.

Confirmed exploitation in the wild

GreyNoise has reported multiple source IPs probing internet-facing hosts with this exact payload, observing Telnet sessions that carry the crafted -f root USER value. In other words, the technique is already operationalized, not theoretical. Given how little skill the exploit demands, defenders should not expect a grace period.

Why telnetd is still out there in 2026

SSH replaced Telnet for remote administration decades ago, yet telnetd survives in pockets of infrastructure that are hard to modernize:

  • Embedded Linux — routers, switches, and appliances that bundle InetUtils into a minimal base image.
  • Industrial and OT gear — PLCs, HMIs, and SCADA gateways where Telnet is sometimes the only management interface offered.
  • Stale vendor images — server and NAS products running firmware that hasn't been refreshed in years.
  • Out-of-band management planes — networks where operators knowingly accepted Telnet's risk to keep reaching aging hardware.

These are precisely the environments that resist rapid patching, often lack endpoint telemetry, and — in OT and management contexts — can connect a root compromise directly to physical processes or safety systems.

Affected versions and remediation

Vulnerable: GNU InetUtils 1.9.3 through 2.7, inclusive.

The InetUtils maintainers shipped fixes on January 20, 2026 — the same day the issue went public on the OSS-Security mailing list — that sanitize environment-variable expansion before invoking login, closing the injection path.

Prioritized response:

  1. Patch or upgrade. Apply the upstream fixes from January 20, 2026, or move to a fixed InetUtils release that incorporates them.
  2. Turn off telnetd anywhere it isn't strictly required. This is the durable fix; Telnet has no place on a modern system.
  3. Constrain the network path if you can't patch immediately — restrict inbound TCP/23 to trusted ranges and block Telnet from untrusted segments.
  4. Block the unsafe login -f path as a stopgap, via PAM policy or a wrapper script, while you wait for a maintenance window.

Detection and threat hunting

Because the exploit abuses ordinary process-execution paths and produces no failed-login noise, it may leave thin forensic traces and slip past signature-based detection. Hunt for:

  • Telnet sessions that yield a root shell with no matching authentication event in /var/log/auth.log (or the platform equivalent).
  • login processes started with the -f flag in process-auditing data such as auditd, syslog, or EDR telemetry.
  • New or altered entries in /etc/cron*, /etc/rc.local, ~root/.bashrc, or /etc/passwd that follow Telnet activity.
  • Unexpected outbound connections or lateral movement sourced from Telnet-enabled hosts.
  • Newly added SSH authorized keys or backdoor accounts tied to root.

A quiet alert console is not evidence of safety: an attacker holding root can wipe logs, and the attack itself generates no authentication failures to flag.

Technical background: NEW_ENVIRON and login -f

For readers unfamiliar with the moving parts, the following is general, well-established Telnet behavior — not incident-specific detail. The Telnet protocol's NEW_ENVIRON option (RFC 1572) lets a client volunteer environment variables to the server during negotiation; USER is a standard one, historically used so the server knows which account the client intends to log in as. Meanwhile, the Unix login program accepts a -f ("force") flag that means "this user is already authenticated, skip the password check" — a feature legitimately used by trusted front-ends. The danger arises whenever an untrusted, attacker-controlled string is concatenated into a command line without escaping: a value that begins with - can be reinterpreted as an option rather than data. Generically, that is the same hazard as running:


# UNSAFE: untrusted $USER expands into argv as a flag
login "$USER"      # attacker sets USER='-f root'  →  login -f root

The fix class is equally generic: validate or quote the value, or use an argument terminator / explicit separation so user-supplied data can never be parsed as flags.

Timeline

  • January 20, 2026 — public disclosure via the OSS-Security mailing list.
  • January 20, 2026 — GNU InetUtils patches released.
  • January 21, 2026 — CVE-2026-24061 published as Critical by MITRE/NVD.
  • January 23, 2026 — Rapid Response test made available via NodeZero.
  • Ongoing — active exploitation observed and reported by GreyNoise.

Bottom line

CVE-2026-24061 checks every box for a worst-case vulnerability: unauthenticated, remotely triggered, instantly root, dead simple, and already being scanned and exploited — against the kind of legacy and embedded infrastructure that is slowest to patch. Audit your estate for TCP/23 exposure, kill telnetd wherever it isn't essential, and apply the January 20, 2026 patches to anything that must keep running it. Confirm remediation with an authenticated scan or a purpose-built test, and don't lean on segmentation alone — assume breach and hunt for post-exploitation artifacts on any host that had Telnet reachable before patching.