**

11-Year-Old Critical Telnetd Flaw Found in GNU InetUtils (CVE-2026-24061)

**

A critical vulnerability, tracked as CVE-2026-24061 with a CVSS score of 9.8, has been discovered in the GNU InetUtils telnet daemon (telnetd). This flaw affects all versions from 1.9.3 to 2.7 and had gone unnoticed for nearly 11 years.

The vulnerability allows an attacker to gain root access on affected systems. Telnetd is a server implementing the DARPA Telnet protocol, typically launched by inetd to handle connections on the Telnet port, with options to run manually in debug mode or on alternate TCP ports.

According to security researcher Kyu Neushwaistein (aka Carlos Cortes Alvarez), who reported the flaw on January 19, 2026, the telnetd server invokes /usr/bin/login (normally running as root) passing the value of the USER environment variable received from the client as the last parameter.

However, if the client supplies a carefully crafted USER environment value being the string “-f root”, and passes the telnet(1) -a or –login parameter to send this USER environment to the server, the client will be automatically logged in as root bypassing normal authentication processes.

This happens because the telnetd server does not sanitize the USER environment variable before passing it on to login(1), and login(1) uses the -f parameter to by-pass normal authentication. This flaw remained undiscovered for nearly 11 years, posing long-standing security risks.

The vulnerability was introduced as part of a source code commit made on March 19, 2015. To mitigate the flaw, apply the latest patches and restrict access to the telnet service to trusted clients. Disable the telnetd server if possible, or configure it to use a custom login tool that prevents use of the “-f” option.

Cybersecurity firm GreyNoise has already observed exploitation attempts for this flaw. It is essential to take immediate action to protect your systems from this critical vulnerability.

**Recommendations:**

  • Affected users should apply the latest patches as soon as possible.
  • Restrict access to the telnet service to trusted clients.
  • Disable the telnetd server if possible, or configure it to use a custom login tool that prevents use of the “-f” option.

**Follow me on social media for the latest news and updates:** Twitter: @securityaffairs, Facebook, and Mastodon.