Reports of Telnet's Death Have Been Greatly Exaggerated

Source: Hacker News

TL;DR

We see no evidence that specific core‑network autonomous systems have blocked Telnet, contrary to previous reports. Continuous, non‑spoofable Telnet traffic is still observed from networks where GreyNoise reported a 100 % drop‑off. The initial results were likely measurement artifacts or the result of threat actors deliberately avoiding GreyNoise infrastructure—something that cannot be confirmed without internal data.

---

Background

• A recent GreyNoise blog post claimed that Telnet traffic from major U.S. ISPs dropped precipitously around the time a CVE‑2026‑24061 (GNU Inetutils) was disclosed.
• The report sparked intense discussion about the role of core‑network providers and the global security implications of Telnet services.
• Terrace decided to re‑examine the claim using both internal measurements and publicly available data.

---

What the Original Report Shows

The GreyNoise data visualized Telnet sessions per day across many source autonomous systems (ASes). The key observations were:

The authors described this as a sudden, sustained collapse—a step‑function drop rather than a gradual decline, scanner attrition, or a data‑pipeline issue.

Source: GreyNoise article (archived).

---

Our Methodology

1. Cross‑checking with Terrace data – Continuous monitoring of inbound Telnet traffic to our own sensors.
2. Comparison with other open‑source observations – Leveraging public Telnet scans and community datasets.
3. Routing verification via RIPE Atlas – Running traceroutes from the allegedly‑affected ASes to our servers to confirm reachability.

All measurements were taken as of 18:47 UTC, 12 Feb 2026.

---

Findings

• No new filtering of Telnet traffic by core ISPs was detected.
• Traceroutes from the reported‑affected ASes successfully reached our servers, confirming that the path remains open.
• Telnet traffic continues to be observed from the same networks that GreyNoise claimed had a 100 % drop‑off.
• The discrepancy is most plausibly explained by measurement artifacts (e.g., sampling bias, temporary collection issues) or targeted evasion by specific threat actors who deliberately avoided GreyNoise’s infrastructure.

---

Conclusion

Our analysis indicates that the dramatic Telnet traffic drop reported by GreyNoise does not reflect a network‑wide block imposed by core autonomous systems. Instead, the observed pattern likely stems from methodological quirks or selective avoidance by certain actors. Consequently, the broader security implications suggested by the original report are unfounded.

---

Terrace Security Team
12 February 2026

Evaluating Telnet Scanning

“How could we have missed this?” – our first reaction when we saw the dramatic drop‑off in Telnet traffic. After digging into the data, the answer turned out to be we didn’t.

---

1. Background

• A sudden, coordinated decline from tens of thousands of Telnet scans to zero suggested a network‑wide block.
• However, sessions can be highly correlated: thousands of scans from different networks may stem from a single noisy source.

---

2. Methodology

---

3. Findings

1. No ISP‑level block detected

   • Across all observed ASes (both those listed by GreyNoise and the broader set seen by Terrace), the volume of port 23 Telnet scans remained stable.
   • The “drop‑off” on January 14 was actually part of a minor spike in scanning activity, not a disappearance.

2. External data corroborates

   • Dataplane.org’s Telnet‑login statistics show no significant correlated drop during the same period, aligning with our observations.

3. Implication

   • The apparent traffic collapse was a visual artifact caused by aggregating highly correlated sessions, not a genuine network‑wide mitigation.

---

4. Visual Summary

(Insert table/graph of Telnet scan counts per AS before, during, and after Jan 14 here)

Note: The placeholder above should be replaced with the actual results table or chart generated from the filtered dataset.

---

5. Conclusion

• Telnet scanning activity remained largely unchanged across the examined ASes.
• The perceived “dramatic drop” was a misinterpretation of correlated scan bursts, not evidence of ISP‑level blocking.
• Continuous, AI‑driven monitoring combined with cross‑validation against open‑source threat feeds provides a reliable picture of global scanning trends.

---

References

• GreyNoise – AS attribution data (internal).
• Dataplane.org – Telnet login statistics.

Measuring Telnet Routing with RIPE Atlas

To confirm our results, we performed a RIPE Atlas measurement of Telnet traffic deliverability.

• For the ASes mentioned in the report as being blocked completely, we ran a Telnet traceroute.
• In 55 out of 56 cases, Telnet sessions were successfully established with our server.

These findings confirm that, across the 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.

Possible Explanations

• Common infrastructure – A coordinated drop‑off often points to a shared factor, such as core network backbones.
• Vantage‑point bias – In the context of data from Terrace and other sources, the more likely factor is the observation point itself.
• Scanner avoidance – Internet scanning campaigns are frequently orchestrated by specific actors. It is possible that a scanner has fingerprinted GreyNoise’s apparatus and is actively avoiding it.
  • This phenomenon has been investigated in prior academic research.

Measurement Caveats

• Session‑based metrics can be misleading – A single Telnet exploit attempt may generate many sessions, inflating the apparent significance of trends.
• Potential concentration of activity – The thousands of sessions observed in GreyNoise’s data could stem from a single coordinated actor—or even just a handful of IP addresses.

Recommendation

Analyze trends using unique network endpoints or fingerprintable behaviors rather than raw session counts. This approach provides a more accurate view of the underlying activity.

Takeaways

• The sky is not falling.
• Suggestions that core ISPs are censoring or filtering Telnet traffic are not supported by our observations.

We fully support and echo GreyNoise’s encouragement to take CVE‑2026‑24061 seriously. In fact, the lack of core network protections further exemplifies that edge systems must be patched immediately.

Note: Any changes to operations or policy based on the expectation that Telnet is being filtered at the core are not warranted.