Critical failure CVE-2026-24061 in GNU InetUtils Telnetd allows to avoid authentication and get root access after almost 11 years

A critical failure in the GNU InetUtils telnet demon has come to light after remaining unnoticed for almost 11 years. Catalysed as CVE-2026-24061 and with a severity score of 9.8 over 10 on the CVSS scale, this problem allows you to avoid the authentication process and get access with root privileges in affected systems.

Telnet is the program that accepts Telnet connections and serves as a bridge to log in to a remote system; although the Telnet protocol is old and without encryption, it is still used in some embedded environments and management networks where the basic simplicity over safety. The vulnerability discovered lies in the way telnetd transmits the USER environment variable to the binary/ usr / bin / loginwithout proper cleaning. The demon literally passes the content it receives from the client as the last login argument, and if that content is interpreted as a valid login option, it can change its behavior.

In particular, if a customer sends the chain "-f root" as USER value and uses the telnet client option that sends environment variables (e.g.-aor--login), the login process receives that chain and interprets it as the option-f, which instructs login to mark the specified user as already authenticated. The result is a direct entry as root without password being requested, which explains why the bug classification is so high.

The source of the problem can be traced to a change in the code made on March 19, 2015, which ended up being part of the 1.9.3 version released in May of that same year. The discovery was recently reported by the researcher identified as Kyu Neushwaisstein (also known as Carlos Cortes Alvarez) and publicly communicated by GNU collaborator Simon Josefsson on the mailing list oss-security. The official NIST entry describes the problem and classifies it as a vulnerability that allows remote authentication to be avoided; it can be found in the vulnerability database in NVD - CVE-2026-24061.

For managers and security officials there are two clear messages: first, check if your environment runs affected versions of GNU InetUtils (from 1.9.3 to 2.7 inclusive); second, apply patches or update to a corrected version as soon as they are available. The GNU Inetutils project page provides information about the software and its components in GNU Inetutils and the manual of telnetd helps you understand the expected behavior of the demon.

As immediate and palliative solutions, it is advisable to restrict access to the Telnet port by firewall rules or access control lists, disable the telnetd service when it is not necessary and, if necessary, configure it to use a login version that does not allow the option-for that it strictly validates its arguments. Another temporary alternative is to replace the log binary with a wrapper that filters the USER variable before calling it. These measures reduce exposure while providing final updates.

Beyond the patch and technical countermeasures, the systems should be audited for signs of exploitation. Review access records and log-in records, check audit files and search for newly created processes or accounts with high privileges are required actions if the system is suspected to have been violated. In environments with telemetry or IDS / IPS, creating specific signatures or rules to detect suspicious chains sent in environment variables can help identify exploitative attempts.

Indicators of activity have already been observed in nature. The GreyNoise threat intelligence firm records attempts at this exploitation: in the last 24 hours, 21 different IP addresses were detected trying to exploit the bypass using the option.-fon telnetd, and these PIs come from several countries and have been marked as malicious. The data and visualizations of these events are available on the GreyNoise panel at GreyNoise - attempts detected and in public consultations GreyNoise - IP details.

This incident highlights two important lessons: on the one hand, how an apparently safe code line and insufficient validation can become a serious gap that lasts years; on the other, the need to reduce the dependence on unsafe design services, such as Telnet, for alternatives that offer encryption and modern controls, for example SSH. In the short term, applying patches and limiting network access are the best defenses. In the medium and long term, planning migration out of obsolete services and strengthening code review and security testing practices will help prevent similar errors from remaining undetected for so long.

To be kept informed and access the technical references mentioned in this article: the description of the failure and its assessment in NVD is in NVD - CVE-2026-24061, technical discussion and notification in the oss-security list appears in oss-security, the commitment that introduced the change is available in the repository in Codeborg - commitment of the 19-mar-2015 and to continue public exploitation, the GreyNoise telemetry can be consulted at GreyNoise. If you manage systems that could be affected, prioritise the mitigation and forensic check before reactivating any disable service.