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?
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.
This is still true, though 5-10 minutes is slightly pessimistic. Source: https://youtu.be/6uSVVCmOH5w
TL;DW - Guy installs XP and makes it internet accessible, only takes 15 minutes before the first malware appears on it.
Filtering one port is not censorship. Not even close.
Great analysis, thank you!
New thread: Reports of Telnet's Death Have Been Greatly Exaggerated https://news.ycombinator.com/item?id=46980355
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.
Is it on port 23/tcp, and what are the ASNs?
The report specifically says that cloud networks like VPS, AWS seemed exempt.
Anyway, just wild seeing this:
> telnet -l 'root -f' server.test
or
> USER='-f root' telnet -a server.test
Survive 11 years.
But adoption stalled when the original SSH moved to a commercial license in 1996-ish - many of us stuck with the last free version, but vulnerabilities started to pile up. There were various half-working alternatives, but it wasn't until OpenSSH came out in 1999 that the remaining telnet holdouts started to move across.
We used telnet in college no problem. It was a fairly well-accepted method of remote access. The heterogeneous network had many different modes, but a major dialup point was the Annex box, which supported telnet into the Unix or VMS machines.
Between Unix machines, we would often prefer "rlogin" instead. There were several horrific iterations of other remote-access protocols such as "remsh". rlogin was notorious for its "/etc/hosts.equiv" authorization method which trusted DNS and should've been perceived as Swiss Cheese from the outset. rlogin was, IIRC, directly related to rsh and rcp and used the same frameworks. rlogin was no more secure than telnet, but probably less secure because of its conveniences.
We also used port 23/tcp for remote management, for example Cisco routers. They weren't running telnetd, but it was the port where you connected remotely and logged in with or without credentials.
rlogin persisted alongside telnet, until encryption came into fashion and ssh was distributed. Once ssh was available and working well, everyone knew that telnetd and rlogind were on borrowed time. The services were shut down and disabled in inetd. The ports were sometimes blocked. Security advisories went out.
I suppose it took a long, long time for ssh to finally dominate, and for people to abandon telnetd mostly, but it was fairly thorough. We all recognized the superiority of sshd's authentication and encrypted channels.
There were mitigations for people to extend their legacy use of telnetd and rlogind. For example, tcp wrappers and fail2ban could be implemented. Firewall filters could select only authorized networks. VPNs could tunnel through an Intranet that still used them. So, the services lived on wherever they didn't need to be exposed on the public Internet. But I think most Unix admins got the picture by the end of the dot-com bubble.
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.
As are many other tools. But the ones above are basically far better direct telnet alternatives.
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.
(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)
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.)
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.
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.
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.
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.
PCI DSS, HIPAA, and ISO 27001 each either highly recommend or enforce this.
I wouldn't use a jumphost without it.
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'm breaking a tonne of FCC rules right now.
I really should update it to allow more secure options
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.
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.
The problem is the auth is plain text too and you're open to having your credentials stolen.
telnet doom.w-graj.net 666It seems to use a different telnetd (busybox?), because from what I can tell it's not prone to this error.
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!
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.
MOOs do.
Since Telnet is totally plain text that would absolutely be easy to do right?
That said in this day and age, servers on the public network really ought to use SSH.
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.
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.
openssl s_client -connect www.yahoo.com:443Who?
Where's the commit?
Apparently the owners of that website don't like my choice of user agent, and have decided to punish me accordingly.
Do you mean that it's intentional? Why do you think so?
https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...
One of the changes is:
- getterminaltype (char *user_name, size_t len)
+ getterminaltype (char *uname, size_t len)
* telnetd/utility.c (getterminaltype): Change the
name `user_name' to `uname', as the former shadows a precious
and global variable name.The present fix is to sanitize user input. Does it cover all cases?
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.
Ubuntu does not include it by default (starting 16.04?). Most most distros don't.
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.
ps.
telnet SDF.org
just works...
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.
(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.)
https://i.imgur.com/tZoTWu6.png
Still seeing a sizable number of open ports but it's on the decline.
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.)
Isn't this one of the remaining, "legit" uses of the Telnet protocol on TCP/23 port over the public Internet?
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.
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 --
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.
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.
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":
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.
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.
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.
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.
Sshing as a regular user and then sudo to root works 95% of the time…
btw if you want a quick telnet client, and an old python happens to be installed, you can use `python -m telnetlib IP`
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
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.
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.)
[1] nc (1) - arbitrary TCP and UDP connections and listens
[2] socat (1) - Multipurpose relay (SOcket CAT)
The modern replacement for telnet used in the "probe a port" fashion is nc/netcat.
I think about this quote a lot: given enough eyeballs, all bugs are shallow
> 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.
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?
https://www.shodan.io/search/report?query=product%3Atelnetd+...
$ telnet smtp.example.co.uk 25
HELO me
MAIL FROM: gerdesj@example2.co.uk
RCPT TO: gerdesj@example.co.uk
DATA
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.
Never heard about https://jetmore.org/john/code/swaks/, thanks for the tip.
I find myself using curl telnet://server:port too often these days because telnet and nc don’t get installed.