CVE-2026-24061 shows how telnetd turns input into root access

At a glance

What this is: CVE-2026-24061 is a critical telnetd argument-injection flaw that can grant unauthenticated root shell access through a single crafted session.

Why it matters: It matters because exposed non-human access paths can become full-system identity failures in minutes, forcing IAM, PAM, and infrastructure teams to treat remote service exposure as governance, not just patching.

By the numbers:

• A critical vulnerability ( CVE-2026-24061 , CVSS 9.8) was disclosed on January 20, 2026 affecting GNU InetUtils telnetd versions 1.9.3 through 2.7.
• GreyNoise reporting indicates that 83% of observed exploitation attempts targeted root access specifically.

👉 Read Orca Security's analysis of CVE-2026-24061 and telnetd root access

Context

CVE-2026-24061 is an argument-injection vulnerability in telnetd, the remote login daemon used by GNU InetUtils. The core identity problem is simple: an unauthenticated network session can be converted into privileged local execution because user-supplied input is passed into the login flow without adequate validation.

For IAM and PAM teams, the issue is not limited to a Unix package. It shows how an exposed service account path, remote access service, or legacy administrative channel can bypass normal authentication boundaries and become a root-level access path. That is a governance failure as much as a software defect.

The article describes active exploitation, public proof-of-concept code, and wide internet exposure on port 23. That combination makes this a typical legacy-access failure pattern, not an isolated product bug.

Key questions

Q: What breaks when telnetd can pass user input into login as a command flag?

A: The authentication boundary breaks. If a remote daemon lets client-supplied values reach a privileged helper as options instead of data, an attacker can change how the helper behaves. In this case, a crafted USER value can make login treat the session as already authenticated, which turns a network connection into root access without credentials.

Q: Why are exposed legacy remote login services such a high-risk identity issue?

A: Because they collapse access, authentication, and privilege into one internet-reachable path. A service that can interpret user input, invoke a privileged helper, and present a shell creates a direct route from network exposure to host compromise. That is why legacy remote access belongs in identity governance, not only in network hardening.

Q: How do security teams know whether a telnet exploit is actually working in the environment?

A: Look for root login events through telnetd that do not match normal password prompts, plus command-line patterns where USER begins with a dash. At the network layer, watch for NEW_ENVIRON negotiation carrying suspicious USER values. If those signals appear together, the service is being abused as designed by the attacker.

Q: Who is accountable when a critical remote access service grants unauthenticated root access?

A: Accountability sits with the team that owns the service exposure, the patching decision, and the retirement plan for the legacy path. Security, infrastructure, and platform owners all have a role, but no single control compensates for leaving a root-capable service reachable from untrusted networks.

Technical breakdown

How telnet NEW_ENVIRON negotiation becomes command injection

Telnet supports the NEW_ENVIRON option, which allows a client to send environment variables during session setup. In this case, telnetd passes the USER variable into the login flow without rejecting values that begin with a dash. Because login treats -f as a flag that bypasses password verification, a crafted value such as USER=-f root changes the meaning of the command. The weakness is not remote code execution in the classic sense. It is argument injection, where attacker-controlled input is interpreted as command options instead of data.

Practical implication: remove or tightly restrict legacy telnet services that accept client-supplied login parameters.

Why login -f root bypasses the normal authentication boundary

The login binary can accept a -f flag to indicate that a user is already authenticated. That flag is safe only when the calling process has already established trust in the session. Here, telnetd fails to prove that trust before handing over the USER field, so an unauthenticated network client can trick the system into treating the session as pre-authenticated. In practice, the attack collapses the boundary between remote connection setup and local privilege elevation.

Practical implication: validate every externally supplied login attribute before it reaches any privileged helper process.

Why internet-exposed port 23 turns a local flaw into immediate root compromise

The exploit path is short because telnet is typically reachable directly over TCP port 23 and often sits on older infrastructure that was never designed for hostile internet traffic. Once the daemon spawns a root shell, the attacker owns the host, can read credential stores such as /etc/shadow, and can plant persistence or pivot laterally. This is why exposure, not just patch status, determines operational urgency.

Practical implication: inventory and isolate every telnet endpoint, then remove the service where possible.

Threat narrative

Attacker objective: The attacker wants immediate root-level control of the host so they can steal credentials, persist, and pivot into the wider environment.

1. Entry occurs when an attacker reaches an internet-exposed telnetd service on TCP port 23 and sends a crafted NEW_ENVIRON USER value.
2. Credential access and escalation occur when telnetd invokes login -f root, bypassing password checks and granting immediate root shell access.
3. Impact follows quickly as the attacker can harvest credentials, install backdoors, and move laterally from the compromised host.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Argument injection in telnetd is a governance failure, not just a patching event. The flaw succeeds because externally supplied input is allowed to influence privileged authentication flow before trust has been established. That is a control boundary failure in legacy remote access, and it shows why service exposure decisions belong in identity governance as much as in vulnerability management. Practitioners should treat privileged remote login paths as governed access surfaces, not passive infrastructure.

Standing trust in administrative login paths breaks the moment client input can redefine the command. The assumption that a remote session will present data, not control flags, is embedded in many older access services. CVE-2026-24061 proves that assumption can collapse into root access with no credentials, no user interaction, and no warning. The implication is that legacy privileged access channels must be evaluated as pre-authentication identity risks, not only as software defects.

Legacy service accounts and remote helpers create identity blast radius when they sit directly on the network. telnetd is a reminder that a daemon with root-adjacent behaviour and weak input handling can become a full-system takeover path. The broader lesson is that administrative access should not depend on interpreters that accept user-controlled arguments in privilege-bearing contexts. Practitioners should map these services as part of NHI and PAM inventory, because the attack surface is an access model problem.

Remote login services need the same lifecycle scrutiny as other privileged identities. If a daemon can still authenticate or elevate based on assumptions made decades ago, the issue is not only technical debt but lifecycle debt. Old access paths often survive because no one owns their retirement, review, or restriction. The practical conclusion is that dormant or legacy administrative channels must be retired, not merely patched, when they no longer fit current trust models.

Exploitation speed matters because identity abuse now follows disclosure almost immediately. The article’s telemetry shows scans and attempts within hours of disclosure, which compresses the window for manual response. That speed matters for IAM and PAM teams because exposed privileged services cannot wait for normal maintenance cycles. The field should assume that once a root-exposure flaw is public, access governance and detection must move in the same operational window.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That same research found only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which underscores how exposed identity surfaces outpace current controls.
• For a broader lifecycle lens, Ultimate Guide to NHIs shows why visibility, offboarding, and privilege scope must be governed together.

What this signals

Identity blast radius: Legacy access services that still accept client-controlled login parameters can turn a single exposed daemon into a full host takeover. That means exposure management, service retirement, and privileged access inventory now need to be treated as one programme rather than separate operations, especially where old protocols still reach production systems.

The operational signal is clear. If a remote service can bypass authentication by design or by bug, then patch SLAs alone are insufficient. Teams need to know which access paths are still trusted implicitly, which are externally reachable, and which should be removed altogether before the next disclosure window closes.

For a broader view of how exposed credentials and weak lifecycle control become breach paths, use 52 NHI Breaches Analysis as a reference point for recurring failure patterns.

For practitioners

• Inventory every telnetd instance immediately Find all GNU InetUtils telnetd deployments, confirm version range, and identify whether any instance is internet-facing or still reachable from flat internal networks.
• Disable or remove telnetd before patching cycles complete Stop the service, disable it at boot, and remove the package where possible. For remote administration, move to SSH and restrict access to trusted management paths only.
• Block TCP port 23 at every perimeter and segment boundary Add controls at firewalls, security groups, and host-level rules so exposed telnet services cannot be reached from untrusted networks.
• Search logs for argument-injection indicators Look for USER values beginning with a dash, root logins via telnetd without normal authentication prompts, and unexpected root shells spawned by the daemon.

Key takeaways

• CVE-2026-24061 shows how a legacy remote login daemon can be converted into unauthenticated root access through argument injection.
• The scale of exposure is material because public internet scanning already targets port 23 and exploitation attempts are arriving quickly after disclosure.
• The limiting control is not only patching. It is removing the exposed service, blocking the port, and retiring the privileged access path entirely.

Key terms

• Argument Injection: Argument injection happens when attacker-controlled input is interpreted as command-line options instead of data. In privileged services, that can change how a helper behaves without breaking authentication directly. The result is often privilege escalation through trusted software paths rather than classic code execution.
• Remote Access Service: A remote access service is a network-exposed component that lets a user or system reach a host without local console access. For identity teams, it is a governed access path, not just an application. If the service can elevate privilege, it belongs in PAM and lifecycle review.
• Privileged Helper Process: A privileged helper process is a program that runs with elevated rights to perform sensitive tasks on behalf of another component. These helpers are high-value identity boundaries because they inherit trust from the caller. If caller input is not validated, the helper can become a direct escalation path.

Deepen your knowledge

CVE-2026-24061 and legacy remote access exposure are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment still includes service-based administrative paths, this is a useful place to strengthen governance.

This post draws on content published by Orca Security: CVE-2026-24061 analysis of telnetd root-shell exploitation. Read the original.