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?
Lots of text games - MUDs - still play over telnet using dedicated MUD clients that implement their own telnet stack. Outright blocking the port has an outsized side efffe on them, this is simply not right.
Changes like these lend even more credibility to the approach of putting everything on port 443 over TLS, and distinguishing protocols based on hostname / HTTP path.
The GP's concern isn't a practical one, it's ultimately about net neutrality. It's not the ISP's job to discriminate against traffic—it's their job to deliver it.
This may seem like a good idea, and frankly is likely a net-positive thing, but it is literally the definition of "ISP decides what apps its customers can and cannot use."
I share the concern and don't really like it either.
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
Have you ever seen a hospital, a bank, a power plan to expose telnetd to the public internet in the last 20 years? It should be extremely rare and should be addressed by company’s IT not by ISPs.
This feels more akin to discovering an alarming weakness in the concrete used to build those hospitals, banks and nuclear power plants – and society responding by grounding all flights to make sure people can't get to, and thus overstress, the floors of those hospitals, banks and nuclear power plants.
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.
I've never really understood why it's a thing to use a telnet client for transmitting text on a socket for purposes other than telnet. My understanding is that telnet is a proper protocol with escape sequences/etc, and even that HTTP/SMTP/etc require things like \r\n for line breaks. Are these protocols just... close enough that it's not a problem in practice for text data?
If it's alright to be pedantic, anyone with programming knowledge can do the same without these tools. What these offer is tried and tested secure code for client side needs, clear options and you don't need to hand roll code for.
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.
You would still be able to use the telnet client to connect to an SMTP server on TCP port 25, just not port 23, right? I don't think that part changed here.
(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.
How do you automate, for example, "HTTPS over websocket with OAuth", without providing some kind of hard-coded, static or otherwise persistent authentication credentials to the calling system in some form (either certificate based auth, OAuth credentials, etc.)?
The problem with IoT and embedded secrets isn't really a solved problem, from what I can tell. I'm not sure that OAuth exactly solves the problem here. Though all your comments about SSH (especially host verification) holds true.
Just honestly trying to understand the possible solution space to the IoT problem and automated (non-human) authorization.
Unless you manage to leak your private host/client SSH keys, this is close to being as secure as it gets.
I'd say that HTTPS (or TLS in general) is more problematic, since you need to trust numerous root CAs in machine/browser store. Sure, you can use certificate pinning, but that has the same issues as SSH host key verification.
The known_hosts file is verification of host keys. It's not verification of a host cert, which is a different thing. Most sshd instances are running on ad hoc hardware without the ability to associate them with someone a cert authority would be willing to authenticate.
Basically people running services that need cert-based authentication are already using TLS (or if they're using sshd they've locked it down appropriately). SSH is for your workstation and your RPi and whatnot.
> IMHO we need a good telnet replacement that sends signed data. Most people interpret signatures as allowed under FCC rules, just not encryption.
I know from bitter experience that IPsec is a “now you have two problems” kind of solution, but the Authentication Header is a thing and is supported by most (all?) implementations. Ham radio operators probably don’t have much use for the actual features of telnet compared to plain netcat, do they? (It’s mostly terminal feature negotiation and such.)
I've always used ssh to connect to it. And it's true that their port 23 is still open at last check. If you cannot reach port 23, and you irrationally hate ssh, you may use 14321 as an alternate.
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.
MUDs were my introduction to telnet- I grew up a university kid and had access to Wesleyan's minicomputer EAGLE.WESLEYAN.EDU running OpenVMS. I used it to telnet to CMU's TinyMUD and later other TinyMUDs around the country. I recall OpenVMS's telnet had a problem with newlines/carriage returns so all the text was staircased, so I ended up learning C and writing a MUD client. I still habitually use telnet today even if netcat and many other tools have replaced it.
All of that was foundational for my career and I still look back fondly on the technology of the time, which tended to be fairly "open" to exploration by curious-minded teenagers.
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!
As a MUD enthusiast of two decades, this is not accurate. Where are you getting this information?
Most MUDs implement RFC 854, and a number of non-standard Telnet option subnegotiation protocols have been adopted for compression (MCCP2), transmission of unrendered data (ATCP, GMCP, ZMP), and even a mechanism for enabling marking up the normal content using XML-style tags (MXP). These telopts build on the subnegotiation facility in standard Telnet, whose designers knew that the base protocol would be insufficient for many needs; there are a great number of IANA-controlled and standardized telopt codes that demonstrate this, and the MUD community has developed extensions using that same mechanism.
> 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.
I think you are confusing "telnet" the program with "telnet" the protocol. I am speaking here of the protocol, defined at base in RFC 854, for which "telnet" the program is but one particularly common implementation. You look at any of those "dedicated, programmable clients" and they will contain an implementation of RFC 854, probably also an implementation of RFC 1143 (which nails down the rules of subnegotiation in order to prevent negotiation loops), and an implementation of the RFCs for several standard telopts as well as non-standardized MUD community telopts. I can speak for the behavior of MUSHclient in especial regard here, though I am also familiar with the underlying Telnet nature of Mudlet, ZMud, and CMUD, not to mention my very own custom-made prototype client for which I very much needed to implement Telnet as described above.
Wouldn't that imply that >80% of all monitored telnet sessions were exploit attempts for the specific CVE in question? Even with the scale of modern botnets, that seems unrealistic for a single vuln that was undisclosed at the time.
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.
That's crazy. This is core business critical software but they just YOLO critical changes without any automated tests? this PR would be insta-rejected in the small SAAS shop I work at.
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.
Apple still includes uucp for some unknown reason.
The saving disk space argument makes no sense because telnet was one of the smaller binaries in /usr/bin.
Telnet continues to be widely used for select use cases and being told we're naughty by not including it feels punitive and just adds extra steps. What are you supposed to do, trash a $1m piece of industrial equipment because Apple wants to remind you Telnet is insecure?
New devices are still being released with Telnet where SSH is impractical or unnecessary.
Well, I mean, the first part is a song by Don McLean called American Pie. You might know that, unsure that everyone will pick it out though.
One of the most famous play choices at karaoke bars these days too. I think because the song is a long story, of sorts? But it's a terribly long song and I will leave to take a smoke break anytime it gets chosen. You're going to be there for a good 10 minutes before it concludes.
So maybe the AI prompt was something like, "take CVE-2026-24061 and compose a song lyric in the style of American Pie by Don Mclean". I wonder if you would get similar results with that prompt.
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.
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.)
Not the parent poster, but I also still use telnet. For me it's "Ancient", I have a few retired SPARC and PA-RISC boxes that run their period appropriate OSes as a hobby. Telnet/rlogin is the more reliable method to get into them remotely (just over the LAN).
They're on a LAN behind a NAT Router/Firewall, and I don't always keep them powered up (I'm not that insane) so I really don't have a concern for them.
Some of the more modern/high-performance examples I have run NetBSD with modern sshd and modern ciphers, but you can tell it's a bit of a workout for them.
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.
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.
I think a proper architecture would not even have a root account. The server would just expose an authenticated endpoint that allows for configuration and updates to be pushed for it.
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.
There is something poetic about telnet finally going quiet. It was never meant to survive this long, yet it outlasted entire generations of 'secure replacements' simply because it was simple and it worked. The real lesson is that protocols do not die when better alternatives arrive; they die when the last device running them gets unplugged.
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.
Even that's argued within linguistics. There are languages which survive for generations as secondary languages (especially trade languages as Swahili or Chinook Jargon appear to have been originally). Also some like Latin, Hebrew and Sanskrit which survive for centuries but not as native languages.
Not the original commenter, but I noticed it too. I guess it's hard since AI is trained on human content, so presumably humans write like this too, but a few that stood out to me:
> Five entire countries vanished from GreyNoise telnet data: Zimbabwe, Ukraine, Canada, Poland, and Egypt. Not reduced — zero.
> An attacker sends -f root as the username value, and login(1) obediently skips authentication, handing over a root shell. No credentials required. No user interaction.
> The GreyNoise Global Observation Grid recorded a sudden, sustained collapse in global telnet traffic — not a gradual decline, not scanner attrition, not a data pipeline problem, but a step function. One hour, ~74,000 sessions. The next, ~22,000.
> That kind of step function — propagating within a single hour window — reads as a configuration change on routing infrastructure, not behavioral drift in scanning populations.
(and I'm not just pointing these out because of the em dashes)
GPTZero (which is just another AI model that can have similar flaws and is definitely not infallible, but is at least another data point) rates my excerpts as 78% chance AI written, 22% chance of AI-human mix.
To me at least, the article still seems to be majority human-written, though.
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.)
I'm not sure I understand how this argument refutes the claim that this isn't about telnetd. There'd be no reason to respond to the vulnerability in the way they did if the vulnerability in telnetd hadn't existed and been exploited -- and the proof is that nobody ever did until 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).
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.
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?
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?
Lots of text games - MUDs - still play over telnet using dedicated MUD clients that implement their own telnet stack. Outright blocking the port has an outsized side efffe on them, this is simply not right.
1 reply →
Changes like these lend even more credibility to the approach of putting everything on port 443 over TLS, and distinguishing protocols based on hostname / HTTP path.
1 reply →
The GP's concern isn't a practical one, it's ultimately about net neutrality. It's not the ISP's job to discriminate against traffic—it's their job to deliver it.
This may seem like a good idea, and frankly is likely a net-positive thing, but it is literally the definition of "ISP decides what apps its customers can and cannot use."
I share the concern and don't really like it either.
3 replies →
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
Have you ever seen a hospital, a bank, a power plan to expose telnetd to the public internet in the last 20 years? It should be extremely rare and should be addressed by company’s IT not by ISPs.
2 replies →
This feels more akin to discovering an alarming weakness in the concrete used to build those hospitals, banks and nuclear power plants – and society responding by grounding all flights to make sure people can't get to, and thus overstress, the floors of those hospitals, banks and nuclear power plants.
6 replies →
Censorship is one of these words that get slapped on anything.
Filtering one port is not censorship. Not even close.
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.
[dead]
So basically the same as censorship because that is the exact same thing blocking ports does.
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).
Anyway, just wild seeing this:
> telnet -l 'root -f' server.test
or
> USER='-f root' telnet -a server.test
Survive 11 years.
The more I work in software, the more amazed I am that anything works at all. There's likely so much low hanging fruit out there
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.
netcat, socat and openssl s_client are all available for general manual connection testing.
As are many other tools. But the ones above are basically far better direct telnet alternatives.
I've never really understood why it's a thing to use a telnet client for transmitting text on a socket for purposes other than telnet. My understanding is that telnet is a proper protocol with escape sequences/etc, and even that HTTP/SMTP/etc require things like \r\n for line breaks. Are these protocols just... close enough that it's not a problem in practice for text data?
10 replies →
If it's alright to be pedantic, anyone with programming knowledge can do the same without these tools. What these offer is tried and tested secure code for client side needs, clear options and you don't need to hand roll code for.
2 replies →
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.
> started blocking telnet's default port
But that's 23 and smtp is 25.
2 replies →
You would still be able to use the telnet client to connect to an SMTP server on TCP port 25, just not port 23, right? I don't think that part changed here.
1 reply →
Why are people still using telnet across the internet in this century? Was this _all_ attack traffic?
(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)
To watch Star Wars in ASCII.
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.)
Maybe we should give the kind person who hosts it a break. Try it out tomorrow. (Yes, I should have thought of that before I tried.)
3 replies →
~~IIRC the blinkenlights telnet movies have been offline for a few years already.~~
1 reply →
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.
How do you automate, for example, "HTTPS over websocket with OAuth", without providing some kind of hard-coded, static or otherwise persistent authentication credentials to the calling system in some form (either certificate based auth, OAuth credentials, etc.)?
The problem with IoT and embedded secrets isn't really a solved problem, from what I can tell. I'm not sure that OAuth exactly solves the problem here. Though all your comments about SSH (especially host verification) holds true.
Just honestly trying to understand the possible solution space to the IoT problem and automated (non-human) authorization.
1 reply →
Unless you manage to leak your private host/client SSH keys, this is close to being as secure as it gets.
I'd say that HTTPS (or TLS in general) is more problematic, since you need to trust numerous root CAs in machine/browser store. Sure, you can use certificate pinning, but that has the same issues as SSH host key verification.
> Very few people use SSH with 2FA.
PCI DSS, HIPAA, and ISO 27001 each either highly recommend or enforce this.
I wouldn't use a jumphost without it.
> Nobody verifies host keys,
The known_hosts file is verification of host keys. It's not verification of a host cert, which is a different thing. Most sshd instances are running on ad hoc hardware without the ability to associate them with someone a cert authority would be willing to authenticate.
Basically people running services that need cert-based authentication are already using TLS (or if they're using sshd they've locked it down appropriately). SSH is for your workstation and your RPi and whatnot.
2 replies →
One reason would be to play MUDs, which are very well and alive these days!
Hams use it over packet radio sometimes since encryption is forbidden on the amateur bands.
IMHO we need a good telnet replacement that sends signed data. Most people interpret signatures as allowed under FCC rules, just not encryption.
> IMHO we need a good telnet replacement that sends signed data. Most people interpret signatures as allowed under FCC rules, just not encryption.
I know from bitter experience that IPsec is a “now you have two problems” kind of solution, but the Authentication Header is a thing and is supported by most (all?) implementations. Ham radio operators probably don’t have much use for the actual features of telnet compared to plain netcat, do they? (It’s mostly terminal feature negotiation and such.)
2 replies →
You can use ssh with the None cipher, thus disabling encryption entirely while still using the rest of the protocol.
Most people don't care about FCC rules.
I'm breaking a tonne of FCC rules right now.
One? All the talkers still use it and all the MUDs/MOOs etc. far out number the talkers.
N.U.T.S. 3.3.3 4eva! There was a NUTS 4, but about a decade too late.
As I understand it, greynoise is monitoring scanner traffic, so yes this would all be scans or attacks
How else would I connect to my BBS to play L.O.R.D. and check FidoNet.
nethack.alt.org still maintains a telnet server!
I've always used ssh to connect to it. And it's true that their port 23 is still open at last check. If you cannot reach port 23, and you irrationally hate ssh, you may use 14321 as an alternate.
https://www.alt.org/nethack/
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.
telnet lambda.moo.mud.org 8888
MUDs were my introduction to telnet- I grew up a university kid and had access to Wesleyan's minicomputer EAGLE.WESLEYAN.EDU running OpenVMS. I used it to telnet to CMU's TinyMUD and later other TinyMUDs around the country. I recall OpenVMS's telnet had a problem with newlines/carriage returns so all the text was staircased, so I ended up learning C and writing a MUD client. I still habitually use telnet today even if netcat and many other tools have replaced it.
All of that was foundational for my career and I still look back fondly on the technology of the time, which tended to be fairly "open" to exploration by curious-minded teenagers.
1 reply →
Aardwolf works well from my work laptop. And I don’t care if someone sees what I’m doing
Do you care if they steal your account though and drop all your inventory?
The problem is the auth is plain text too and you're open to having your credentials stolen.
1 reply →
I run a DikuMUD that users connect to using Telnet
I really should update it to allow more secure options
> that users connect to using Telnet
Not anymore ;)
Seriously though: did you notice any spikes up or down?
If you'd run it on a non-standard port, anyone can still connect with netcat, socat, etc etc.
4 replies →
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.
I just tried on a Zyxel Wifi AP I have.
It seems to use a different telnetd (busybox?), because from what I can tell it's not prone to this error.
> 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?
Most MUDs do not use Telnet.
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!
As a MUD enthusiast of two decades, this is not accurate. Where are you getting this information?
Most MUDs implement RFC 854, and a number of non-standard Telnet option subnegotiation protocols have been adopted for compression (MCCP2), transmission of unrendered data (ATCP, GMCP, ZMP), and even a mechanism for enabling marking up the normal content using XML-style tags (MXP). These telopts build on the subnegotiation facility in standard Telnet, whose designers knew that the base protocol would be insufficient for many needs; there are a great number of IANA-controlled and standardized telopt codes that demonstrate this, and the MUD community has developed extensions using that same mechanism.
> 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.
I think you are confusing "telnet" the program with "telnet" the protocol. I am speaking here of the protocol, defined at base in RFC 854, for which "telnet" the program is but one particularly common implementation. You look at any of those "dedicated, programmable clients" and they will contain an implementation of RFC 854, probably also an implementation of RFC 1143 (which nails down the rules of subnegotiation in order to prevent negotiation loops), and an implementation of the RFCs for several standard telopts as well as non-standardized MUD community telopts. I can speak for the behavior of MUSHclient in especial regard here, though I am also familiar with the underlying Telnet nature of Mudlet, ZMud, and CMUD, not to mention my very own custom-made prototype client for which I very much needed to implement Telnet as described above.
3 replies →
> MUDs do none of this.
MOOs do.
It wasn’t clear from the article but I assumed they were filtering for the attack specifically.
Since Telnet is totally plain text that would absolutely be easy to do right?
Wouldn't that imply that >80% of all monitored telnet sessions were exploit attempts for the specific CVE in question? Even with the scale of modern botnets, that seems unrealistic for a single vuln that was undisclosed at the time.
1 reply →
Not at interconnect speeds
It seems like they are doing a port based block similar to how residential lines often have their SMTP ports shut off.
That said in this day and age, servers on the public network really ought to use SSH.
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.
If you miss that and long for the olden days, you can still do it today with OpenSSL’s sclient:
I did this too, lol
The scope of this CVE and the response to it are genuinely wild.
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.
>some dude is singlehandedly responsible
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.
So eleven years ago someone put a backdoor in the Telnet daemon.
Who?
Where's the commit?
https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...
That link goes to a page full of random garbage. No commits there to be seen.
Apparently the owners of that website don't like my choice of user agent, and have decided to punish me accordingly.
1 reply →
That's crazy. This is core business critical software but they just YOLO critical changes without any automated tests? this PR would be insta-rejected in the small SAAS shop I work at.
22 replies →
Telnet's cleartext and always has been. A backdoor seems like overkill.
You still have to know the password or snoop on someone typing the password. But with this vuln, you don't. You can just get root instantly.
> backdoor
Do you mean that it's intentional? Why do you think so?
It wasn't a backdoor, just a very serious security bug. Congrats on jumping straight to conspiracy and paranoia, though.
It's only a conspiracy and paranoia if it's wrong. 11 years ago was 2015.
1 reply →
The CVE referenced is caused by this commit:
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)
From ChangeLog:
Congratulations! Now you've got yourself a precious and global(ly exploitable) vulnerability...
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?
It's nice to not see C being blamed for once! ... Just good old lack of reasoning (which is most C's codebase downfall, agreeably).
Argument injection can happen in any programming language where you can concatenate strings and call something with the result.
It's also not DNS!
Or Windows, for a change!
1 reply →
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.
Thats what the mystery exceptions for the Open Group macOS UNIX certification was for!
telnet has never been in POSIX though.
2 replies →
There's always nc hostname 23 unless you need authentication
There's no UNIX requirement for telnet.
Ubuntu does not include it by default (starting 16.04?). Most most distros don't.
Two wrongs don't make a right.
Apple still includes uucp for some unknown reason.
The saving disk space argument makes no sense because telnet was one of the smaller binaries in /usr/bin.
Telnet continues to be widely used for select use cases and being told we're naughty by not including it feels punitive and just adds extra steps. What are you supposed to do, trash a $1m piece of industrial equipment because Apple wants to remind you Telnet is insecure?
New devices are still being released with Telnet where SSH is impractical or unnecessary.
7 replies →
Netcat works as a telnet client. GAWK can do that too with a dumb loop. So can con(1) under 9front.
1 reply →
Stranger article. I wasn't able to get the main point of this article. Strangely written, but hey - I'm nob native by any means.
ps.
telnet SDF.org
just works...
it was just ai written thats why.. unexpectedly so from greynoise.
Well, I mean, the first part is a song by Don McLean called American Pie. You might know that, unsure that everyone will pick it out though.
One of the most famous play choices at karaoke bars these days too. I think because the song is a long story, of sorts? But it's a terribly long song and I will leave to take a smoke break anytime it gets chosen. You're going to be there for a good 10 minutes before it concludes.
So maybe the AI prompt was something like, "take CVE-2026-24061 and compose a song lyric in the style of American Pie by Don Mclean". I wonder if you would get similar results with that prompt.
2 replies →
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.
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.
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.)
Port 23 has decreased significantly over the past decade:
https://i.imgur.com/tZoTWu6.png
Still seeing a sizable number of open ports but it's on the decline.
I still used telnet today (had to). Unsure of the patching here. But its definitely locked down to a subset of internal use only.
Embedded? Ancient? What sort of systems are you telnetting into?
Not the parent poster, but I also still use telnet. For me it's "Ancient", I have a few retired SPARC and PA-RISC boxes that run their period appropriate OSes as a hobby. Telnet/rlogin is the more reliable method to get into them remotely (just over the LAN).
They're on a LAN behind a NAT Router/Firewall, and I don't always keep them powered up (I'm not that insane) so I really don't have a concern for them.
Some of the more modern/high-performance examples I have run NetBSD with modern sshd and modern ciphers, but you can tell it's a bit of a workout for them.
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:
I'm sure the port 23 telnet blocking will be coming to IPv6 soon though.
It's more like telnetd died rather than telnet died.
btw if you want a quick telnet client, and an old python happens to be installed, you can use `python -m telnetlib IP`
More likely a specific botnet had it's c2 or telnet scanning report endpoint go down / get nulled on Jan 14th.
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.
What do you think proper architecture would be, given that ssh needs a capability to let root logins?
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.
> ssh needs a capability to let root logins
One can disable root login via SSH in /etc/ssh/sshd_config. sshd also drops root priviledges once it's running IIRC.
I use use sudo or doas as a regular user once logged in.
I think a proper architecture would not even have a root account. The server would just expose an authenticated endpoint that allows for configuration and updates to be pushed for it.
1 reply →
Does ssh need to allow root logins?
Sshing as a regular user and then sudo to root works 95% of the time…
2 replies →
Literally how else is a remote login daemon supposed to work though?
1. Start with root to bind the port below 1024.
2. give up root because you don't need it any further.
3. Only accept non-root logins
4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.
9 replies →
The remote daemon has its own account and is given a privilege that allows it to connect a network socket to a pseudo terminal.
10 replies →
OpenSSH has been moving quite quickly in the direction of multiple, privilege separated processes, each also heavily sandboxed with pledge and unveil
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.
Stop spamming AI slop
?
3 replies →
77k hosts with port 23 open https://www.shodan.io/search?query=telnet
Between you and me telnet is not dead. Sometimes I use it to probe a port to verify it is working.
You might wanna use netcat for that instead [1]. Or, for example, socat [2]. Netcat has been around for a long, long time now.
[1] nc (1) - arbitrary TCP and UDP connections and listens
[2] socat (1) - Multipurpose relay (SOcket CAT)
That's not really telnet. Yeah, it's using the same client, but the server and underlying protocol are what's relevant here.
The modern replacement for telnet used in the "probe a port" fashion is nc/netcat.
I used to telnet into my POP3 account and check email by protocol. Shucks.
Your dial up ever die when you where checking your email? My ISP didn't allow for leave copy on server, I remember times I lost emails to this.
There is something poetic about telnet finally going quiet. It was never meant to survive this long, yet it outlasted entire generations of 'secure replacements' simply because it was simple and it worked. The real lesson is that protocols do not die when better alternatives arrive; they die when the last device running them gets unplugged.
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.
Even that's argued within linguistics. There are languages which survive for generations as secondary languages (especially trade languages as Swahili or Chinook Jargon appear to have been originally). Also some like Latin, Hebrew and Sanskrit which survive for centuries but not as native languages.
1 reply →
Why would somebody read something that somebody couldn't be bothered to write? This article is AI slop.
What stood out as AI written? It felt like a well-written article by an SME to me.
Not the original commenter, but I noticed it too. I guess it's hard since AI is trained on human content, so presumably humans write like this too, but a few that stood out to me:
> Five entire countries vanished from GreyNoise telnet data: Zimbabwe, Ukraine, Canada, Poland, and Egypt. Not reduced — zero.
> An attacker sends -f root as the username value, and login(1) obediently skips authentication, handing over a root shell. No credentials required. No user interaction.
> The GreyNoise Global Observation Grid recorded a sudden, sustained collapse in global telnet traffic — not a gradual decline, not scanner attrition, not a data pipeline problem, but a step function. One hour, ~74,000 sessions. The next, ~22,000.
> That kind of step function — propagating within a single hour window — reads as a configuration change on routing infrastructure, not behavioral drift in scanning populations.
(and I'm not just pointing these out because of the em dashes)
GPTZero (which is just another AI model that can have similar flaws and is definitely not infallible, but is at least another data point) rates my excerpts as 78% chance AI written, 22% chance of AI-human mix.
To me at least, the article still seems to be majority human-written, though.
1 reply →
Personally, I found the spoof song in the middle of very dry writing to be jarring. But I didn't think it sounded AI written.
[dead]
This is about Telnetd. Not telnet itself.
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.)
I'm not sure I understand how this argument refutes the claim that this isn't about telnetd. There'd be no reason to respond to the vulnerability in the way they did if the vulnerability in telnetd hadn't existed and been exploited -- and the proof is that nobody ever did until 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).
I wonder if simply moving to a nearby port would work. I assume only port TCP/23 is filtered instead of filtering the telnet protocol itself.
telnet isn't just for ... telnet.
.. or you can use SWAKS! For some odd reason telnet is becoming rare as an installed binary.
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.
Never heard about https://jetmore.org/john/code/swaks/, thanks for the tip.
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.
As long as it works, it doesn’t really matter for a quick test.
I find myself using curl telnet://server:port too often these days because telnet and nc don’t get installed.
I discovered swaks recently, god I love that tool
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?
Ah. Telnet. My oscilloscope still talks telnet, and this is the reason why that type of equipment is on an isolated net.
Your cookie banner is very inconvenient and made me leave your website and not read the article
Who actually uses the tectia ssh client instead of openssh?
telnet + shijack = good times
port 22 2FA
The pattern points toward one or more North American Tier 1 transit providers implementing port 23 filtering
Someone attempted to compromise my home router last week using CHARGEN. Can you imagine!
Attempted to compromise, or just port scanned?
1 reply →
[dead]
[dead]