Were telcos tipped off to *that* ancient Telnet bug? Cyber pros say the signs stack up
(2026/02/11)
- Reference: 1770824507
- News link: https://www.theregister.co.uk/2026/02/11/were_telcos_tipped_off_to/
- Source link:
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.
[1]
"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 [2]blog .
[3]
[4]
The researchers unverified theory is that infrastructure operators may have received information about the [5]make-me-root flaw before advisories went to the masses.
"A backbone or transit provider – possibly responding to a coordinated request, possibly acting on their own assessment– implemented port 23 filtering on transit links. The filtering went live on January 14. The public disclosure followed on January 20."
[6]
As for supporting evidence? 18 operators, including BT, Cox Communications, and Vultr went from hundreds of thousands of Telnet sessions to zero by January 15.
Major cloud providers were mostly unaffected by this drop off, and in some cases like AWS, increased by 78 percent.
"Cloud providers have extensive private peering at major IXPs that bypass traditional transit backbone paths. Residential and enterprise ISPs typically don't," the researchers said.
[7]
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.
[8]EU considers whether there's Huawei of axing Chinese kit from networks within 3 years
[9]Cloudflare pours cold water on 'BGP weirdness preceded US attack on Venezuela' theory
[10]Outdated Samsung handset linked to fatal emergency call failure in Australia
[11]Suspected Salt Typhoon snoops lurking in European telco's network
[12]If you thought China's Salt Typhoon was booted off critical networks, think again
While GreyNoise acknowledged that correlation does not equal causation, its experts said a pre-advisory notification could explain the timing between traffic drop off and advisory releases, the specific port 23 filtering, and the fact that the filter is still in place today.
"We can't prove this. The backbone drop could be entirely coincidental – ISPs have been slowly moving toward filtering legacy insecure protocols for years ( [13]Wannacry ), and January 14 could simply have been when someone's change control ticket finally got executed.
"But the combination of a Tier 1 backbone implementing what appears to be port 23 filtering, followed six days later by the disclosure of a trivially exploitable root-access telnet vulnerability, followed four days after that by a [14]CISA KEV listing, is worth documenting and considering."
The Register approached some of the telcos GreyNoise mentioned in its report for their take on the theory and we'll update this article if we hear back. ®
Get our [15]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aYy1tQQAU4P7GIN-xSD70wAAAUc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://www.labs.greynoise.io/grimoire/2026-02-10-telnet-falls-silent/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aYy1tQQAU4P7GIN-xSD70wAAAUc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aYy1tQQAU4P7GIN-xSD70wAAAUc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2026/01/22/root_telnet_bug/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aYy1tQQAU4P7GIN-xSD70wAAAUc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aYy1tQQAU4P7GIN-xSD70wAAAUc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2026/01/21/eu_mulls_deadline_of_3_years/
[9] https://www.theregister.com/2026/01/08/cloudflare_venezuela_bgp_attack_theory/
[10] https://www.theregister.com/2025/11/18/samsung_emergency_call_failure/
[11] https://www.theregister.com/2025/10/20/salt_typhoon_european_telco/
[12] https://www.theregister.com/2025/08/28/china_salt_typhoon_alert/
[13] https://www.theregister.com/2017/05/20/wannacry_windows_xp/
[14] https://www.theregister.com/2026/02/03/greynoise_cisa_ransomware_gripe/
[15] https://whitepapers.theregister.com/
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.
[1]
"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 [2]blog .
[3]
[4]
The researchers unverified theory is that infrastructure operators may have received information about the [5]make-me-root flaw before advisories went to the masses.
"A backbone or transit provider – possibly responding to a coordinated request, possibly acting on their own assessment– implemented port 23 filtering on transit links. The filtering went live on January 14. The public disclosure followed on January 20."
[6]
As for supporting evidence? 18 operators, including BT, Cox Communications, and Vultr went from hundreds of thousands of Telnet sessions to zero by January 15.
Major cloud providers were mostly unaffected by this drop off, and in some cases like AWS, increased by 78 percent.
"Cloud providers have extensive private peering at major IXPs that bypass traditional transit backbone paths. Residential and enterprise ISPs typically don't," the researchers said.
[7]
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.
[8]EU considers whether there's Huawei of axing Chinese kit from networks within 3 years
[9]Cloudflare pours cold water on 'BGP weirdness preceded US attack on Venezuela' theory
[10]Outdated Samsung handset linked to fatal emergency call failure in Australia
[11]Suspected Salt Typhoon snoops lurking in European telco's network
[12]If you thought China's Salt Typhoon was booted off critical networks, think again
While GreyNoise acknowledged that correlation does not equal causation, its experts said a pre-advisory notification could explain the timing between traffic drop off and advisory releases, the specific port 23 filtering, and the fact that the filter is still in place today.
"We can't prove this. The backbone drop could be entirely coincidental – ISPs have been slowly moving toward filtering legacy insecure protocols for years ( [13]Wannacry ), and January 14 could simply have been when someone's change control ticket finally got executed.
"But the combination of a Tier 1 backbone implementing what appears to be port 23 filtering, followed six days later by the disclosure of a trivially exploitable root-access telnet vulnerability, followed four days after that by a [14]CISA KEV listing, is worth documenting and considering."
The Register approached some of the telcos GreyNoise mentioned in its report for their take on the theory and we'll update this article if we hear back. ®
Get our [15]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aYy1tQQAU4P7GIN-xSD70wAAAUc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://www.labs.greynoise.io/grimoire/2026-02-10-telnet-falls-silent/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aYy1tQQAU4P7GIN-xSD70wAAAUc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aYy1tQQAU4P7GIN-xSD70wAAAUc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2026/01/22/root_telnet_bug/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aYy1tQQAU4P7GIN-xSD70wAAAUc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aYy1tQQAU4P7GIN-xSD70wAAAUc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2026/01/21/eu_mulls_deadline_of_3_years/
[9] https://www.theregister.com/2026/01/08/cloudflare_venezuela_bgp_attack_theory/
[10] https://www.theregister.com/2025/11/18/samsung_emergency_call_failure/
[11] https://www.theregister.com/2025/10/20/salt_typhoon_european_telco/
[12] https://www.theregister.com/2025/08/28/china_salt_typhoon_alert/
[13] https://www.theregister.com/2017/05/20/wannacry_windows_xp/
[14] https://www.theregister.com/2026/02/03/greynoise_cisa_ransomware_gripe/
[15] https://whitepapers.theregister.com/
So a low powered "AI" bot
JimmyPage
could have suggested a Telnet flaw before it was announced just by looking at traffic ?
Which does rather raise the question why didn't it ?
How the ancient Telnet bug worked
Taliesinawen
* A template string used by telnetd to exec the system login program was modified to support a new %U placeholder that is expanded to the value of the USER environment variable at runtime.
* Telnetd already allowed the remote client to influence USER (via Telnet environment options and login‑related flags), and after this change it began substituting that value directly into the login argument list without validation or escaping.
* As a consequence, values starting with a dash such as -f root were now passed to login as if they were its command‑line options, enabling an authentication bypass and root shell.
How come they weren't filtering port 23 already?