A critical authentication bypass vulnerability in GNU InetUtils telnetd is being actively exploited in the wild, allowing remote unauthenticated attackers to obtain a root shell in a single step. Tracked as CVE-2026-24061 and carrying a CVSS v3.1 score of 9.8, this flaw requires no credentials, no user interaction, and no special pre-conditions. Any system with a reachable telnetd service running GNU InetUtils versions 1.9.3 through 2.7 should be treated as immediately compromised until patched or mitigated.

What Is CVE-2026-24061?

CVE-2026-24061 is an authentication bypass vulnerability in the GNU InetUtils Telnet daemon (telnetd). The daemon is responsible for accepting incoming Telnet connections, negotiating protocol options, and invoking the local login program to authenticate users.

The root cause is a failure to sanitize the USER environment variable before expanding it into the command line used to invoke login. A malicious Telnet client can supply a crafted value — specifically -f root — for the USER variable. When telnetd constructs the login invocation, it executes:

login -f root

The -f flag instructs the login binary to skip authentication entirely. The result is an immediate, unauthenticated root shell granted to the remote attacker. No exploit chaining, no privilege escalation step, and no target-side interaction is required. This is a single-packet-to-root compromise.

Active Exploitation Confirmed

GreyNoise has observed multiple IP addresses actively attempting to exploit CVE-2026-24061 against internet-facing hosts. Observed attack traffic includes Telnet sessions delivering the crafted -f root USER variable payload, confirming that threat actors have already operationalized this vulnerability.

The simplicity of the exploit — it is a trivial parameter injection with no shellcode, no memory corruption, and no prerequisite foothold — means the barrier to exploitation is extremely low. Script-kiddie-tier actors can weaponize this as easily as advanced persistent threat groups.

Why telnetd Is Still Present in 2026

While Telnet has been deprecated in favor of SSH for decades, telnetd persists in environments where legacy compatibility, operational constraints, or vendor lock-in prevent hardening. Commonly affected environments include:

• Embedded Linux systems — routers, switches, and appliances shipping with InetUtils as part of a minimal base image
• Industrial and OT devices — PLCs, HMIs, and SCADA gateways where Telnet is the only supported management interface
• Legacy vendor images — server and NAS products that have not received updated firmware in years
• Management networks — out-of-band management planes where administrators accepted the Telnet risk to maintain access to aging hardware

The presence of telnetd in OT and management networks is particularly dangerous. These environments are often difficult to patch rapidly, may lack endpoint detection coverage, and a successful root compromise could directly affect physical operations or safety systems.

Affected Versions and Patch Guidance

Affected: GNU InetUtils versions 1.9.3 through 2.7 (inclusive).

The GNU InetUtils maintainers released patches on January 20, 2026, the same day as public disclosure via the OSS-Security mailing list. The patches sanitize environment variable expansion before invoking login, closing the injection path.

Remediation steps in priority order:

• Apply the upstream patches released January 20, 2026, or upgrade to a fixed InetUtils release incorporating those changes.
• Disable telnetd entirely wherever it is not operationally required. This is the preferred long-term fix; Telnet should not be running on any modern system.
• Restrict access at the network layer if immediate patching is not feasible — firewall TCP/23 to trusted IP ranges only and block all inbound Telnet from untrusted segments.
• Block unsafe login -f invocation as a temporary compensating control through PAM configuration or wrapper scripts while awaiting a patch window.

Indicators of Compromise

Because CVE-2026-24061 abuses normal process execution paths, exploitation may leave limited forensic artifacts and may not trigger signature-based alerts. Defenders should hunt for the following indicators on exposed hosts:

• Telnet sessions that result in a root shell without a corresponding authentication event in /var/log/auth.log or equivalent
• login processes invoked with the -f flag visible in process auditing logs (e.g., auditd, syslog, EDR telemetry)
• New or modified entries in /etc/cron*, /etc/rc.local, ~root/.bashrc, or /etc/passwd following Telnet session activity
• Unexpected outbound connections or lateral movement originating from Telnet-enabled hosts
• New SSH authorized keys or backdoor accounts added to the root user

The absence of alerts should not be taken as confirmation of a clean system. Attackers with root access can clear logs, and the attack itself generates no failed authentication noise.

Vulnerability Timeline

• January 20, 2026 — Vulnerability publicly disclosed via the OSS-Security mailing list
• January 20, 2026 — GNU InetUtils patches released
• January 21, 2026 — CVE-2026-24061 published with Critical severity by MITRE/NVD
• January 23, 2026 — Rapid Response test made available via NodeZero
• Active exploitation observed and reported by GreyNoise

Conclusion

CVE-2026-24061 is about as dangerous as vulnerabilities get: unauthenticated, remotely exploitable, immediately yields root, requires no complexity, and is already being actively scanned and exploited. The attack surface — legacy telnetd deployments in embedded systems, OT networks, and management planes — is precisely the class of infrastructure that organizations struggle to patch quickly.

The immediate action is straightforward: audit your environment for TCP/23 exposure, disable telnetd wherever it is not required, and apply the January 20, 2026 patches to any system that must continue running the service. Verify remediation with an authenticated scan or a purpose-built exploit test. Do not assume that network segmentation alone is sufficient — assume breach and hunt for post-exploitation artifacts on any system that had Telnet exposed before this patch was applied.