GNU InetUtils telnetd の引数インジェクションで認証を回避（悪用確認済み）

Critical（CVSS 9.8）に分類されるGNU GNU InetUtils (telnetd)の脆弱性です。GNU InetUtils の telnetd に引数インジェクションがあり、リモートの攻撃者が認証を回避できる。telnet の環境変数 USER に「-f root」という値を渡すと、それがログインプログラムへの引数として解釈され、パスワード無しで root としてのログインが成立する。影響は InetUtils 1.9.3 から 2.7 まで（両端を含む）。修正は upstream の2つのコミット（ccba9f74 と fd702c02）で、GNU の bug-inetutils メーリングリストに緩和策を含むアナウンスが出ている。CVSS は CNA の MITRE による 9.8 Critical（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）で、NVD 自身の Primary スコアは付与されていない。CISA KEV には 2026-01-26 に収載され、是正期限は 2026-02-16。GreyNoise は公開直後 18時間で実際のスキャン・悪用の観測を報告している（NVD の参照に Exploit タグ付きで収載）。ランサムウェア利用は Unknown（不明）。

この CVE の正しい終わり方は、たいていの環境では「telnetd を止める」ことである。telnet は平文プロトコルで、2026年のサーバ運用に telnetd が動いている状態そのものが問題なので、パッチ適用ではなくサービス停止・パッケージ削除を第一候補にすべきである。判定手順は3段階。第一に、リッスンしているかを確認する（ss -lntp | grep :23、または inetd/xinetd/systemd socket の telnet ユニットの有効化状況）。第二に、パッケージが入っているかを確認する（dpkg -l | grep inetutils、rpm -qa | grep inetutils、Alpine なら apk info | grep inetutils）。ここで注意すべきは、GNU InetUtils はコンテナの軽量イメージやネットワーク機器・組み込み Linux、そして「telnet クライアントを入れるついでに」導入されたケースで残りやすい点で、サーバ本体より先にコンテナイメージと検査用踏み台を洗ったほうが早いことが多い。第三に、外部から到達可能かを確認する（セキュリティグループ / ファイアウォール規則 / VPC ファイアウォールで TCP 23 の許可があるか）。対応は、(a) telnetd を無効化して削除する、(b) どうしても必要なら 1.9.3〜2.7 に該当するビルドを修正コミット入りの版へ差し替える、(c) 経路を閉じる（TCP 23 の受信を全面拒否し、必要な運用は SSH に寄せる）の順で選ぶ。既に悪用が観測されているため、telnetd を外部公開していた期間があるなら、認証ログ（wtmp / lastlog / auth.log の root ログイン）と不審な cron・SSH 公開鍵の追加を遡って点検する必要がある。完了条件は、TCP 23 で待ち受けるホストが1つも無く、InetUtils の telnetd を残しているホストがあればそれが修正版であること、そして公開実績があった環境では侵害調査が済んでいることである。KEV 是正期限 2026-02-16 は経過しているので、残存があるなら期限超過として扱う。

GNU GNU InetUtils (telnetd) を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-24061）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。

はい。CISA の既知の悪用された脆弱性カタログ（KEV）に登録されており、実環境での悪用が確認されています。米国連邦機関向けの対応期限の目安は 2026/02/16 です。推奨される対応: ベンダーの指示に従って緩和策を適用し、クラウドサービスについては該当する BOD 22-01 のガイダンスに従うこと。緩和策が無い場合は当該製品の使用を停止すること。