Legacy Telnet Service Under Fire: CISA Adds CVE-2026-24061 to KEV After Active Exploitation

CyberDefender 8 mins0

CVE-2026-24061 is a critical authentication bypass vulnerability affecting the GNU InetUtils telnetd service. When exploited, it allows a remote, unauthenticated attacker to obtain root access over Telnet with no valid credentials.

The issue exists because telnetd incorrectly trusts environment variables provided by the remote client and passes them directly to the local login binary. Under specific conditions, this allows an attacker to bypass authentication entirely and spawn a root shell.

CVE-2026-24061 has been added to the U.S. Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) Catalog. This means CISA has identified it as a vulnerability that is actively exploited in the wild, and federal civilian agencies and others should treat it as a high-priority issue to remediate.

Key points about its inclusion in CISA KEV

  • It’s officially listed in the CISA KEV catalog as of January 26, 2026.
  • The catalog entry describes it as a GNU InetUtils argument injection issue in telnetd that can lead to authentication bypass and remote root access.
  • CISA sets due dates for remediation under its BOD 22-01 policy, indicating organizations are expected to patch or mitigate by February 16, 2026.

This vulnerability is especially dangerous because:

  • It requires no credentials
  • It works over the network
  • It grants immediate root access
  • Telnet is often forgotten on legacy systems, appliances, lab servers, and embedded devices

Affected Software

  • GNU InetUtils telnetd
  • Vulnerable versions: 1.9.3 up to 2.7
  • Affects multiple Linux distributions where inetutils-telnetd is installed or enabled

Any system running telnetd from GNU InetUtils in this range should be considered compromised if exposed.

Root Cause Analysis

What Goes Wrong Internally

  1. Telnet supports an option called ENVIRON, which allows a client to send environment variables to the server.
  2. GNU InetUtils telnetd accepts these variables and forwards them to /usr/bin/login.
  3. The login program supports a -f <user> option:
    • This option skips authentication if the caller is trusted.
  4. Telnetd fails to sanitize the USER environment variable.
  5. A malicious client can set: USER=-f root
  6. When telnetd launches login, the argument is misinterpreted as a flag rather than a username.
  7. login assumes authentication has already succeeded and spawns a root shell.

Why This Is Severe

  • No memory corruption
  • No brute force
  • No race condition
  • No exploit chaining

It’s a logic flaw, which makes exploitation extremely reliable.

Exploitation Characteristics

The following is behavioral analysis only, for detection and defense. No exploit steps or commands are provided.

An exploitation attempt typically involves:

  • A Telnet client that explicitly negotiates ENVIRON
  • Transmission of a malicious USER variable
  • Immediate successful login as root without password prompts
  • No failed authentication attempts in logs

This makes the attack quiet and easy to miss if you only monitor failed logins.

Indicators of Compromise (IoCs)

System-Level Indicators

  • Root shell sessions originating from telnetd
  • No corresponding authentication events
  • Unexpected /bin/login executions by telnetd
  • Root sessions with no PAM authentication trail

Log Artifacts to Watch

Depending on distro, inspect:

  • /var/log/auth.log
  • /var/log/secure
  • journalctl -u telnet.socket
  • journalctl -u telnet@*.service

Red flags include:

  • login sessions without password checks
  • Root logins over Telnet
  • Missing PAM messages for successful root sessions

Detection Rules (Defensive / SOC-Ready)

1. Telnet Root Login Detection (SIEM)

IF
  process.name == "login"
  AND parent.process.name == "telnetd"
  AND user == "root"
  AND authentication.method != "password"
THEN
  alert "Possible CVE-2026-24061 exploitation"

2. ENVIRON Abuse Detection (Network)

Monitor Telnet sessions for:

  • ENVIRON option negotiation
  • Suspicious environment values containing:
    • -f
    • whitespace
    • leading hyphens

This can be implemented in:

  • IDS (Suricata / Snort)
  • Network telemetry tools
  • Zeek protocol analysis

3. Unexpected Root Telnet Sessions

IF
  service == "telnet"
  AND user == "root"
THEN
  high-severity alert

Root login over Telnet should be considered malicious by default in modern environments.

4. Process Anomaly Detection (EDR)

Watch for:

  • telnetd spawning login with abnormal arguments
  • Root shells spawned without PAM stack invocation

Exploitation Availability (Educational Only)

  • Proof-of-concept exploitation code exists publicly
  • Exploitation is trivial once Telnet is reachable
  • Attacks are fully automated and scriptable
  • Often used for:
    • Initial access
    • Botnet propagation
    • Lateral movement staging

Do not test exploitation on production systems.
Only validate exposure using configuration checks.

How to Check If You’re Vulnerable (Safe Methods)

Check if Telnet Is Installed

which telnetd

or

dpkg -l | grep inetutils-telnetd
rpm -qa | grep inetutils

Check If Telnet Is Active

systemctl status telnet.socket
systemctl status [email protected]

If Telnet is installed and enabled → assume vulnerable unless patched.

Remediation & Mitigation

Immediate Actions

  1. Disable Telnet systemctl disable telnet.socket systemctl stop telnet.socket
  2. Block TCP port 23 at network boundaries
  3. Audit for unauthorized root activity

Patch / Upgrade (Official Fixes)

Apply vendor patches or upgrade InetUtils to a fixed version.

🔗 Patch & advisory links (official sources):

Always use your OS vendor’s packaged update — do not manually replace binaries.

Long-Term Security Recommendations

  • Remove Telnet entirely; replace with SSH
  • Disable root login over remote protocols
  • Enforce PAM auditing
  • Add detection rules for legacy services
  • Treat Telnet exposure as a critical misconfiguration

CyberDefender