13
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【Telnet】2026年1月14日、インターネットからtelnetが消えた

13
Last updated at Posted at 2026-02-23

2026/01/26にCVE-2026-24061という脆弱性が公開されました。
telnetの接続リクエストに-f rootって入れたらパスワードなしでrootになるという、冗談みたいな脆弱性です。

このバグが紛れ込んだのは2015/03/19のことであり、CVE-2014-8104のバグ修正として導入されたようです。
スコア6.8の脆弱性を修正するために入り込んだスコア9.8の脆弱性は、人知れず10年以上telnetdの中に潜んでいました。

さてこのバグ、Kyu Neushwaisteinという人が2026/01/19に発見したとされているのですが、実はその一週間も前に大変興味深い現象が発生していました。

ということで以下はセキュリティ企業GreyNoiseが発表したブログ記事、2026-01-14: The Day the telnet Diedの紹介です。

2026-01-14: The Day the telnet Died

GreyNoiseの観測によると、2026年1月14日に世界中のTelnetトラフィックが激減しました。
トラフィックの59%が減少し、18のAS番号が停止し、5つの国が消滅しました。
その6日後、CVE-2026-24061が公開されました。
可能性のひとつは、偶然の一致です。

UTC 2026年1月14日21時ごろ、インターネットに異変が起こりました。
GreyNoise Global Observation Gridは、世界中のtelnetトラフィックが突如として減少したことを記録しました。
これは漸減ではなく、検出器のバグでもなく、データパイプラインの問題でもなく、階段状減少でした。
ある時間までは74000セッション、次の1時間は22000セッション、さらにその次は11000セッションまで減少し、そしてその状態が継続しました。

6日後の1月20日CVE-2026-24061のセキュリティアドバイザリがoss-securityに公開されました。
1月26日に、CISAはこれを脆弱性カタログに登録しました。

脆弱性が公開されたあと18時間の動きについては別の記事を掲載しました。
今回は、CVEに先立って発生した世界的なtelnetトラフィックの変動と、これらの出来事が関連していると考えられる理由について解説します。

The Drop

01.png

2025年12月1日から2026年1月14日まで、GreyNoiseはtelnetセッションを一日平均914000、トータルで5120万観測しました。
これをベースラインと呼ぶことにしましょう。

1月14日21時に、1時間あたりセッション数が一瞬でベースラインから65%減少しました。
2時間後には83%の減少になりました。
その後は一日あたり373000セッション程度に落ち着き、2月10日の本稿執筆時点では59%の減少が継続しています。

これは漸減ではありません。
時系列データがその状況を物語っています。

UTC 時間あたりセッション数 メモ
Jan 14, 19:00 73,900 通常
Jan 14, 20:00 64,722 通常
Jan 14, 21:00 22,460 65%減少
Jan 14, 22:00 11,325 83%減少
Jan 14, 23:00 11,147 下げ止まり
Jan 15, 00:00 12,089 下げ止まり

このような階段的な変化は、telnetを使用しているユーザがたまたま一斉にtelnetをやめたというわけではなく、ルーティングの構成自体が変わったことが原因であると考えられます。

What Went Silent

それぞれ5万セッション以上というかなりの数があった18のAS番号からのアクセスが、1月15日以降完全にゼロになりました。
特に注目すべきAS番号には以下のようなものがあります。

・Vultr (AS20473) 以前は382000セッション、以降ゼロ。
・Cox Communications (AS22773) 150000からゼロ。
・Charter/Spectrum (AS20115) 141000からゼロ。
・BT/British Telecom (AS2856) 127000からゼロ。

ジンバブエ・ウクライナ・カナダ・ポーランド・エジプトの5か国からのtelnetがなくなりました。
減った、ではなく完全に消滅です。

いっぽう、大手クラウドプロバイダからのセッションは影響を受けておらず、むしろ上昇しました。
AWSは78%の増加、Contaboは90%の増加です。
DigitalOceanは+3%で、ほぼ横ばいでした。
クラウドプロバイダは、通常のトランジットプロバイダーをバイパスするプライベートピアリングを提供しています。
いっぽう個人向けや企業向けのプロバイダは、普通はそのようなものを提供していません。

Where’s the Filter?

このパターンは、少なくとも1社以上の北米のTier1トランジットプロバイダーが、ポート23をフィルタリングしたということを示しています。

UTC21時、すなわちEST16時という時間帯は、アメリカにおけるメンテナンス時間帯に当てはまります。
アメリカの一般向けISPは壊滅しましたが、クラウドプロバイダはこの変化を回避するためピアリングを行いました。
Verizon/UUNET (AS701) は79%減少しました。
ここはTier1バックボーンなので、ここがフィルタリングの主体であるか、フィルタリング事業者のすぐ上流に位置していることが示唆されます。
残りの21%は、フィルタリングされていないルートを通ったことを示しています。

アメリカがホストするインフラへのアクセスに太平洋・大西洋を経由している国が最も大きな影響を受けました。
欧州と直接ピアリングしている国はほとんど影響を受けませんでした。
フランスは+18%、ドイツは-1%です。

中国のバックボーンプロバイダ、中国電信と中国聯合通信は両方とも等しく59%減少しました。
この結果は、フィルタが太平洋横断ケーブルの中国側ではなく、米国側にあることを意味しています。
もしこれが中国のファイアウォールだったのであれば、通信事業者間に差が表れたであろうし、もっと莫大な減少になったことでしょう。

Then Came the CVE

CVE-2026-24061は、GNU InetUtils telnetdの認証をバイパスするクリティカルな脆弱性です。
telnetdがネゴシエーション中にUSER環境変数を処理する際にインジェクションが存在しました。
攻撃者がユーザ名として-f rootを送信すると、login(1)は認証処理を省略してrootユーザにします。
ユーザによる操作も、パスワードも不要です。
この脆弱なコードは2015年のcommitで入り込み、11年近くも見逃されていました。

日付 イベント
Jan 14 Telnetが消え始めた
Jan 20 CVE-2026-24061がoss-securityに投稿された
Jan 21 NVDが公開、最初のエクスプロイトを確認
Jan 22 GreyNoise、最初の18時間について投稿
Jan 26 CISAがCVE-2026-24061をKEVに追加

興味深いのは、telnetの切断とCVEに6日の間隔があることです。
telnet切断が先であるため、一見するとCVEがその原因であることはありえません。
しかし、この両者は原因結果という関係性ではありません。

The Supposition

協調的脆弱性開示プロセスは、公開されたときから始まるわけではありません。
公開情報によると、この脆弱性を発見した研究者 Kyu Neushwaistein / Carlos Cortes Alvarezは1月19日にこれを報告しました。
しかし、パッチの準備、勧告の作成、KEVへの追加といった調整は、通常、公開よりもずっと前から始まります。

我々の想像としては、おそらく以下のようなことが起こりました。
telnetdに容易に悪用可能な脆弱性があるという事前通知が、インフラ関係者に届きました。
バックボーンプロバイダやトランジットプロバイダーは、この要請にこたえたか、もしくは独自評価の結果、ポート23にフィルタリングを実行しました。
フィルタリングは1月14日に開始され、その後1月20日に公開されました。

これによって以下のような状況証拠が説明できます。

・タイミングのずれ。
・フィルタリングの特異性。TCP23のみで、一般的なルーティング操作等ではない。
・影響範囲。トランジットは影響を受けるが、ピアリングには影響がない。
・持続性。数週間経過後もまだ継続している。

とはいえ、これを証明することはできません。
バックボーンのダウンは全くの偶然かもしれないし、ISPがWannacryのころから長年進めてきたレガシープロトコル排除の最後のステップがたまたまその日になっただけかもしれません。
相関関係も、タイミングのよさも、メカニズムの一致も、必ずしも因果関係とイコールではありません。

What the Post-Drop World Looks Like

1月14日以降のtelnetトラフィックは、周期的な急増と急減を繰り返す鋸歯パターンを繰り返しています。
たとえば1月28日は806000セッション、1月30日は191000セッションです。
これはフィルタを迂回するルーティングと、迂回路へのフィルタ適用の攻防を表しているのかもしれません。

周で平均すると、大まかな傾向が見て取れます。

日付 日平均セッション数 ベースライン比
Dec 01 1086744 119%
Jan 05 985699 108%
Jan 19 363184 40%
Jan 26 407182 45%
Feb 02 322606 35%

フィルタ前のおおよそ1/3の量であり、わずかに減少傾向にあります。

Practical Implications

影響範囲。

GNU Inetutils telnetdをどこかで使っているのであれば、バージョン2.7-2以降にアップグレードするか、サービスを無効化してください。
11年間という期間を考えると、組み込み機器やネットワーク家電、レガシーLinuxなど多くの環境で使われている可能性が高いでしょう。

CISA KEVの脆弱性対策期限は2026年2月16日です。
GreyNoiseは、脆弱性の開示からわずか数時間後には攻撃の試行を観測しました。
2月冒頭には一日2600件というピークを迎え、その後攻撃数は徐々に減少しています。

もしあなたがネットワーク事業者で、もしまだポート23をフィルタリングしてなかったとすれば、バックボーンプロバイダによるフィルタリングが助けになったことでしょう。
トランジットプロバイダーのかなりの上層にいる誰かが、telnetトラフィックを伝送する価値はもうないと判断したようです。
そしておそらく、それは正しい判断でしょう。

この件についてなにか知っている人がいましたら、ぜひ教えてください。

感想

ISP単位とかではなく、ASレベルでTCP23フィルタリングを行っているバックボーンプロバイダがいるぞ、という話でした。
今後他プロバイダにも広がっていって最終的にOP25Bのように誰も使えなくなるのか、一部の暴走みたいな話で終わってしまうのかは不明です。
しかし、telnetが使えなくなった!みたいな悲鳴を全然見かけないので、実際まともな用途でtelnetを使っているユーザは既にほとんどいないのかもしれません。

SSHがほぼ上位互換なので、今どきあえてtelnetを使う意味はほぼ全くありません。
Linuxなどではデフォルトでは有効化されないため、起動せずに眠っているだけであれば無害です。
さらに最近のディストリビューションではインストールすらされなくなったようで、わざわざインストールしないと使うこともできないことが多いようです。

では何が狙われるかといえば、それはもちろん古いネットワーク機器です。
ルータなどの機器は外部からアクセスできる手段がいくつか開いているわけですが、その中にtelnetが含まれていることがあります。
たとえば無線ルータ用ファームウェアZRouterなどは、わりと最近までデフォルトでtelnetが有効だったみたいです。
さらには外部からtelnetを有効化できるような機種もあるようです。
こういった機器が乗っ取られ、悪用される危険性があります。

今後ポート23フィルタリングが広まればtelnetによる攻撃は物理的に不可能になっていくかもしれませんが、古いバージョンを使っているネットワーク機器は、それ以外にも脆弱性が存在する可能性が非常に高いです。
古い機器はそれだけで危険ということで、CISAはサポート切れの機器は廃棄するよう政府機関に対して指示を出しました
みんなも3Rなど一切気にせず古いものはどんどん捨てていきましょう。

そういえば自宅のルータも10年以上使っている気がするな。
と思って調べてみたところ2012年発売だったけどtelnetは非対応だったから安心でした(安心ではない)

13
1
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
13
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?