Hello, Thank you for consulting with me. As a vulnerability researcher, I do not want to take responsibility for the effectiveness of the fix. With that being said, In my opinion the proposed fix will stop this exploit, but the main issue stays. The issue exists as long as unauthenticated clients can set arbitrary environment variables in the memory of telnetd and its sub processes. The best solution will be that the environment variables set by the client will only apply on the shell process and only after the client has already authenticated. No process running as root should run with any environment variables set by the client.
Best regards, Ron Ben Yizhak On Mon, Feb 9, 2026 at 11:21 AM Erik Auerswald <[email protected]> wrote: > Hi Ron Ben Yizhak, > > On Fri, Feb 06, 2026 at 06:27:30PM +0100, Erik Auerswald wrote: > > 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 > > > [...] > > > > [...] 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. > > Can you confirm that the patch[0] from my previous message[1] stops > the exploit? > > [0] > https://lists.gnu.org/archive/html/bug-inetutils/2026-02/txt5Lp7CdbQkO.txt > [1] https://lists.gnu.org/archive/html/bug-inetutils/2026-02/msg00001.html > > > [...] > > A possible workaround would be to use an older version of "login". > > Another possible workaround would be to wrap "login" execution with > "env", and use "env" to unset the problematic environment variable > "CREDENTIALS_DIRECTORY". The inetd.conf line could look as below: > > telnet stream tcp nowait root /usr/local/libexec/telnetd telnetd > --exec-login "/usr/bin/env -u CREDENTIALS_DIRECTORY /usr/bin/login -p -h %h > %?u{-f -- %u}{-- %U}" > > Can you confirm that this stops the exploit? > > Thanks, > Erik >
