Hi Ron Ben Yizhak,
On Thu, Feb 05, 2026 at 02:39:57PM +0200, Ron Ben Yizhak via Bug reports for
the GNU Internet utilities wrote:
>
> My name is Ron Ben Yizhak and I am a security researcher from SafeBreach.
>
> I want to report a severe vulnerability that I found in telnetd from the
> repository https://codeberg.org/inetutils/inetutils
>
> [...] However the research on CVE-2026-24061 revealed that telnetd
> allows clients to set environment variables for the telnetd process
> itself and for all its sub processes. One of its processes as we know
> from CVE-2026-24061, is /usr/bin/login.
>
> This is the root cause of the vulnerability I’m reporting to
> you. Setting environment variables as a remote telnet client
> enables us to spawn /usr/bin/login with the environment variable
> “CREDENTIALS_DIRECTORY”. This will make the process search
> for a file named “login.noauth” in the directory specified by
> “CREDENTIALS_DIRECTORY”. If the file contains the string “yes”,
> login will skip the authentication and provide a shell for the client
> running as the user the client specified. It can be any user, even root.
>
> https://github.com/util-linux/util-linux/blob/master/login-utils/login.c#L1306
The first regular util-linux release to contain this new authentication
bypass method seems to be 2.40. According to the release notes, it was
added for some systemd functionality.
> Attached to this mail is a video demonstrating the vulnerability on a fully
> patched ubuntu 25 machine with the latest telnetd. Also attached is a
> script to test this vulnerability
I did not watch the video, nor try out the script, but the method seems to
be plausible, because a Telnet client can send any environment variable to
a Telnet server, and GNU Inetutils' Telnet server does not restrict this.
The GNU Inetutils Telnet client can set arbitrary environment variables
that are sent to the Telnet server:
$ ./telnet
telnet> environ define CREDENTIALS_DIRECTORY /attacker/controlled/value
I confirmed that this is sent and present in the environment used when
executing "login" by using "--exec-login=/usr/bin/env".
I do not know how to address this problem properly, but a quick and dirty
hack that should stop this method is contained in the attached patch.
I have tested it with the above mentioned method only.
Assuming current util-linux "login" can be tricked to accept an
authentication bypass instruction from a file controlled by a non-root
user via CREDENTIALS_DIRECTORY, this could affect recent GNU/Linux
systems.
A possible workaround would be to use an older version of "login".
> [...]
Cheers,
Erik
--
To a first approximation, we can say that accidents are almost always
the result of incorrect estimates of the likelihood of one or more things.
-- C. Michael Holloway, NASA
diff --git a/telnetd/pty.c b/telnetd/pty.c
index c727e7be..f3518049 100644
--- a/telnetd/pty.c
+++ b/telnetd/pty.c
@@ -129,6 +129,14 @@ start_login (char *host, int autologin, char *name)
if (!cmd)
fatal (net, "can't expand login command line");
argcv_get (cmd, "", &argc, &argv);
+
+ /* util-linux's "login" introduced an authentication bypass method
+ * via environment variable "CREDENTIALS_DIRECTORY" in version 2.40.
+ * Clear it from the environment before executing "login" to prevent
+ * abuse via Telnet.
+ */
+ unsetenv ("CREDENTIALS_DIRECTORY");
+
execv (argv[0], argv);
syslog (LOG_ERR, "%s: %m\n", cmd);
fatalperror (net, cmd);
