MikroTik RouterOS脆弱性2件がKEV入り｜更新と侵害確認を分ける7段階

ルーターを更新したことと、侵害されていないことを確認したことは別です。今回のMikroTik RouterOS脆弱性では、この二つを同じ完了欄に入れないでください。

米国CISAのKnown Exploited Vulnerabilities Catalog（KEV）は2026年9月10日、MikroTik RouterOSのCVE-2026-86060とCVE-2026-67277を追加し、対処期日を9月13日としました。2026年9月12日に取得した一覧はカタログ版2026.09.11で、両件の追加日と期日は変わっていません。ランサムウェアでの利用は「不明」とされています。

この9月13日は、CISAの指令に従う米国連邦政府機関に向けた期日です。日本企業へ同じ法的期限が課されるという意味ではありません。ただし、実際の悪用が確認された脆弱性として、通常の月次更新より優先度を上げる材料になります。CISAの現在の必要措置欄はBOD 26-04とフォレンジック・トリアージ要件を参照しており、古い解説で見かけるBOD 22-01の表記をそのまま使わないよう注意が必要です。

さらに混同しやすい点があります。CERT Polskaが観測した認証なしの完全制御につながる攻撃連鎖は、CVE-2026-67276とCVE-2026-86060です。KEVへ同日に入った二つはCVE-2026-86060とCVE-2026-67277です。末尾が676と677で似ていますが、役割は同じではありません。本稿は「KEVの2件」と「観測された攻撃連鎖の2件」を分けて整理します。

結論：7段階を「更新」と「侵害確認」に分けて記録する

経営側が確認する順番は次のとおりです。

4までが脆弱性の修正です。5以降が侵害確認と影響低減です。更新済みの印だけで案件を閉じると、更新前に作られた未知の利用者や設定が残る可能性があります。逆に、怪しい痕跡が見つからなくても、確認できるログの期間が短ければ「侵害なし」とは断定できません。証拠の範囲と限界を一緒に記録します。

何が起きているのか：三つのCVEを分ける

公式情報で確認できる関係は次のとおりです。

CERT Polskaは、公開されたSSHを入口にCVE-2026-67276とCVE-2026-86060を組み合わせ、認証なしで完全制御できる攻撃を報告しています。両件の深刻度は同報告で9.2です。CVE-2026-67277は帯域試験サービスに関わり、遠隔からサービス不能を起こし得る別の問題として深刻度8.8とされています。

MikroTikのセキュリティ情報は、今回の修正版として7.25 beta3、7.24.2、7.23.4、6.49.21を案内しています。自社が使う系統に合った修正版へ上げる必要があり、単純に最も大きい番号を入れるという意味ではありません。機器の型番、対応系統、現在版、構成の互換性を保守会社と確認してください。

また、MikroTikはSSHを信頼できないネットワークへ公開しないよう求めています。初期設定ではインターネットから遮断されるものの、遠隔保守のために手動で公開されている環境が問題になります。「初期設定は安全」と「現在の設定が安全」は別です。

第1段階：全拠点の機器を特定する

最初の難所は、更新作業ではなく対象機器の把握です。MikroTikを会社が直接購入したとは限りません。拠点開設時に販売店が設置した、監視カメラ会社が回線と一緒に入れた、海外拠点の現地業者が選んだ、予備機として棚にある、といった経路があります。

台帳には最低限、拠点、用途、型番、製造番号、RouterOS版、管理用アドレス、外部公開の有無、保守会社、管理権限の保有者、最終更新日を入れます。請求書や契約書から候補を出し、ネットワーク構成図、管理画面、外部からの資産確認で照合します。

一台も見つからなかった場合も、調査方法を記録します。「担当者に聞いた」だけでは、無人拠点や委託先管理分が漏れます。機器台帳、契約、通信経路の三方向で確認したかを完了条件にします。外部から見える資産の棚卸し方法はASMで管理対象を見つける手順でも解説しています。

第2段階：外部到達性を確認する

攻撃連鎖の観測では、SSHがインターネットへ公開されていることが重要な条件です。そこで、「SSHを使っていますか」ではなく、「信頼されない外部ネットワークから到達できますか」と質問します。社内から接続できることだけを見ても、外部公開は判定できません。

確認対象はSSHだけに絞りません。管理画面、独自管理ポート、帯域試験サービス、VPN終端、遠隔保守元の許可範囲を確認します。全世界から到達できる設定と、保守会社の固定接続元だけを許可する設定では、暴露面が違います。ただし固定元の許可だけでも、保守会社側の端末や認証情報が侵害されれば安全とは限りません。管理はVPN経由にし、多要素認証や接続元制限を組み合わせます。

外部公開を止める変更は、保守作業ができなくなる影響を伴います。現地作業の代替、緊急時の接続経路、設定を戻す承認者を先に決め、変更の前後で到達試験を残します。

第3・4段階：版を確認し、修正版へ更新する

更新前に現在版と設定の控えを取り、機器時刻が正しいか確認します。時刻がずれていると、後のログ調査で出来事の順序が分からなくなります。設定の控えは保全用と復旧用を区別し、侵害が疑われる機器の設定を無条件で別機器へ戻さないようにします。

修正版は、MikroTikが案内する7.25 beta3、7.24.2、7.23.4、6.49.21です。利用系統と機器対応を確認し、可能なら安定版系統を選びます。更新後は再起動、通信、VPN、拠点間接続、名前解決、電話や監視機器など、そのルーターを通る重要業務を試験します。

「自動更新を有効にしている」という回答だけでは完了にしません。更新後の実際の版、再起動日時、失敗した機器、保留理由を一覧にします。長期停止できない拠点は、予備機や迂回経路を用意したうえで保守時間を設定します。

脆弱性情報を経営判断へ翻訳する基本は、脆弱性対応を経営者向けに整理した入門にまとめています。外部保守ツール自体が入口になる問題と責任分界は、N-able N-central事例から見る保守会社への確認事項も参照してください。

第5段階：更新後に侵害確認を行う

MikroTikは、修正版が起動時に既知の侵害痕跡を調べ、該当時は「Flagged」をログや状態に表示すると案内しています。しかし、表示がないことは侵害がなかった証明ではありません。攻撃者が痕跡を消した、ログ保存期間を超えた、既知の検出条件に合わない、別経路から侵害された可能性が残ります。

少なくとも次を確認します。

• 覚えのない利用者、権限、認証鍵が増えていないか
• opsという高権限利用者や、作成経路が不自然な利用者がないか
• 身に覚えのないスクリプト、定期実行、プロキシ、トンネルがないか
• DNS、名前解決、通信転送、ファイアウォールの設定が変わっていないか
• 管理接続や認証失敗に不自然な接続元がないか
• 2026年9月の公式情報に示された接続元指標と一致しないか
• 設定変更時刻と担当者の作業記録が一致するか

CERT Polskaは観測例として、利用者名-2に関するログ、ssh:-2@...経由の追加、高権限のops利用者、82.192.72.4と103.102.31.18という接続元を示しています。これらがなければ安全という意味ではなく、あれば直ちに調査優先度を上げる指標です。公開時点で指標は追加・変更され得るため、必ず最新の原文も確認してください。

侵害が疑われる場合：初期化より先に証拠を残す

未知の利用者や設定、不審な接続が見つかったら、通常更新の案件からインシデント対応へ切り替えます。まず管理経路を制限し、業務影響を見ながらネットワークから隔離します。次にログ、現在設定、利用者一覧、スクリプト、時刻、通信情報を保全します。何を誰がいつ取得したかも記録してください。

証拠を取る前の初期化は、攻撃経路や影響範囲を確認する材料を失います。一方で、侵害された可能性のある設定一式をそのまま復元すると、悪意ある利用者や設定まで戻す恐れがあります。CERT Polskaは、可能なら工場出荷状態から信頼できる基準で再構成し、完全な設定控えを盲目的に戻さないよう勧めています。

ルーターだけ直しても、そこに保存されていた認証情報や通過した通信の秘密が悪用される可能性があります。管理者のパスワード、SSH鍵、VPN資格情報、連携先の秘密情報を対象に、失効と再発行の順序を決めます。同じ認証情報を他拠点で使い回していれば全拠点が対象です。

影響範囲が判断できない場合は、ログを消さずにインシデント対応支援へ切り替えてください。実機の設定・到達性を第三者が確認する入口は脆弱性診断です。

第6・7段階：認証情報を変え、継続監視へ移す

更新と調査が終わったら、管理者アカウントを個人単位にし、共有アカウントを減らします。不要な利用者と鍵を無効化し、保守会社の接続元と作業時間を限定します。緊急用アカウントは通常利用せず、使用時に経営側へ通知されるようにします。

監視では、管理ログイン、利用者作成、権限変更、スクリプト変更、DNS変更、外部への新規接続、設定の保存・復元を記録します。ルーター内だけにログを置くと侵害時に消される可能性があるため、外部の記録先へ送ります。通知先が個人一人だけになっていないかも確認します。

一度の緊急対応で終えず、毎月「新しいKEVに該当しないか」「公開管理機能が増えていないか」「更新保留が残っていないか」を確認します。社内で回らない場合はセキュリティ運用伴走で、機器台帳、脆弱性判定、委託先への依頼、証跡確認を定例化できます。

保守会社へそのまま送れる確認文

CISA KEVにMikroTik RouterOSのCVE-2026-86060とCVE-2026-67277が2026年9月10日に追加されたことを確認しました。当社および各拠点について、①MikroTik機器の有無と全台一覧、②現在のRouterOS版、③SSH・管理画面・帯域試験サービスの外部到達性、④修正版への更新日時と更新後の版、⑤Flagged表示の有無、⑥未知の利用者・スクリプト・定期実行・プロキシ・トンネル・DNS・転送設定の確認結果、⑦保存できるログの期間、⑧不審時の隔離・証拠保全・再構成手順、⑨認証情報変更の対象、⑩今後の監視方法を証跡付きで回答してください。更新済みと侵害確認済みは別項目にしてください。

「対象なし」という回答には、何を根拠に全拠点を確認したかを求めます。「更新済み」という回答には、更新前後の版と日時を求めます。「Flaggedなし」という回答には、未知の利用者や設定を別途確認したかを求めます。この三段階だけでも、口頭の安心と検証済みの状態を区別できます。

回答期限も設定してください。外部公開があり脆弱な版なら当日、機器はあるが外部公開なしなら翌営業日、機器の所在確認から必要なら三営業日など、状態ごとに分けます。全拠点の回答がそろうまで案件を閉じず、未回答を「対象なし」に数えないことが重要です。経営報告では、対象台数、更新完了台数、侵害確認完了台数、要調査台数、所在不明台数の五つを示します。

保守契約の範囲外という回答が来た場合も放置せず、緊急作業の見積、社内で実施できる範囲、別の調査会社へ渡す情報を分けます。責任分界が曖昧なこと自体を今回の改善項目として記録してください。

経営者が避けたい6つの判断ミス

1. 販売店へ任せているから自社の責任ではない。 業務停止や情報漏えいの影響を受けるのは自社です。作業を委託しても、対象範囲と完了証拠を確認する責任は残ります。

2. 期日を過ぎたからもう遅い。 期日は対応優先度を示します。過ぎても更新と侵害確認の必要性はなくなりません。速報性ではなく、今後も使える7段階で実施してください。

3. KEVの二つが、そのまま観測された攻撃連鎖だと思う。 実際に報告された連鎖は67276と86060です。同日KEVの二つは86060と67277です。番号を取り違えると、SSH公開と帯域試験サービスの確認が混ざります。

4. Flaggedがなければ非侵害と判定する。 検出できる既知痕跡がないことしか示しません。ログ期間と追加確認の範囲を明記します。

5. 設定控えがあるので初期化して戻せばよい。 侵害後の設定を戻せば、悪意ある変更も復元しかねません。証拠を保全し、信頼できる基準から再構成します。

6. この一件だけを直して完了する。 同じ保守経路、共有認証情報、外部公開方針が他機器にも残ります。拠点ルーター、VPN、UTM、遠隔保守装置を一つの台帳で管理します。

GXOへ相談する判断線

「MikroTikがあるか分からない」「保守会社の回答を技術的に評価できない」「更新済みだが侵害確認の証跡がない」のいずれかに当てはまれば、セキュリティ優先順位レビューが入口です。機器を売り替える前に、外部公開、脆弱な版、未知の設定、ログ、認証情報、保守責任を一枚に整理します。

ここから、実機確認が必要なら脆弱性診断、平時の月次運用が必要ならセキュリティ運用伴走、不審な痕跡があればインシデント対応へ分岐します。調査範囲を先に決めるため、緊急性だけで全機器交換を勧める相談ではありません。確認可能な証拠と残る不確実性を分け、経営者が停止、継続、再構成を判断できる状態を作ります。

FAQ

Q. 日本企業も9月13日までに対応する法的義務がありますか。

A. 本稿で確認した9月13日は、CISAの指令対象となる米国連邦政府機関向けの期日です。日本企業への同じ法的期限ではありません。ただし実悪用が確認されたことを示すKEV掲載は、対応優先度を上げる根拠になります。

Q. どの版へ更新すればよいですか。

A. MikroTikは7.25 beta3、7.24.2、7.23.4、6.49.21を修正版として案内しています。現在の系統と機器の対応に合う版を選ぶ必要があるため、型番と現在版を確認し、公式情報に従ってください。

Q. 更新後にFlaggedが出なければ安全ですか。

A. 安全とは断定できません。未知の利用者、スクリプト、定期実行、プロキシ、トンネル、DNS、転送設定、外部接続を確認し、保存ログの期間も記録してください。

Q. CVE-2026-67277はSSHの認証回避ですか。

A. いいえ。CERT Polskaが報告したSSHを使う攻撃連鎖はCVE-2026-67276とCVE-2026-86060です。CVE-2026-67277は帯域試験サービスの認証不備などに関わる別の問題です。

Q. 不審な利用者が見つかりました。すぐ初期化すべきですか。

A. 先に隔離と証拠保全を検討してください。初期化で調査材料が消えるため、ログ、設定、利用者、スクリプト、時刻を保全し、インシデント対応として影響範囲を判断します。業務影響が大きい場合は専門家へ連絡してください。

この記事の確認範囲

本稿は2026年9月12日、CISA KEVのJSON、MikroTikの2026年9月セキュリティ情報、CERT Polskaの調査報告を取得して確認しました。KEVの版は2026.09.11、両件の追加日は9月10日、期日は9月13日です。修正版、SSH公開への注意、Flaggedと追加確認、観測された攻撃連鎖、指標は各原文に基づきます。個別機器が侵害されたかは本稿だけでは判定できません。公開後もKEVの必要措置、修正版、指標、既知のランサムウェア利用に変更がないか確認します。

参考資料

• Known Exploited Vulnerabilities Catalog（CISA）
• September 2026 Vulnerability（MikroTik）
• Vulnerabilities in MikroTik RouterOS actively exploited（CERT Polska）