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

At a glance

What this is: This is a critical telnetd argument-injection flaw that lets unauthenticated attackers turn a crafted USER value into immediate root access on affected systems.

Why it matters: It matters because exposed remote access services can become direct identity compromise points, forcing IAM and PAM teams to treat service exposure, authentication bypass, and administrative privilege as one control problem.

By the numbers:

• CVE-2026-24061 carries a CVSS score of 9.8, according to Orca Security.
• GreyNoise telemetry cited by Orca Security showed 18-21 unique IP addresses conducting automated exploitation scans within 24 hours of disclosure.

Context

CVE-2026-24061 is an argument-injection vulnerability in GNU InetUtils telnetd that lets a remote client influence how the login program is invoked. In identity terms, the problem is not just a software bug but a broken trust boundary between network input and privileged execution.

The risk sits squarely in remote access governance because telnetd is handling authentication-adjacent data before the system has established a trustworthy user identity. Once an attacker can shape the login command line, the service stops being a gate and becomes a privilege conveyor.

Orca Security says the flaw affects versions 1.9.3 through 2.7 and has already been exploited in the wild. That makes this a live exposure problem, not a hypothetical patch-cycle issue.

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 is exposed telnet such a serious access-control problem?

A: Because exposed telnet is not just an old transport, it is a remotely reachable administrative surface. When a flaw allows argument injection or authentication bypass, port 23 exposure becomes a direct path to privileged execution rather than a harmless legacy service.

Q: What are the signs that telnetd exploitation is underway?

A: Look for telnet sessions negotiating NEW_ENVIRON with suspicious USER values, especially dash-prefixed arguments, and for root shell processes spawned by telnetd without a normal authentication flow. Those signals point to command injection or authentication bypass rather than ordinary remote use.

Q: Should organisations keep telnetd running if it is patched?

A: Usually no. If an unauthenticated flaw can convert a remote connection into root access, the safer decision is to remove telnetd wherever possible and reserve privileged administration for encrypted, accountable remote access methods with stronger session controls.

Technical breakdown

How telnetd turns environment input into a login command

telnetd supports the NEW_ENVIRON option, which lets a client send environment variables during session negotiation. In the vulnerable flow, the USER value is passed into the login invocation without sufficient validation. Because login accepts -f to skip password verification for a user assumed to be pre-authenticated, a crafted value such as USER=-f root can alter the command’s meaning. The bug is a classic argument-injection pattern: attacker-controlled input is treated as trusted process arguments instead of inert data. That is why a network connection can become a privileged local execution path.

Practical implication: treat any remotely supplied environment value as command input risk until it is explicitly validated and safely passed.

Why a single flag can bypass authentication

The dangerous detail is not telnet alone but the interaction between telnetd and the login binary. If telnetd passes a dash-prefixed USER value into login, the flag parsing logic interprets it as an option rather than a username. That shifts the session from identity verification to authentication bypass, which is why the flaw produces an immediate root shell instead of a limited user session. This is exactly the sort of boundary failure that makes legacy remote access services hazardous: one parser trusts the other parser’s output, and neither layer re-establishes identity before privilege is granted.

Practical implication: validate command arguments at the boundary where remote input becomes privileged process execution.

Why exposed port 23 creates an identity risk, not just a network risk

Publicly reachable telnet services are not simply outdated transport. They are remotely reachable identity entry points with weak confidentiality, minimal session integrity, and high privilege potential if the service is misused or compromised. When a flaw like CVE-2026-24061 exists, exposure on TCP port 23 converts reachability into immediate administrative compromise. That means the control question is not only whether the host is patched, but whether telnetd should exist at all in an environment where SSH or other controlled access paths can replace it.

Practical implication: inventory and remove exposed telnet services before relying on patching alone.

Threat narrative

Attacker objective: The attacker’s objective is immediate root-level control of the target system without needing valid credentials or prior access.

1. Entry occurs over TCP port 23 when an unauthenticated attacker opens a telnet session to a vulnerable GNU InetUtils telnetd service.
2. Credential access is bypassed when the attacker supplies a crafted USER value that telnetd passes to login as a command argument.
3. Escalation follows immediately because login -f root suppresses password verification and returns an interactive root shell.
4. Impact is full system compromise, including credential theft, persistence, and lateral movement from the affected host.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Argument injection at the login boundary is the real failure, not telnet as a protocol. The vulnerable trust decision happens when user-controlled environment data is converted into a login command line. That means the security boundary is not the socket, but the point where remote input becomes privileged execution. Practitioners should read this as a command-construction failure in a remote access service, not a simple patch-ticket item.

Remote access services should be governed as identity infrastructure. Telnetd is effectively making an authentication decision on behalf of the system, which places it in the same governance conversation as PAM, remote administration, and privileged session control. Once a service can mint root access from unauthenticated input, its lifecycle, exposure, and removal strategy belong in identity governance, not only vulnerability management.

Standing access assumptions break the moment a network service can impersonate a trusted user. The assumption that authentication happens before privilege assignment was designed for services that preserve a clear boundary between identity proofing and command execution. That assumption fails when an attacker can inject a login option through a remote session and obtain root in one step. The implication is that practitioners need to rethink which legacy services are still allowed to sit inside the trust boundary at all.

Privileged access review does not help if the service can create privilege before review. The article’s exploitation path shows a control gap where no certification cycle can intervene because the attacker goes from network reachability to root shell in a single transaction. That makes exposure reduction, service elimination, and strict remote access containment more decisive than post-event account review.

Telnet exposure debt: services kept for compatibility can become latent privilege conduits once command parsing bugs are discovered. That debt accumulates across forgotten hosts, old distributions, and unsupported workflows that still accept port 23 traffic. The practical conclusion is that legacy remote access should be treated as an inherited identity risk until it is removed or isolated.

What this signals

Telnetd is a governance problem once it can convert network reachability into root access. The practical lesson is that some remote services are too close to privilege creation to be treated as ordinary infrastructure. Identity teams should fold legacy remote access into PAM and service-exposure reviews, not leave it inside a generic patch queue.

Access review alone cannot compensate for authentication bypass in a service boundary. If a remote daemon can invoke login with attacker-shaped arguments, the control failure happens before any human review or certification cycle has a chance to operate. The answer is to reduce the exposure surface and remove the service path, not to rely on downstream monitoring.

Services that still depend on port 23 should be treated as latent root-access conduits. That framing helps teams prioritise removal over acceptance of legacy exceptions, especially where SSH or another controlled remote access pattern is already available. Once the service is reachable, the trust assumption is already strained.

For practitioners

• Disable telnetd on every reachable host Stop and disable telnetd on systems that still run it, then verify that no management workflow depends on TCP port 23 for administrative access.
• Block external access to port 23 Remove internet exposure at firewalls, security groups, and network ACLs so unauthenticated remote sessions cannot reach the service even before patching is complete.
• Patch or remove affected inetutils packages Upgrade vulnerable GNU InetUtils telnetd installations to fixed releases, or uninstall the package entirely where the service is not essential.
• Audit for root logins driven by telnetd Search auth logs and process telemetry for root shells spawned by telnetd and for login events that lack a normal password challenge.
• Replace telnet with controlled remote access paths Move administrative access to SSH or another authenticated remote access pattern that preserves accountability, encryption, and least privilege.

Key takeaways

• CVE-2026-24061 shows that a remote access daemon can become a direct root shell path when it accepts attacker-controlled arguments as part of authentication flow.
• Orca Security says the flaw is critical, affects GNU InetUtils telnetd 1.9.3 through 2.7, and has already been seen under active exploitation.
• The control that matters most here is service removal or isolation, because a vulnerable telnetd instance can create privilege before any credential review or session governance can help.

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.
• Authentication bypass: An authentication bypass is a flaw that lets a requester reach protected functionality without completing the intended identity check. In practice, it turns the application’s login boundary into a broken assumption, so any exposure path in front of that application becomes materially more important.
• Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.