Re: Telnetd Vulnerability Report

--0000000000001dd4cb064aa0638a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Ron Ben Yizhak <ron.benyizhak@safeb=
reach.com>
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 clien=
t
> will only apply on the shell process and only after the client has alread=
y
> 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=E2=80=AFAM Erik Auerswald <auerswal@unix-ag.=
uni-kl.de>
> 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.t=
xt
>> [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
>>
>

--0000000000001dd4cb064aa0638a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,<div><br></div><div>Following this rep=
ort, I wanted to ask - do you have any estimation for a fix release date, a=
nd a CVE release?</div><div><br></div><div>Best regards,</div><div>Ron Ben =
Yizhak</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 9, 2026 at 11:37=E2=80=AFAM R=
on Ben Yizhak &lt;<a href=3D"mailto:[email protected]">ron.benyi=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr">Hello,<div><br></div><div>Thank you for=
 consulting=C2=A0with me. As a vulnerability researcher, I do not want to t=
ake responsibility for the effectiveness of the fix.</div><div>With that be=
ing=C2=A0said, In my opinion the proposed fix will stop this exploit, but t=
he main issue stays. The issue exists as long as unauthenticated clients ca=
n set arbitrary environment variables in the memory of telnetd and its sub =
processes.</div><div>The best solution will be that the environment variabl=
es set by the client will only apply on the shell process and only after th=
e client has already authenticated. No process running as root should run w=
ith any environment variables set by the client.</div><div><br></div><div>B=
est regards,</div><div>Ron Ben Yizhak</div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 9, 2026 at 11:21=E2=
=80=AFAM Erik Auerswald &lt;<a href=3D"mailto:[email protected]" t=
arget=3D"_blank">[email protected]</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">Hi Ron Ben Yizhak,<br>
<br>
On Fri, Feb 06, 2026 at 06:27:30PM +0100, Erik Auerswald wrote:<br>
&gt; On Thu, Feb 05, 2026 at 02:39:57PM +0200, Ron Ben Yizhak via Bug repor=
ts for the GNU Internet utilities wrote:<br>
&gt; &gt; <br>
&gt; &gt; My name is Ron Ben Yizhak and I am a security researcher from Saf=
eBreach.<br>
&gt; &gt; <br>
&gt; &gt; I want to report a severe vulnerability that I found in telnetd f=
rom the<br>
&gt; &gt; repository <a href=3D"https://codeberg.org/inetutils/inetutils" r=
el=3D"noreferrer" target=3D"_blank">https://codeberg.org/inetutils/inetutil=
s</a><br>
&gt; &gt; [...]<br>
&gt; <br>
&gt; [...] a quick and dirty hack that should stop this method is contained=
<br>
&gt; in the attached patch.=C2=A0 I have tested it with the above mentioned=
<br>
&gt; method only.<br>
<br>
Can you confirm that the patch[0] from my previous message[1] stops<br>
the exploit?<br>
<br>
[0] <a href=3D"https://lists.gnu.org/archive/html/bug-inetutils/2026-02/txt=
5Lp7CdbQkO.txt" rel=3D"noreferrer" target=3D"_blank">https://lists.gnu.org/=
archive/html/bug-inetutils/2026-02/txt5Lp7CdbQkO.txt</a><br>
[1] <a href=3D"https://lists.gnu.org/archive/html/bug-inetutils/2026-02/msg=
00001.html" rel=3D"noreferrer" target=3D"_blank">https://lists.gnu.org/arch=
ive/html/bug-inetutils/2026-02/msg00001.html</a><br>
<br>
&gt; [...]<br>
&gt; A possible workaround would be to use an older version of &quot;login&=
quot;.<br>
<br>
Another possible workaround would be to wrap &quot;login&quot; execution wi=
th<br>
&quot;env&quot;, and use &quot;env&quot; to unset the problematic environme=
nt variable<br>
&quot;CREDENTIALS_DIRECTORY&quot;.=C2=A0 The inetd.conf line could look as =
below:<br>
<br>
telnet stream tcp nowait root /usr/local/libexec/telnetd telnetd --exec-log=
in &quot;/usr/bin/env -u CREDENTIALS_DIRECTORY /usr/bin/login -p -h %h %?u{=
-f -- %u}{-- %U}&quot;<br>
<br>
Can you confirm that this stops the exploit?<br>
<br>
Thanks,<br>
Erik<br>
</blockquote></div>
</blockquote></div></div>

--0000000000001dd4cb064aa0638a--