Never mind telnetd. Tier 1 transit providers doing port filtering is EXTREMELY alarming. They have partitioned the Internet, and in a way that automatic routing (BGP) can't get around.
> Tier 1 transit providers doing port filtering is EXTREMELY alarming.
I was admining a small ISP when blaster and its variants hit. Port filtering 139 and the rest was the easiest way to deal with it, and almost over night most of the ISPs blocked it, and we were better for it. There was a time when if you'd put a fresh XP install on the Internet you'd get 5-10 minutes until it would get restarted.
I guess if you're really an admin that needs telnet, you can move it to another port and go around it? Surely you'd tunnel that "old box that needs to stay alive" if that's the usecase? Is there anyone seriously running default telnet on 23 and is really affected by this filtering?
I do not know what is more critical: the risk of censorship or stand by while hospitals, banking, nuclear power plants and other systems become compromised and go down with people dying because of it. These decision makers not only have powers but also have a responsibility
Port 23 has been filtered by most providers for decades.
This is why everything converges on using TLS over 443 or a high port number. I don't see this as a huge deal, and especially not one deserving all caps rants about censorship. Save those for things like FOSTA/SESTA.
not to mention, filtering on udp vs tcp, which makes using anything else impossible. Not that I have one, but it's just a bit in a field, why filter on it?
What an amazing bug. I probably spent my first 10 years on the internet just using telnet. They were wild times. You could log ethernet traffic and see passwords. Towards the end of those we started to have a few more single-user machines, but the vast majority were old school many many user machines, where "root" was thought to be tightly restricted (of course, even then, in practice it wasn't if you were in the know).
I never sent root over telnet, but I spent too much vacation time browsing the web via lynx on my school AIX account from a library near my parents' home, because it had a telnet client in addition to the card catalogue program on the otherwise locked down desktop. It was just a more innocent time: you didn't assume your traffic was being logged six ways to Sunday. With telnet access to my AIX account, I could do all the internet things, like mail (pine) and the web (lynx) and irc, from a convenient command line anywhere in the world.
When did we all stop using telnet? I can't even remember. Most of my first 10-15 years was using telnet. One day I used telnet to connect to a shell for the last time and didn't know it. I had a ton of servers all with root telnet access Internet facing. Never hacked once, somehow. Those were the days.
It's hilarious, especially given that I have memories of similar rlogin vulnerabilities -- various unixes being vulnerable to rlogin -l '-froot' in the 90s.
Never used telnet to log in to something but it is a cool debugging tool, so used it for that. E.g. can this container even send traffic to that container at all.
So Telnet as a client is not dead though, right? A long time ago, I used to use the Telnet client to talk to SMTP servers (on port 25) and send spoofed emails to friends for fun.
With port blocking widening in scope, I’ve long believed that we would one day have every service and protocol listening on port 443. Since all other ports are being knocked off in the name of security, we’ll end up having one port that makes port based filtering useless.
I don’t remember how I did it but when I was about 12 years old I somehow managed to send SMS from Telnet to cell phones, and to the receiver they appeared to be sent by an official Telecom account - good that I was still an innocent child, had I discovered this a few years later I may have tried doing something nefarious with it.
None of this affects the use of telnet the client program nor the ability to run a telnetd on your own host (but do be sure it's patched!).
What's happened is that global routing on the internet (or big chunks of it, it's not really clear) has started blocking telnet's default port to protect presumably-unpatched/unpatchable dinosaur systems from automated attack. So you can no longer (probably) rely on getting to a SMTP server to deliver that spoofed email unless you can do it from its own local environment.
(Remember hearing about this a long time ago (from some searching I think it was in 1999 via Slashdot) and verified some instance of it still exists/works.)
Telnet is used in legacy, IoT, embedded, and low-level industrial hardware. It's also intentionally enabled on devices where automation was written for telnet and it wasn't easy to switch to ssh.
If you investigate most commercial uses of ssh, the security is disabled or ignored. Nobody verifies host keys, and with automation where hosts cycle, you basically have to disable verification as there's no easy way around the host keys constantly changing. Without host key verification, there's kinda no point to the rest.
Even assuming the host keys were verified, the popular ssh conventions are to use either long-lived static keys (and almost nobody puts a password on theirs), or a password. Very few people use SSH with 2FA, and almost no-one uses ephemeral keys (OIDC) or certificates (which many people screw up).
So in terms of how people actually use it, SSH is one of the least secure transport methods. You'd be much more secure by using telnet over an HTTPS websocket with OAuth for login.
Probably one of the reasons this bug survived so long is that it isn't used much for priveleged access any more, but so you can play a moo or play you an ASCII movie, as people below you are replying.
On the bright side that CVE seems like pretty great news for the hardware hacking community hoping to get root on embedded devices which have open telnetd.
> Someone upstream of a significant chunk of the internet’s transit infrastructure apparently decided telnet traffic isn’t worth carrying anymore. That’s probably the right call.
Does this impact traffic for MUDs at all? I know several MUDs operate on nonstandard Telnet ports, but many still allow connection on port 23. Does this block end-to-end Telnet traffic, or does it only block attempts to access Telnet services on the backbone relays themselves?
MUDs use plaintext TCP protocols that are accessible to a wide range of clients.
The Telnet protocol is well-defined and not completely plaintext. There are in-band signaling methods and negotiations. Telnet is defined to live on 23/tcp as an IANA well-known, privileged, reserved port.
MUDs do none of this. You can usually connect to a MUD using a Telnet client, but most players hate the experience and often deride this method in favor of a dedicated, programmable client.
The fact that MUDs inhabit higher 4-digit ports is an artifact from their beginnings as unprivileged, user-run servers without a standardized protocol or an assigned “well-known port” presence. If you want your MUD to be particularly inaccessible, you could certainly run on port 23 now!
When I was an intern for some reason they issued me a voip phone for my desk. One day I got bored and figured out I could telnet into it. Nothing interesting but it was still a fun moment for me!
A very very long time ago as an intern I was working on a perl cgi script and I would often test it with telnet. I was used to messing around with hayes commands so manually typing in HTTP commands seemed like a natural extension of that.
Wouldn't attention to getenv() calls yield more benefit? Such calls are where input typically isn't parsed--because parsing is "hard"--becoming targets for exploit.
The present fix is to sanitize user input. Does it cover all cases?
An RCE in GNU's telnetd has no relationship to the sunsetting of telnet. Something could equally likely happen with SSH (but not really because the OpenBSD folks are paranoid by nature).
Apple removing the telnet client from OS X was a stupid move. How can you call yourself UNIX and not have a telnet client? It's like removing grep or ed.
Am I the only one who feels like it isn't the responsibility of backbone ISPs to filter traffic like this? In the case of a DDoS situation I could get behind it, but in this case I feel as though it's not Cogent's problem if I want to use telnet from a device on Charter's network to a Vultr VPS, even if it may be ill-advised.
(Of course, the article only speculates that this traffic filtering is what's going on; there isn't any hard proof, but it feels plausible to me.)
It should be possible to get a better idea where the filtering happens with a tool like tcptraceroute (possibly patched to use other segments beyond the default TCP SYN).
I haven't found evidence of extremely widespread filtering. Why would there be? The installation count is not that high. The potential side effects from uncoordinated port filtering could be quite severe. This isn't netkit's telnetd or Busybox. (I'm aware of Debian switching defaults, but that was fairly recently.)
Kind of "funny" affected service is BGP RouteViews CLI access, still running over telnet: https://archive.routeviews.org/ (scroll to bottom of the page)
Isn't this one of the remaining, "legit" uses of the Telnet protocol on TCP/23 port over the public Internet?
I'm slightly taken aback by the telnetd fix: The solution to the username "-f root" being interpreted as two arguments to /usr/bin/login is to add a "sanitize" function, really? I'm not seeing the sense in that. Surely in any case where the sanitize functions changes something, the login will fail. Better to error out early than to sanitize and try to hobble along.
What I'd like to know is how the arguments get interpreted like that in the first place. If I try giving that kind of argument /usr/bin/login directly, its argument parser chides me:
$ login '-f root'
login: illegal option --
What's telnetd doing differently? Is it invoking login via a shell?
You passed '-f root' to login (a single long string). telnetd is likely passing '-f' 'root' to login (two arguments instead of one, whether this is because it creates two, or it uses the shell (which then reparses) I don't know).
But '-f' is a valid option to login (man login):
login [-p] [-h host] [-H] [-f username|username]
...
-f Used to skip a login authentication. This option is usually used by the getty(8) autologin feature.
For about 15 years beginning in 2003 I had some VPSs with CrystalTech/NewTek. I noticed right away that they had blocked all port 23 traffic in/out of their edge.
I asked them about it and they said it was a security measure. Apparently they used telnet for managing their routers.
It turned out that they did not have very good security anyway.
The design of telnet and ssh where you have a daemon running as root is bad security that as shown here is a liability, a ticking time bomb ready to give attackers root.
Oldschool telnetd didn’t actually run as root; rather, it just set up a PTY for the incoming socket to talk to, and then fork-exec’ed a /bin/login subprocess to live inside that pty. /bin/login is setuid-root, so it’s “where the security lived.”
I think we all collectively decided that that was a bad idea at some point — probably because /bin/login was never designed under the assumption that it would have to deal with arbitrary binary network traffic being thrown at it (it really only expects keyboard input.) So we switched to doing auth directly in our network daemons, since at least then “people who are aware the code is network-facing” would be maintaining it.
Since Tier 1 transit providers have now blocked telnet (port 23), this means the death of watching ASCII Star Wars with `telnet towel.blinkenlights.nl`
However, if you still long for nostalgia, I was able to access it over IPv6 using a VPN based in the Netherlands:
telnet 2001:7b8:666:ffff::1:42
I'm sure the port 23 telnet blocking will be coming to IPv6 soon though.
Interesting... I hadn't been watching, but I average around 2000 unique IPs for telnet... there was a brief 7500 IP spike in the middle of January, but it was short lived. There was a smaller blip just at the end of January, but going into February it's actually down around 1000.
1. TELNET is an IETF-standard protocol defined by RFCs.
2. Telnet is a well-known port assigned by the IANA (tcp/23).
3. telnet is a client program, originated on Unix, available on many systems, and likely from a quite homogeneous codebase.
4. telnetd is a server program, also originated on Unix for the purpose of implementing Telnet protocol as a login server. Also a homogeneous codebase or two.
TFA is about items 2 and 4, and 1/3 are completely unrelated.
IIRC, the only traffic that was monitored and detected here is the scanning. The vulnerability scanners that try and detect, for better or worse, what someone's running on port 23, fingerprint it, and figure out if it's a vulnerability.
Interestingly, filtering port 23 only mitigates the CVE by happenstance. It is merely by convention that telnetd runs on port 23, so that people can use it to log in remotely. There is no constraint that requires port 23. Any other service could usurp 23/tcp for itself if the admin decrees it. So, filtering port 23 is an effective mitigation for the defaults of someone running a vulnerable server on the standard port. But it is not a panacea, and it doesn't prevent anyone from using the telnetd server, or the telnet client, except for port 23.
But it also prevents you from offering any service on port 23/tcp, lest it be filtered. You wouldn't want to run a web server, sshd, a MUD, or anything else, because your connectivity would be negatively impacted for this reason. (The common experience is that a lot of Windows SMB/NetBIOS ports are blocked, and SMTP and port 80, on a lot of consumer ISPs, although this is contrasting the ISP situation to Tier-1 transit carriers now.)
...except that port 23 seems to now be filtered across the internet at large, leading to a huge drop-off in telnet traffic over the course of days if not hours. I think it's safe to say that even if you patch telnetd, being able to use telnet over the internet is not possible in many places (including Canada, according to the data).
Am I the only one who finds this suspicious ? About Telnetd “…The vulnerable code was introduced in a 2015 commit and sat undiscovered for nearly 11 years.”
Okay, it is really weird. This was not an exploit difficult to pull off, or discover. It is such an elementary error that any script kiddie could have leveraged it anywhere, once it was understood.
Is there proof or evidence that it was never exploited in all of 10 years and remained as a latent zero-day?
The only saving grace I would propose, is that since telnetd has been aggressively deprecated once ssh became popular, and encryption became ubiquitous, and remote exploits became commonplace, and Starbucks WiFi was routinely surveilled, that telnetd simply wasn't running anywhere, anymore.
We have commenters saying that embedded systems and IoT used telnet servers. But were they running an actual GNU telnetd or just a management interface that answered on port 23/tcp? Commenters are citing statistics of "open port 23", but that means nothing in terms of this CVE, if it ain't GNU telnetd. Cisco has literally always used port 23 for management. Other routers and network devices use port 23 without telnetd.
How popular was GNU telnetd to be running on a system and exposed to the Internet? This article pertains to all the port-scanners running everywhere, so surely someone with a Shodan account can make a survey and tell us: who was still exposing GNU telnetd in 2026?
The difference between "telnet" the program and "telnet" the protocol is especially important in this discussion, I think.
A more "proper" tool for that is netcat -- I doubt SMTP supports the Telnet option negotiations subsystem. (I also doubt SMTP servers can interpret the full suite of Network Virtual Terminal (NVT) commands that the Telnet protocol supports.) There's clearly enough similarity between the two protocols that if you're just using it to transfer plaintext it will probably work out fine, but they are distinct protocols.
I used telnet(1) as a generic TCP text client for many years before switching to GNU/BSD netcat. Nowadays, netcat is more prominent then telnet, and telnet had its corner cases with control characters.
You want nc (usually with -v) or socat. telnet is muscle memory for a lot of people (myself included sometimes) but it's a strictly inferior choice these days for poking arbitrary plaintext services.
I think it would be better suited to use the terms we use for natural languages. A natural language is dead when the last person who learned it as first language dies and are extinct when there is noone that would speak it at all.
In these terms, telnet has been dead for a long while, but it's extinct now.
The most interesting thing here isn't the CVE - it's the invisible coordination. A backbone provider acted on advance knowledge of a critical flaw, implemented filtering at scale, and the rest of us didn't notice until GreyNoise's data showed the drop. The vulnerability got patched at the network layer before it ever reached the application layer. This is what mature security ecosystems look like - the boring, quiet fixes that happen before the press release.
Some comments were deferred for faster rendering.
virgulino|20 days ago
NitpickLawyer|20 days ago
I was admining a small ISP when blaster and its variants hit. Port filtering 139 and the rest was the easiest way to deal with it, and almost over night most of the ISPs blocked it, and we were better for it. There was a time when if you'd put a fresh XP install on the Internet you'd get 5-10 minutes until it would get restarted.
I guess if you're really an admin that needs telnet, you can move it to another port and go around it? Surely you'd tunnel that "old box that needs to stay alive" if that's the usecase? Is there anyone seriously running default telnet on 23 and is really affected by this filtering?
oaiey|20 days ago
ericpauley|19 days ago
pjc50|20 days ago
This is why everything converges on using TLS over 443 or a high port number. I don't see this as a huge deal, and especially not one deserving all caps rants about censorship. Save those for things like FOSTA/SESTA.
acters|20 days ago
fragmede|20 days ago
worksformeintx|19 days ago
Quarrel|20 days ago
Anyway, just wild seeing this:
> telnet -l 'root -f' server.test
or
> USER='-f root' telnet -a server.test
Survive 11 years.
anitil|20 days ago
Telemakhos|20 days ago
qingcharles|20 days ago
mlyle|20 days ago
wellf|20 days ago
AnonHP|20 days ago
With port blocking widening in scope, I’ve long believed that we would one day have every service and protocol listening on port 443. Since all other ports are being knocked off in the name of security, we’ll end up having one port that makes port based filtering useless.
mmh0000|20 days ago
As are many other tools. But the ones above are basically far better direct telnet alternatives.
dudefeliciano|19 days ago
ajross|20 days ago
What's happened is that global routing on the internet (or big chunks of it, it's not really clear) has started blocking telnet's default port to protect presumably-unpatched/unpatchable dinosaur systems from automated attack. So you can no longer (probably) rely on getting to a SMTP server to deliver that spoofed email unless you can do it from its own local environment.
trebligdivad|20 days ago
(OK, I know one ancient talker that uses it - but on a very non-standard port so a port 23 block wouldn't be relevant)
jaredsohn|20 days ago
telnet towel.blinkenlights.nl https://www.youtube.com/watch?v=Mhcf6tc2jeQ
(Remember hearing about this a long time ago (from some searching I think it was in 1999 via Slashdot) and verified some instance of it still exists/works.)
0xbadcafebee|20 days ago
If you investigate most commercial uses of ssh, the security is disabled or ignored. Nobody verifies host keys, and with automation where hosts cycle, you basically have to disable verification as there's no easy way around the host keys constantly changing. Without host key verification, there's kinda no point to the rest.
Even assuming the host keys were verified, the popular ssh conventions are to use either long-lived static keys (and almost nobody puts a password on theirs), or a password. Very few people use SSH with 2FA, and almost no-one uses ephemeral keys (OIDC) or certificates (which many people screw up).
So in terms of how people actually use it, SSH is one of the least secure transport methods. You'd be much more secure by using telnet over an HTTPS websocket with OAuth for login.
iamnothere|20 days ago
IMHO we need a good telnet replacement that sends signed data. Most people interpret signatures as allowed under FCC rules, just not encryption.
rcakebread|20 days ago
mcpherrinm|20 days ago
myko|20 days ago
I really should update it to allow more secure options
VadimPR|19 days ago
semyonsh|20 days ago
omegaham|20 days ago
breve|20 days ago
unknown|20 days ago
[deleted]
para_parolu|20 days ago
Quarrel|20 days ago
Suzuran|19 days ago
thrance|19 days ago
unknown|20 days ago
[deleted]
VladVladikoff|20 days ago
josteink|20 days ago
It seems to use a different telnetd (busybox?), because from what I can tell it's not prone to this error.
Twisol|20 days ago
Does this impact traffic for MUDs at all? I know several MUDs operate on nonstandard Telnet ports, but many still allow connection on port 23. Does this block end-to-end Telnet traffic, or does it only block attempts to access Telnet services on the backbone relays themselves?
RupertSalt|20 days ago
MUDs use plaintext TCP protocols that are accessible to a wide range of clients.
The Telnet protocol is well-defined and not completely plaintext. There are in-band signaling methods and negotiations. Telnet is defined to live on 23/tcp as an IANA well-known, privileged, reserved port.
MUDs do none of this. You can usually connect to a MUD using a Telnet client, but most players hate the experience and often deride this method in favor of a dedicated, programmable client.
The fact that MUDs inhabit higher 4-digit ports is an artifact from their beginnings as unprivileged, user-run servers without a standardized protocol or an assigned “well-known port” presence. If you want your MUD to be particularly inaccessible, you could certainly run on port 23 now!
MBCook|20 days ago
Since Telnet is totally plain text that would absolutely be easy to do right?
Laforet|20 days ago
That said in this day and age, servers on the public network really ought to use SSH.
peteforde|20 days ago
It's crazy to think that some dude is singlehandedly responsible for ultimately ending the telnet era in such a definitive way.
One for the history books.
ycombinatrix|20 days ago
Well, one person to put up the PR and one dude to approve it - back in 2015. It isn't the security researcher's fault.
catskull|20 days ago
bentcorner|20 days ago
ekropotin|20 days ago
Animats|20 days ago
Who?
Where's the commit?
greyface-|20 days ago
Arubis|20 days ago
mmooss|20 days ago
Do you mean that it's intentional? Why do you think so?
parl_match|20 days ago
digitalPhonix|20 days ago
https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...
One of the changes is:
What is the reason for a rename these days? If I saw that in a code review I’d immediately get annoyed (and probably pay more attention)naniwaduni|20 days ago
unknown|20 days ago
[deleted]
ky3|20 days ago
The present fix is to sanitize user input. Does it cover all cases?
keyle|20 days ago
tosti|20 days ago
accrual|20 days ago
tokyobreakfast|20 days ago
Apple removing the telnet client from OS X was a stupid move. How can you call yourself UNIX and not have a telnet client? It's like removing grep or ed.
paulddraper|20 days ago
Ubuntu does not include it by default (starting 16.04?). Most most distros don't.
p_ing|20 days ago
badc0ffee|20 days ago
iberator|20 days ago
ps.
telnet SDF.org
just works...
jwpapi|20 days ago
snazz|20 days ago
(Of course, the article only speculates that this traffic filtering is what's going on; there isn't any hard proof, but it feels plausible to me.)
achillean|20 days ago
https://i.imgur.com/tZoTWu6.png
Still seeing a sizable number of open ports but it's on the decline.
fweimer|19 days ago
I haven't found evidence of extremely widespread filtering. Why would there be? The installation count is not that high. The potential side effects from uncoordinated port filtering could be quite severe. This isn't netkit's telnetd or Busybox. (I'm aware of Debian switching defaults, but that was fairly recently.)
pjf|19 days ago
Isn't this one of the remaining, "legit" uses of the Telnet protocol on TCP/23 port over the public Internet?
RonanSoleste|20 days ago
pbhjpbhj|20 days ago
munch117|19 days ago
What I'd like to know is how the arguments get interpreted like that in the first place. If I try giving that kind of argument /usr/bin/login directly, its argument parser chides me:
What's telnetd doing differently? Is it invoking login via a shell?pwg|19 days ago
But '-f' is a valid option to login (man login):
login [-p] [-h host] [-H] [-f username|username]
...
-f Used to skip a login authentication. This option is usually used by the getty(8) autologin feature.
anonymousiam|20 days ago
I asked them about it and they said it was a security measure. Apparently they used telnet for managing their routers.
It turned out that they did not have very good security anyway.
https://krebsonsecurity.com/2018/02/domain-theft-strands-tho...
I switched to A2 hosting shortly after the above incident, but I dumped them when they did not keep up to date on their Ubuntu LTS OS options.
I've been running on AWS for the past eight years. It costs more, but it's been extraordinarily reliable.
A2 and AWS do not restrict port 23.
VladVladikoff|20 days ago
achillean|19 days ago
https://www.shodan.io/search?query=port%3A23
Or to filter by product:telnetd
https://www.shodan.io/search?query=product%3Atelnetd
A query of "telnet" searches Shodan for banners where the "data" property contains the string "telnet":
https://book.shodan.io/getting-started/query-syntax/
gbacon|12 days ago
charcircuit|20 days ago
derefr|20 days ago
I think we all collectively decided that that was a bad idea at some point — probably because /bin/login was never designed under the assumption that it would have to deal with arbitrary binary network traffic being thrown at it (it really only expects keyboard input.) So we switched to doing auth directly in our network daemons, since at least then “people who are aware the code is network-facing” would be maintaining it.
direwolf20|20 days ago
nine_k|20 days ago
I suppose it could be via a proper PAM module, which is widely supported.
Too bad the first PAM RFC was published about the same time the first be version of ssh was released.
ikmckenz|20 days ago
est|20 days ago
btw if you want a quick telnet client, and an old python happens to be installed, you can use `python -m telnetlib IP`
varenc|20 days ago
However, if you still long for nostalgia, I was able to access it over IPv6 using a VPN based in the Netherlands:
I'm sure the port 23 telnet blocking will be coming to IPv6 soon though.atoav|20 days ago
pigggg|20 days ago
nubinetwork|19 days ago
jopython|20 days ago
RupertSalt|20 days ago
IIRC, the only traffic that was monitored and detected here is the scanning. The vulnerability scanners that try and detect, for better or worse, what someone's running on port 23, fingerprint it, and figure out if it's a vulnerability.
Interestingly, filtering port 23 only mitigates the CVE by happenstance. It is merely by convention that telnetd runs on port 23, so that people can use it to log in remotely. There is no constraint that requires port 23. Any other service could usurp 23/tcp for itself if the admin decrees it. So, filtering port 23 is an effective mitigation for the defaults of someone running a vulnerable server on the standard port. But it is not a panacea, and it doesn't prevent anyone from using the telnetd server, or the telnet client, except for port 23.
But it also prevents you from offering any service on port 23/tcp, lest it be filtered. You wouldn't want to run a web server, sshd, a MUD, or anything else, because your connectivity would be negatively impacted for this reason. (The common experience is that a lot of Windows SMB/NetBIOS ports are blocked, and SMTP and port 80, on a lot of consumer ISPs, although this is contrasting the ISP situation to Tier-1 transit carriers now.)
saulpw|20 days ago
Sparkyte|20 days ago
Fnoord|20 days ago
[1] nc (1) - arbitrary TCP and UDP connections and listens
[2] socat (1) - Multipurpose relay (SOcket CAT)
otterley|20 days ago
The modern replacement for telnet used in the "probe a port" fashion is nc/netcat.
erichanson|20 days ago
neom|20 days ago
jgalt212|19 days ago
I think about this quote a lot: given enough eyeballs, all bugs are shallow
davebranton|20 days ago
nephihaha|20 days ago
unknown|20 days ago
[deleted]
accrual|20 days ago
gzread|20 days ago
[deleted]
fortranfiend|19 days ago
pavelstoev|20 days ago
RupertSalt|20 days ago
Is there proof or evidence that it was never exploited in all of 10 years and remained as a latent zero-day?
The only saving grace I would propose, is that since telnetd has been aggressively deprecated once ssh became popular, and encryption became ubiquitous, and remote exploits became commonplace, and Starbucks WiFi was routinely surveilled, that telnetd simply wasn't running anywhere, anymore.
We have commenters saying that embedded systems and IoT used telnet servers. But were they running an actual GNU telnetd or just a management interface that answered on port 23/tcp? Commenters are citing statistics of "open port 23", but that means nothing in terms of this CVE, if it ain't GNU telnetd. Cisco has literally always used port 23 for management. Other routers and network devices use port 23 without telnetd.
How popular was GNU telnetd to be running on a system and exposed to the Internet? This article pertains to all the port-scanners running everywhere, so surely someone with a Shodan account can make a survey and tell us: who was still exposing GNU telnetd in 2026?
unknown|20 days ago
[deleted]
lofaszvanitt|20 days ago
fsmv|20 days ago
teddyh|19 days ago
adolph|20 days ago
RupertSalt|20 days ago
gerdesj|20 days ago
Twisol|20 days ago
A more "proper" tool for that is netcat -- I doubt SMTP supports the Telnet option negotiations subsystem. (I also doubt SMTP servers can interpret the full suite of Network Virtual Terminal (NVT) commands that the Telnet protocol supports.) There's clearly enough similarity between the two protocols that if you're just using it to transfer plaintext it will probably work out fine, but they are distinct protocols.
ktpsns|20 days ago
Never heard about https://jetmore.org/john/code/swaks/, thanks for the tip.
quotemstr|20 days ago
ozarkerD|20 days ago
lacunary|20 days ago
rballpug|20 days ago
gogasca|20 days ago
[deleted]
chenmx|20 days ago
[deleted]
prerok|20 days ago
In these terms, telnet has been dead for a long while, but it's extinct now.
clarkqaq|20 days ago
[deleted]
willmarquis|19 days ago
[deleted]
ubixar|20 days ago
Gigachad|20 days ago