A vulnerability in the GNU InetUtils package has affected all versions from 1.9.3 to 2.7 inclusive.
It may seem that telnet has long been left behind with modems and dial-up, yet it has suddenly become the source of a serious vulnerability. A bug has been discovered in GNU InetUtils that allows remote access to the system as root without a password, simply by sending a specially crafted value for the environment variable.
The problem affects the telnetd server, part of GNU InetUtils. It passes the USER variable value received from the client to the login program without any verification. This can be exploited if the client sends the string "-f root" as USER and connects with the telnet -a or –login parameter. As a result, the login interprets this as a service flag, bypasses the standard authentication procedure, and automatically authorizes the user as root.
The vulnerability has been assigned the identifier CVE-2026-24061 and a CVSS rating of 9.8. All versions of GNU InetUtils from 1.9.3 to 2.7 inclusive are at risk. The bug has been present in the project for almost 11 years, since May 2015, but was only discovered recently. Essentially, this is a classic example of an old-school vulnerability where a dangerous string is passed to a system utility with root privileges without filtering.
The authors of the advisory strongly recommend not using telnetd at all, restricting access to the telnet port only to trusted clients, and quickly applying the patch or upgrading to a version that fixes the problem. A temporary solution may involve completely disabling telnetd or using a custom version of login that does not support the "-f" parameter.
The vulnerability was discovered by researcher Carlos Cortes Alvarez, with a patch prepared and refined by the GNU InetUtils developers in January 2026. The fixes include sanitizing all variables used in forming the login command, making such attacks impossible in principle.
The story seems almost symbolic: an outdated protocol, a forgotten service, and a classic logical error led to a complete system compromise. Another reminder that even "ancient" technologies can still pose a real threat if they remain operational in production.
Immediately after the information about the vulnerability was published, the research team deployed honeypot sensors to track actual exploitation attempts. The attackers did not keep waiting. During 18 hours of observation, 60 hacking attempts were recorded from 18 unique sources. (the key to connect to is specified, and iroh finds the associated host and establishes an encrypted connection using the QUIC protocol). Direct P2P connections are established whenever possible, but if not, it falls back to using relays, which are also employed for host discovery by keys. You can run your own relay or connect to public relays supported by the community.. According to Censys, around three thousand systems worldwide were found to be potentially vulnerable, although a significant portion of them were likely honeypot traps as well.
Analysis of the intercepted traffic painted a rather colorful picture. The most active attacker was from the address 178.16.53.82, who conducted 12 sessions against 10 different targets. Their actions were fully automated: upon gaining access, a standard set of reconnaissance commands such as uname -a, id, reading /proc/cpuinfo, and /etc/passwd were executed. A notable feature was the wrapping of command outputs with special markers for subsequent parsing, clearly indicating a botnet or an automated data collection system.
A more sophisticated attacker was identified at the address 216.106.186.24. They focused on a specific subnet and attempted to establish an SSH key for persistent access, as well as upload and execute a Python script from an external server — presumably, malware for cryptocurrency mining or a botnet. However, both attempts failed: the target system did not have a .ssh directory, and curl and python were also absent.
Particular interest lies in two attackers from addresses 167.172.111.135 and 165.22.30.48. Unlike the others, they did not attempt to gain root access immediately, but rather experimented with the accounts nobody, daemon, and even the non-existent nonexistent123. The delays between sessions and the logic of their actions suggest a real person behind the keyboard. They are likely more experienced hackers who are aware of intrusion detection systems and possess privilege escalation techniques.
Some attackers displayed remarkable negligence in operational security. For example, an intruder from the address 67.220.95.16 used the same IP for both exploitation and hosting a server with malicious software. Others accidentally exposed their hostnames through the DISPLAY variable: one operated from a system named MiniBear, another from a virtual machine shared-vm2.localdomain, and a third directly connected from a full graphical environment of Kali Linux.
Overall, the level of attackers was quite low. Out of 18 attack sources, only a few showed signs of professionalism. Most used basic automated tools or just prodded at the keyboard, following instructions from the internet. The Suricata intrusion detection system successfully detected the moment one of the attackers gained root access, further confirming the importance of multi-layer security and monitoring of network traffic.
Researchers note that this vulnerability, on one hand, provided amateur hackers an opportunity to practice, while on the other, allowed security specialists to gather valuable data on current tactics and tools of malicious actors.
Learn more: https://www.securitylab.ru/news/568478.php
Source: linux.org.ru
