JPCERT/CCが2026年7月30日に公開した「TSUBAMEレポート Overflow（2026年4〜6月）」で、2026年5月初旬にMiraiの特徴を持つ23/TCP（Telnet）宛パケットが急増したことが報告されました。注目すべきはその発生源です。監視カメラやルータといったIoT機器ではなく、cPanelが動作しているとみられるホスティング事業者のサーバが多数を占めていました。原因はcPanel/WHMの認証バイパス脆弱性CVE-2026-41940（CVSS v3.1で9.8）の悪用とみられています。
そして日本を送信元とする通信も、同じ期間に増加前の約15倍に膨らんでいました。つまり国内のサーバが、他者を探索する側に回っていたということです。
この記事でわかること
- 2026年5月のMirai系23/TCP急増で何が起きていたのか
- 「Mirai＝IoT機器のマルウェア」という理解のどこが危ういのか
- cPanel／WHMとは何者で、自社のどこに潜んでいるのか
- 海外センサーとの比較から見える、探索されているポートの実像
- 自社が加害者側に回らないために点検すべきこと
cPanel／WHMとは何者か
cPanelとは、Linuxサーバ上のWebサイト・メール・データベース・FTPなどをブラウザのGUIから管理するためのホスティング管理パネルです。対になるWHM（WebHost Manager）は、サーバ全体やアカウントを管理する上位の管理画面で、公式ドキュメントも「cPanel＆WHM」として一体で提供されています。
ホスティング事業者がWHMでサーバ全体を運用し、契約者が自分の領域をcPanelで操作する役割分担が一般的です。ここが重要で、自社でcPanelを導入した記憶がなくても、契約しているレンタルサーバや共用ホスティングの管理画面がcPanelであることは珍しくありません。JPCERT/CCの四半期レポートでも、本脆弱性の国内被害組織はホスティング事業者のテナントとして利用していたと記されています。「うちは使っていない」と即断せず、まずは契約先の管理画面のURLとログイン画面の表記を確認してください。/cpanel（2083/TCP）や/whm（2087/TCP）といったパスとポートが典型です。
何が起きたのか
TSUBAMEは、JPCERT/CCが国内外に設置したセンサーに届くパケットを継続的に観測するインターネット定点観測システムです。報告によると、Miraiの特徴を持つ23/TCP宛パケットは2026年4月30日に急増し、その後ゆっくりと減少しました。
JPCERT/CCが送信元IPアドレスを調べたところ、複数のホスティング事業者に割り当てられたアドレスが多数確認され、それらにWebブラウザでアクセスすると多くでcPanelの管理画面が表示されたとしています。観測データだけで原因までは断定できないとしつつ、同時期に公開されたCensysのブログやNICTER解析チームの発信を踏まえ、CVE-2026-41940を悪用したMirai／Mirai亜種の感染活動ではないかと推測しています。
この脆弱性は、cPanel＆WHMのログイン処理に存在する認証バイパスで、認証なしで管理画面へのアクセスを許すものです。米国NVDの登録は2026年4月29日。影響範囲はバージョン11.40以降の広範なブランチにおよび、ブランチごとに修正版が示されています。急増が始まった4月30日は、脆弱性公表の直後にあたります。
なぜ「サーバ」がMiraiに感染したのか
Miraiは2016年に大規模DDoS攻撃で知られるようになったマルウェアで、初期の感染対象がネットワークカメラやルータだったため「IoT機器のマルウェア」として記憶されている方が多いはずです。しかしJPCERT/CCは今回の報告で、Mirai／Mirai亜種は特殊な機器に限定して感染するわけではなく、サーバにも感染すると明確に述べています。
実装としてのMiraiはLinux上で動作し、脆弱な認証情報や既知の脆弱性を突いて侵入し、次の標的を探索して増殖します。侵入口さえ開いていれば、その先が組み込み機器かレンタルサーバかは本質的な違いになりません。今回はcPanelの認証バイパスという「よく効く入口」が公開されたため、感染がサーバ側に偏ったと理解するのが妥当でしょう。IoT機器の棚卸しリストだけを見て「うちにMiraiが感染する機器はない」と判断していた組織は、前提の見直しが必要です。
日本発のパケットも約15倍｜加害者側に回るリスク
報告では、日本を送信元とする23/TCP宛パケットも同じ期間に増加前から約15倍に増えており、ピーク時の送信元には複数のホスティング事業者が確認されたとしています。地域別では米国が最多で、次いでドイツ、フランス、カナダなどでも5月1日前後に急増が見られました。特定地域に限った感染ではなく、インターネット全域に拡大したものとJPCERT/CCは推測しています。
ここが情シスにとって一番のポイントです。この事象で自社が受けるダメージは「攻撃を受ける」だけではありません。自社が契約・運用しているサーバが乗っ取られ、他組織を探索するボットの一員として稼働してしまうという形をとります。踏み台化した側は、通信量の増加、IPアドレスのレピュテーション低下によるメール不達、契約先からの利用停止、そして被害組織からの問い合わせ対応といった実害を負います。境界機器が攻撃インフラに転用されるORB化や、レジデンシャルプロキシとしての悪用と同じ構図です。
海外センサーとの比較で見えるもの
「TSUBAMEレポート Overflow」は、四半期レポート本体には載らない海外センサーの観測動向を補足するブログです。国内センサーの上位ポートは四半期レポートを扱った記事で、前四半期（2026年1〜3月）の傾向は別記事で紹介しました。本記事の独自部分は、国内外のセンサーを並べた比較と、上記のMirai急増の原因分析です。
報告によれば、国内より海外のセンサーで多くのパケットを観測しており、23/TCPがほとんどのセンサーで首位、一部では443/TCPが上回りました。センサーごとの上位10ポートを一部抜粋すると次のとおりです。
| 順位 | 国内センサー1 | 北米センサー2 | 欧州センサー1 |
|---|---|---|---|
| 1 | 23/TCP | 443/TCP | 23/TCP |
| 2 | 443/TCP | 80/TCP | 443/TCP |
| 3 | ICMP | ICMP | 80/TCP |
| 4 | 80/TCP | 8080/TCP | ICMP |
| 5 | 22/TCP | 22/TCP | 22/TCP |
| 6 | 3389/TCP | 3389/TCP | 8080/TCP |
| 7 | 8080/TCP | 23/TCP | 3389/TCP |
| 8 | 5555/TCP | 8728/TCP | 8728/TCP |
| 9 | 8443/TCP | 8443/TCP | 8443/TCP |
| 10 | 2222/TCP | 2222/TCP | 2222/TCP |
JPCERT/CCは、80/TCPや8080/TCP、22/TCPなどがほぼすべてのセンサーで観測されていることから、広範囲のネットワークに対してスキャンが行われていることを示唆すると述べています。
実務的に効くのは、上位に並ぶポートが「うっかり開いたまま」になりやすい顔ぶれだという点です。22/TCPと2222/TCPが両方入っているのは、SSHをポート番号だけずらして隠したつもりの設定も探索対象になっていることを示します。8080/TCPや8443/TCPは検証用に立てた管理画面、3389/TCPはリモートワーク対応で一時的に開けたRDPが典型です。8728/TCPや5555/TCPのように用途が一見わかりにくいポートは、そこで何が待ち受けているのかを製品の公式ドキュメントで確認するところから始めてください。
現場目線の課題
正直なところ、この手の話で一番つらいのは「自社の資産台帳に載っていないサーバ」です。事業部門が独自に契約した共用ホスティング、キャンペーン用に立てて放置された検証環境、退職者が管理していたドメイン。情シスの目が届く範囲は実際の攻撃面より常に狭い、というのが実感です。禁止だけでは影のIT資産が増えるので、申請ルートを用意して周知するほうが結局は効きます。
しかもcPanelのような管理パネルは、更新の責任が事業者側か自社かが契約形態で変わります。専用サーバやVPSの自前運用なら自社の責任ですが、共用ホスティングなら事業者任せです。ここを曖昧にしたまま「たぶん事業者がやってくれている」と考えるのが一番危ない状態です。実際、JPCERT/CCの四半期レポートの対応事例では、被害組織が事業者に痕跡調査の協力を求めたものの、利用契約上の制約を理由に十分な協力を得られていません。脆弱性が直った後に残るのは「調べられるかどうか」という契約の問題です。パッチ適用とは別に、インシデント時のログ提供範囲を契約書で確認しておく価値があります。
情シスはどうすべきか
個別の対策チェックリストを並べるより、公的機関の指針を土台にするほうが確実です。まずは以下を参照してください。
- 中小企業の情報セキュリティ対策ガイドライン（IPA）：外部委託・クラウド利用時の責任分界を含め、体制づくりの土台として使えます。
- セキュリティインシデント対応 机上演習教材（IPA）：「自社サーバが踏み台になった」という想定は演習の題材として現実的です。
今回の事象に固有の観点として、JPCERT/CCが挙げる対策は「脆弱性への早期対応、リモートアクセスの制限、脆弱なパスワードの変更」の3点です。感染が疑われる場合は、プロセスやネットワーク通信が設定どおりに動作しているかを中心に確認するよう推奨しています。外向きの不審な通信、特に見覚えのない23/TCP宛の大量発信は、踏み台化したときの分かりやすい兆候です。
まとめ
- 2026年5月初旬のMirai系23/TCP急増は、IoT機器ではなくcPanelが動くホスティング事業者のサーバが発生源とみられ、CVE-2026-41940（認証バイパス、CVSS v3.1で9.8）の悪用が推定されています。
- Mirai／Mirai亜種は特殊な機器に限定して感染するわけではなくサーバにも感染します。IoT機器の棚卸しだけで「該当なし」と判断する前提は見直しが必要です。
- 日本発のパケットも約15倍に増えており、自社は被害者だけでなく加害者側に回りうるという点が実務上の要点です。契約先の管理パネルの更新責任と、インシデント時のログ提供範囲を確認しておきましょう。
