Hackers Exploit Critical Telnetd Authentication Bypass to Gain Root Access (CVE-2026-24061)

What happened

Security researchers and threat monitoring teams have observed active exploitation of CVE-2026-24061, a critical flaw in the GNU InetUtils telnet daemon (telnetd). The vulnerability enables remote attackers to bypass authentication and obtain a shell as a chosen local account, most commonly root, without valid credentials.

While Telnet is widely considered a legacy protocol, it still appears in real environments:

• Industrial networks
• Embedded systems
• Lab infrastructure
• Long-lived Linux deployments where "if it still works, do not touch it" becomes the operating model

This incident is a reminder that legacy does not mean low risk. It often means high blast radius, slow patch cycles, and hard-to-replace devices.

The vulnerability in plain terms

The root cause is argument injection in how telnetd handles client-supplied environment variables during Telnet option negotiation. Telnetd passes the USER environment variable to the system login process without sanitizing it. The login program supports a flag that can skip normal authentication when it believes the session is pre-authenticated. An attacker can abuse this behavior remotely.

Why this is especially dangerous

Who is at risk

You should treat this as high priority if any of the following are true:

• You run GNU InetUtils telnetd, or inherited it through inetd style services
• TCP port 23 is reachable from untrusted networks (internet, partner networks, flat internal segments)
• You operate OT, ICS, or embedded environments where Telnet remains enabled for maintenance
• You rely on aging Linux images, appliance-like systems, or vendor stacks that rarely receive updates

Even if you believe "nobody uses Telnet," the relevant question is different: can an attacker reach Telnet? If the answer is yes, then the attacker uses it.

What exploitation looks like in the wild

Observed activity indicates coordinated probing of Telnet services, often automated, followed by post-exploitation steps that resemble common initial access playbooks:

Post-exploitation patterns observed

In several observed cases, follow-on steps failed due to missing utilities or directories on the target, but that is not a reliable defense. Attack chains rapidly evolve once attackers confirm a workable entry point.

Campaign metrics (GreyNoise)

Immediate mitigation and patch guidance

1) Eliminate exposure first

The safest mitigation is to disable telnetd entirely. If you must keep Telnet for operational reasons, restrict access aggressively:

• Block TCP/23 at the perimeter and between internal segments by default
• Allowlist only known admin subnets
• Put telnetd behind a VPN or zero trust access broker
• Add compensating controls such as strict monitoring and rapid isolation procedures

2) Patch using your distribution's security updates

Upstream fixes exist, but most environments consume telnetd via distribution packages. Apply the relevant inetutils updates from your distro security channel as soon as they are published for your release line.

3) If you cannot patch

Treat the system as potentially exposed and reduce blast radius:

Detection and hunting: what to look for

Prioritize detection in two layers: network and host.

Network level signals

Host level signals

Quick triage commands (Linux)

# Is Telnet listening?
ss -lntp | grep ':23'

# What package/version is installed (Debian/Ubuntu style)?
dpkg -l | grep inetutils

# Check for telnetd or inetd style services
ps aux | egrep 'telnetd|inetd' | grep -v grep

# Recent auth events (depends on distro)
sudo journalctl -u inetutils-inetd --since "7 days ago" 2>/dev/null
sudo grep -iE 'telnet|inetd|login' /var/log/auth.log 2>/dev/null | tail -n 200

Why this still matters in 2026: the legacy and OT reality

Security teams often discount Telnet vulnerabilities because the protocol is "obsolete." Operational teams keep Telnet because the systems are not.

The OT and embedded challenge

In OT and embedded environments, upgrades may require:

• Downtime that production cannot afford
• Reboot cycles that disrupt operations
• Recertification for regulated environments
• Vendor support that no longer exists

That mismatch is exactly what attackers exploit: a service that should be gone, but is still reachable.

The business takeaway

When you cannot eliminate exposure:

1. Wrap it in hardened access controls
2. Implement monitoring that assumes compromise attempts are continuous
3. Plan and budget for protocol replacement or system decommission

Closing

CVE-2026-24061 is a textbook example of why legacy exposure remains a critical risk category. The vulnerability is simple, exploitation is active, and the impact is root access. If your environment includes any systems running GNU InetUtils telnetd with network reachability, treat this as an urgent action item:

• Disable telnetd where possible
• Block TCP/23 at all network boundaries
• Patch via distro security updates
• Hunt for evidence of compromise during the exposure window

The attacker does not care that Telnet is obsolete. They care that it is reachable.