Sudden Telnet Traffic Drop. Are Telcos Filtering Ports to Block Critical Vulnerability? (theregister.com) 73
An anonymous reader shared this report from the Register:
Telcos likely received advance warning about January's critical Telnet vulnerability before its public disclosure, according to threat intelligence biz GreyNoise. Global Telnet traffic "fell off a cliff" on January 14, six days before security advisories for CVE-2026-24061 went public on January 20. The flaw, a decade-old bug in GNU InetUtils telnetd with a 9.8 CVSS score, allows trivial root access exploitation. GreyNoise data shows Telnet sessions dropped 65 percent within one hour on January 14, then 83 percent within two hours. Daily sessions fell from an average 914,000 (December 1 to January 14) to around 373,000, equating to a 59 percent decrease that persists today.
"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," said GreyNoise's Bob Rudis and "Orbie," in a recent blog [post]. The researchers unverified theory is that infrastructure operators may have received information about the make-me-root flaw before advisories went to the masses...
18 operators, including BT, Cox Communications, and Vultr went from hundreds of thousands of Telnet sessions to zero by January 15... All of this points to one or more Tier 1 transit providers in North America implementing port 23 filtering. US residential ISP Telnet traffic dropped within the US maintenance window hours, and the same occurred at those relying on transatlantic or transpacific backbone routes, all while European peering was relatively unaffected, they added.
"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," said GreyNoise's Bob Rudis and "Orbie," in a recent blog [post]. The researchers unverified theory is that infrastructure operators may have received information about the make-me-root flaw before advisories went to the masses...
18 operators, including BT, Cox Communications, and Vultr went from hundreds of thousands of Telnet sessions to zero by January 15... All of this points to one or more Tier 1 transit providers in North America implementing port 23 filtering. US residential ISP Telnet traffic dropped within the US maintenance window hours, and the same occurred at those relying on transatlantic or transpacific backbone routes, all while European peering was relatively unaffected, they added.
Whut?? (Score:2)
It's 2026. Who on Earth still runs a Telnet server? (Other than cute little demos like mapscii.me that don't require authentication anyway.)
Re: (Score:3)
Re: (Score:2)
Without an ssh or VPN proxy in front? That is asking for it.
Re: (Score:2)
Vintage hardware can use ssh. I was introducted to ssh in the nineties.
Re: (Score:2)
It's 2026. Who on Earth still runs a Telnet server? (Other than cute little demos like mapscii.me that don't require authentication anyway.)
Sure maybe you have a really legacy embedded device tucked away somewhere where it is somewhat secured and a calculated risk, but this article is talking about the open internet. That is just crazy, I had no idea.
Re: (Score:2)
Re: (Score:2)
Yes. That was my first though as well. Telnet servers have no place on the Internet anymore and are far more of a risk than they can be a benefit.
Re: (Score:1)
Re: Whut?? (Score:2)
Satirizing politicians is also illegal there, even foreign politicians with obvious problems like Erdogen.
While telnet is cleartext, that's no reason to ban it. If you want to, you can literally use a telnet client to talk to http servers, mail servers, and a lot more. Do it through an openssl tunnel for the secure versions of those.
Not everything needs authentication or privacy.
Re: (Score:3)
Satirizing politicians is also illegal there, even foreign politicians with obvious problems like Erdogen.
While telnet is cleartext, that's no reason to ban it. If you want to, you can literally use a telnet client to talk to http servers, mail servers, and a lot more. Do it through an openssl tunnel for the secure versions of those.
Not everything needs authentication or privacy.
But you wouldn't be doing that on port 23, so you still can. See how easy that was?
Re: (Score:1)
And?
Re: (Score:2)
The article talks about telnet servers, not clients. Telnet client can be used for a lot of things. Telnet servers can only be used for log-in.
Re: Whut?? (Score:1)
That is not at all true.
Re: (Score:2)
It is mostly true. Stop being mindlessly contrarian just because you cannot get over yourself.
Re: (Score:1)
Ah...well...now you're just asking for it.
It is mostly true.
This statement:
Telnet servers can only be used for log-in.
Is just plain fucking false, and moronically so, but I refrained from stating the obvious earlier. Not slightly false, not halfway false, just completely fucking false. Don't believe me? Take a look at the RFC:
https://datatracker.ietf.org/d... [ietf.org]
Look at that? It doesn't mention login anywhere in it, and in fact its purpose is clearly defined in that very first paragraph. This is a fact. I didn't set it. You obviously have telnet confused with something l
Re: (Score:2)
You are being an idiot. The fact of the matter is that Telnet is primarily used for log-ins on the server (!) side.
Re: (Score:1)
That RFC document mentions "server" exactly 22 times. The word "log" is mentioned exactly never. The word "log" is mentioned exactly never. Notice how telnet-based login schemes don't echo back the password when you're typing it in? Tell me where you see that behavior documented in the RFC. You know why it's not there? Because that's not telnet. The only reason I mentioned the client side at all is because I was making it easy for you to see for yourself what telnet really is. The content behind that telnet
Re: (Score:2)
> Satirizing politicians is also illegal there
References ? Because what I've found that's not the case:
"There is broad scope here: political utterances or other expressions of opinion are generally protected even if they are polemical or exaggerated. The Federal Constitutional Court ruled that the statement “Soldiers are murderers” falls under freedom of expression, for example. In addition, satire – by cabaret artists or caricaturists, for instance – not only falls under freedom
Re: (Score:2)
I wouldn't put it past some IOT devices to have it enabled.
Re: Whut?? (Score:2)
Until recently, you could get the text of national weather service guidance by telnet. It was about the right level of protocol to provide plain text to a terminal with enough information to paginate it and enough input to pick an airport code.
Re: (Score:3)
Sure. Anything that doesn't require authentication and provides publicly-known information anyway doesn't need encryption.
Re: Whut?? (Score:2)
Well, until getting root with an exploit comes along...
Then authentication and encryption - or a better protocol (http?) would seem de rogue.
Re: (Score:2)
That's not a problem with the protocol though, any more than a similar vulnerability in Apache or nginx would be a problem with http.
Re: (Score:2)
Right? I had to pull from the mental archive (pre-coffee) to figure out what in the world telnet was. It was familiar, but... distant. I couldn't remember which port it was, specifically.
Another possibility is that all these telnet services were pre-exploited, that's why they disappeared. There may have been a threat actor doing things at the same time.
Re: Whut?? (Score:1)
Really just text over TCP, with a handful of telnet specific control codes outside of the ASCII range suitable for e.g. menus, which I believe makes it incompatible with all Unicode variants, but I've never tried any. The rest of the stack takes care of things like packet order and retransmitting some forms of data corruption and mostly deals with dropped packets.
It's pretty simple. Pull up Wireshark and follow the TCP stream. You generally can send/receive binary as well, but both sides will need to negoti
Re: (Score:2)
Yes, I was there, in the old days.
I just haven't -seen- or -used- it in almost 25 years.
Re: (Score:2)
I have no idea why this isn't already upvoted to 5 and beyond. There are vape rigs that have a built in ssh server now for pete's sake.
Most of the things these other people are talking about probably don't use telnetd at all but instead simply use an inet superserver (inetd/xinetd) that launches their whatever.
There's just no reason to be using telnetd unless someone is expecting people to login like it's 1996 or something,
Re: (Score:2)
Me, but thankfully it's not exposed to the Internet. Don't ask.
Re: (Score:1)
Telnet as in port 23? (Score:2)
Telnet, like we used to use in between fighting sabre-tooth tigers and coding in COBOL?
When we sent symmetric passwords in plaintext?
That is a zombie protocol risen from the OxDEAD ! Just kill it.
Re: (Score:3)
That is a zombie protocol risen from the OxDEAD ! Just kill it.
Given the exploit was patched but telnet traffic stayed down... it's apparent a bunch of people made exactly that decision.
Now, if you want to ask why they didn't make that decision 15 years earlier... I've got nothin'.
Re: (Score:2)
Either made that decision, or didn't notice that Telnet doesn't work anymore.
If you meant the ISPs then no, they didn't block Telnet. They merely blocked port 23.
Re: (Score:2)
Telnet, like we used to use in between fighting sabre-tooth tigers and coding in COBOL?
I code in PASCAL, you insensitive clod!
Probably a good thing (Score:4, Insightful)
Don't get me wrong, I still telnet to a handful of BBSes that still use the protocol...but with SSH largely supplanting it, and few end-user facing applications using it...the odds are good that most residential telnet traffic isn't all that legitimate, so requiring that customers call to request opening of port 23, along with 80 and 443 as some ISPs do, is probably a good thing overall.
Re: (Score:2)
Yeah, those insecure protocols - telnet, ftp, rsh, rlogin, http,... all ought to be deprecated. Long overdue
Re: (Score:2)
No-login HTTP and FTP is fine. Obviously, if you download anything important, you need to verify signatures.
Re: (Score:2)
Why not just assume that anything worth downloading - or uploading - is important enough that one doesn't want it corrupted, or intercepted by any MITM attacks? Just default to https and ftps (or sftp if one prefers)
Re: (Score:2)
Even if the transport protocol is secure, you have no assurance that the data hasn't been modified on the server. Which is why if you care, you should verify the cryptographic signature of whatever you download---it is signed, right? And you should also sign anything important that you upload.
For downloads, you also need to ponder how much you can trust the signing key.
Re: (Score:2)
For downloads, you also need to ponder how much you can trust the signing key.
Yes. And how trustworthy the ones doing the signature are to get things right. But the good thing is you only need to trust this and nothing else. It is surprising how many people still do not know how digital signatures work and what they give you. Public-key crypto has been publicly known for 50 years now.
Re: (Score:2)
Yeah, they teach all about Pubic-key crypto in public high school. It's in the class where they teach you how to write a check, balance a checkbook, fold laundry and do basic cooking. Oh right, no one in 35 years has had that class offered to them.
Still, it would be nice if people understood the benefits of using public-key crypto for signing stuff. Unfortunately, computers and cellphones are still just appliances to 99% of the public. Good luck getting them to understand public-key crypto. They hear crypto
Re: (Score:2)
In a mirror network, the TLS cert is a weaker assurance than the signed payload from the presumably trusted source. A mirror host is more exposure and more risk that the actual content gets modified despite having 'a' valid certificate.
So the TLS assurance is redundant and less specific and less rigorous than the content signature validation from the originator. Further, unencrypted protocols are friendlier to things like proxying, which can dramatically reduce load on the internet hosts if proxies take on
Re: (Score:2)
Indeed. As long as you can trust the signature (after verifying it), you do not need to trust the path the data took in any way. Verifying a signature is pretty easy, while verifying the path a file took is somewhere from very hard to impossible. Obviously, you need to get the signing-key in authentic form, but you only need to do that once and there are several ways to verify it. For the file-path, you would need to do a full verification each time.
Re: (Score:2)
Here is the thing: HTTPS and FTPS do not actually ensure that and things can also get corrupted earlier. SFTP requires an account.
But if you verify the signature anyways, you do not need a secure connection. You can get things from anywhere.
BBSes Re: Probably a good thing (Score:1)
What BBSes are available these days. I want one!
Re: (Score:3, Informative)
What BBSes are available these days. I want one!
https://www.telnetbbsguide.com... [telnetbbsguide.com] Enjoy!
Re: (Score:2)
How fortunate that Telnet works only on port 23... (and HTTP(s) on 80/443)
Telnet is still used? (Score:2)
I guess some old ideas never die
Re: (Score:2)
The telnet client is useful for a number of things. Just not for actual log-ins over the Internet.
Re: (Score:2)
Re: (Score:2)
You are talking about different things. The telnet client is useful (though there are better replacements these days). The telnet server "telnetd" should be taken out back and shot. Then the person who enabled it, if they are still alive, should also be taken out back and shot. Sure, sure, "legacy devices on secured subnets", but TFA talks about servers accessible from the internet.
And I say this as someone who set up many telnetd servers, and continued using them with kerberos auth for a while. But I
Re: (Score:2)
Exactly
Re: (Score:2)
Re: (Score:2)
Errr... what?
There are still unencrypted services (less now than in the past, but you can always bet on vendor laziness and/or incompetence). And in the past "telnet" was my frontline debugging tool.
Re: (Score:2)
Serious Question (Score:2)
Who the actual fuck is using telnet?
I'll admit to using a telnet client to test connectivity from time to time, SMTP for instance. But, no one should be running telnetd in 2026.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
We actually have an old arduino-based temperature probe, in a server room, that has a telnet interface. However it's not reachable from the internet (and also not on the same network as the servers).
I'd like to see it replaced, but for various reasons that has yet to happen.
Re: (Score:2)
Do you use the telnet interface, or does it just have an interface?
Also, if your Arduino has the telnetd flaw and gets rooted, what's the worst that they could do?
Re: (Score:2)
Chances are you'll need to use openssl s_client -starttls smtp rather than telnet these days.
Re:Serious Question (Score:5, Funny)
Helo
Disclosure Process (Score:5, Interesting)
"Telcos likely received advance warning"
Yes, there is a semi-secret mailing list of organizations that are informed of CVEs before public disclosure. Without being on the inside of this particular vulnerability, I can say with 99% certainty that this is indeed the case.
I was brought on as a contractor to help evaluate one of the "sudo" privilege escalation attacks years ago, to test it on a number of platforms. I had about one to two weeks advanced notice of the CVE before it went public to help evaluate potential risk, which is where the "scores" come from. Note, in this context, a platform is more than just a single vendor or single OS, I was brought on as the subject matter expert for a particular CPU architecture and F/OSS operating system combination to see if the exploit was valid there as well. Testing required seeing if the same exploit worked across OS revisions, patch levels, CPU architectures, and comparing it to other OSes with similar hardware configurations.
There is a whole community behind the scenes of people who are deeply passionate about security doing this work behind closed doors. Many of these people are industry professionals at the hyper-scalers and OS vendors (both open and closed source) and push out patches there first before anything goes public.
Re: (Score:2)
Yes, there is a semi-secret mailing list of organizations that are informed of CVEs before public disclosure.
It's called responsible disclosure, and security researchers have done this since the last century. When a vulnerability is discovered, the software's maintainers are given advance notice to develop a patch before the vulnerability is made public. I'm not aware that there's any master list of entities that get notified about every vulnerability whether it belongs to them or not.
Re: (Score:2)
Yes, there is a "master list" - as I mentioned, its primarily the hyperscalers and OS vendors. That's how I got pulled in personally, it was one of the F/OSS OSes that wanted some insights into a particular CPU architecture where I had expertise plus a full testing lab to do all the validation testing quickly.
That would make a fine Slashdot story (Score:2)
The remaining nerds would find it newsworthy, and you'd know what to leave unsaid.
telnet? (Score:3)
Re: (Score:2)
telnet towel.blinkenlights.nl (Score:2)
Will this be the final end then?
Telnet servers are still in use (Score:2)
A common use for them is old BBS systems and short term access to virtualized old machines.
My recent test shows vultr isn't blocking telnetd servers.
Oh no (Score:3)