Hi, Following this report, I wanted to ask - do you have any estimation for a fix release date, and a CVE release?
Best regards, Ron Ben Yizhak On Mon, Feb 9, 2026 at 11:37 AM Ron Ben Yizhak <[email protected]> wrote: > 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 >> >
