Researchers spot suspicious Telnet traffic drop six days before public disclosure of critical vulnerability, suggesting telcos may have received advance warning.
Security researchers are investigating a suspicious drop in global Telnet traffic that occurred six days before the public disclosure of a critical vulnerability, raising questions about whether telecommunications companies received advance warning.
On January 14, Telnet sessions plummeted by 65 percent within one hour and 83 percent within two hours, according to threat intelligence firm GreyNoise. This dramatic decline preceded the January 20 public disclosure of CVE-2026-24061, a decade-old bug in GNU InetUtils telnetd with a critical 9.8 CVSS score that allows trivial root access exploitation.
The timeline that raises eyebrows
The timing is particularly suspicious because the traffic drop was so abrupt and specific. Daily Telnet sessions fell from an average of 914,000 between December 1 and January 14 to around 373,000—a 59 percent decrease that has persisted.
"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 their analysis.
Who was affected and who wasn't
Eighteen 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, with some like AWS actually increasing by 78 percent.
This pattern suggests backbone or transit providers may have implemented port 23 filtering on transit links. The researchers noted that cloud providers have extensive private peering at major internet exchange points that bypass traditional transit backbone paths, while residential and enterprise ISPs typically don't.
Geographic patterns support the theory
US residential ISP Telnet traffic dropped during US maintenance window hours, with similar patterns occurring for those relying on transatlantic or transpacific backbone routes. European peering was relatively unaffected, pointing to one or more Tier 1 transit providers in North America implementing the filtering.
The stakes are high
This isn't just about an old protocol. The Telnet vulnerability in question allows trivial root access exploitation, making it extremely dangerous. The fact that filtering remains in place today suggests the threat was taken seriously by those who knew about it first.
Could it be coincidence?
GreyNoise acknowledges that correlation does not equal causation. ISPs have been gradually moving toward filtering legacy insecure protocols for years, particularly after incidents like WannaCry. January 14 could simply have been when someone's change control ticket finally got executed.
However, the combination of events is striking: 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 CISA Known Exploited Vulnerabilities (KEV) listing.
What this means for security disclosure
If telcos did receive advance warning, it raises serious questions about the security disclosure process. While coordinated disclosure aims to give organizations time to patch vulnerabilities before public disclosure, the practice becomes problematic when it appears to favor certain classes of organizations over others.
The researchers concluded: "We can't prove this. But the combination of events is worth documenting and considering."
The Register has approached some of the telcos mentioned in GreyNoise's report for comment and will update this article if responses are received.

This case highlights the ongoing challenges in vulnerability disclosure and the delicate balance between giving organizations time to protect themselves and ensuring all stakeholders have equal access to critical security information. As legacy protocols like Telnet continue to pose risks, the question of who gets warned first—and why—remains a contentious issue in the cybersecurity community.

Comments
Please log in or register to join the discussion