Reports of Telnet's death have been greatly exaggerated

You may have seen the recent news that Telnet traffic from major US ISPs dropped precipitously around the time that a CVE against GNU Inetutils was announced. Because this report has led to intense discussion around the role of core network infrastructure providers and implications for the security of network services globally, we at Terrace felt it was important to share our results and correct the record. After analyzing both our internal and open data, we believe there are critical errors that undermine the basic findings of the report.

The original report shows the number of Telnet sessions observed from GreyNoise across many source autonomous systems (ASes) by day. Their data show a dramatic shift in observed network traffic:

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. By the following hour, we were down to ~11,000 and the floor held. (Link)

We cross-checked this data against traffic observed by Terrace, other open observation data, and measurements of underlying routing infrastructure through RIPE Atlas. In sum, our results show that there is no new filtering of Telnet being performed by core ISPs. To be clear, we successfully performed Telnet traceroutes from reportedly-affected ASes to our servers as of today at 18:47 UTC.

Evaluating Telnet Scanning

Naturally, seeing such a dramatic and coordinated drop in traffic (from 10s of thousands down to zero) would make you suspect that the network is the common factor. As we describe below, the fundamental flaw of this approach is that sessions can be highly correlated: thousands of scans from disparate networks can be directly tied to individual noisy actions.

At Terrace we use artificial intelligence to detect trends from our global deployment of network sensors in real-time, so when we saw this our first thought was “how could we have missed this?” We went to the data, and as far as we can tell, the answer is that we didn’t.

We cross-checked ASes reported by GreyNoise against port 23 scanning data from Terrace. Of course, we filtered these to only incoming traffic that successfully completed the three-way TCP handshake to factor out IP spoofing. Here are those results:

ASes from 9678 down are those that saw a 100% drop-off in GreyNoise data. Note that Terrace’s footprint differs from GreyNoise and we therefore see scanning from different ASes, hence the lower coverage of these specific networks. However, the (lack of) trend is clear: We see continued port 23 traffic from affected ASes and no shift on January 14. Note that here we look at the number of source IPs observed, not total sessions. We believe this is a more precise metric, as single large-scale scans (e.g., from a Telnet password guesser) can dramatically skew session counts.

The bigger scanning picture

We next look at all the ASes observed by Terrace, the sum of sources seen in GreyNoise-referenced ASes, and specifically at the group that saw complete drop-off. In each case, there is no change in port 23 Telnet scanning behavior that we can attribute to broad ISP-level blocking. In fact, January 14 is part of a relative spike of Telnet scanning traffic.

We also cross-checked our results against open network threat data. For instance, Dataplane.org does not see a large correlated drop in Telnet traffic, aligning with our results.

Measuring Telnet Routing with RIPE Atlas

To confirm our results, we also performed a measurement of Telnet traffic deliverability using RIPE Atlas. For ASes mentioned in the report as being blocked completely, we performed a Telnet traceroute, confirming that in 55 of 56 cases Telnet sessions were successfully established with our server. Our results confirm that, across referenced ASes, there is no observable widespread blocking of port 23 as of February 11.

It’s not A, it’s B

Looking at the original report’s data in light of our analysis, we can posit several potential interpretations that align with our observations.

When you see such a coordinated drop-off, there’s likely a common factor. One possibility is core network backbones. However, in the context of data from Terrace and others we believe a more likely factor is the vantage point itself. Internet scanning often consists of large campaigns coordinated by specific actors, and in this case it is possible that an Internet scanner has managed to fingerprint GreyNoise’s apparatus and actively avoid it. Notably, such apparatus avoidance is something we’ve previously investigated in academic research.

Another confounding factor is the use of total sessions to visualize this trend. Because a single Telnet exploit attempt could consist of many sessions, visuals can overstate the statistical significance of observed trends. In this case, it again is possible that the thousands of observed sessions in GreyNoise’s data are actually coming from a single coordinated actor, or even just a small handful of IPs. We recommend analyzing trends such as these in terms of unique network endpoints or fingerprintable behaviors rather than raw number of sessions.

Takeaways

The sky is not falling. Suggestions that core ISPs are censoring or filtering Telnet traffic are not supported by our observations. Of course, we fully support and echo GreyNoise’s encouragement to take CVE-2026-24061 seriously. In fact, the lack of core network protections yet further exemplifies that edge systems must be patched immediately.

However, we strongly believe that any changes to operations or policy based on the expectation that Telnet is being filtered at the core are not warranted.