SSH経由で悪用が進むMikroTik RouterOSの脆弱性 | eSecurity Planet

攻撃者はMikroTik RouterOSの脆弱性を悪用し、SSHがインターネットから到達可能なルーターに対して完全な管理者権限を奪取しています。

実際の攻撃は少なくとも9月2日から観測されており、これはMikroTikがパッチ適用済みのRouterOSビルドをリリースする1日前にあたります。管理者は脆弱なデバイスを直ちにアップデートするとともに、修正版の導入前に攻撃者による侵入がなかったかを確認する必要があります。

CERT Polskaは6件のRouterOS脆弱性を特定し、攻撃者が2つの欠陥を組み合わせた攻撃チェーン(同組織がMikroTrickと命名)を実際に悪用していることを確認しました。このチェーンを使えば、インターネットに公開されたデバイスを認証なしで乗っ取ることが可能です。CERTによれば、リリース済みのパッチはこれまで観測された攻撃を阻止できるとしています。

公表されたMikroTik RouterOSの脆弱性

6件の脆弱性のうち2件はCVSSスコア9.2と評価されています。

CVE-2026-67276は、RSA公開鍵の検証が不完全であることに起因するSSH認証バイパスです。攻撃者はユーザー名と、許可されたRSA鍵の公開モジュラスさえ把握していれば、対応する秘密鍵を持たずに認証を突破できる可能性があります。

CVE-2026-86060は、RouterOSが特定のSSHユーザー名を処理する方法に関わる脆弱性です。細工されたユーザー名によって、生成されたセッションに割り当てられるポリシーを操作でき、結果として完全な管理者権限の獲得につながる恐れがあります。

残る脆弱性としては、帯域幅テストサービスに存在するCVE-2026-67277、X.509証明書検証に関わるCVE-2026-67278、SSH認証状態に関するCVE-2026-67279、WebFigインターフェースのCVE-2026-67281が挙げられます。技術的な詳細はCERT PolskaのCVEアドバイザリで確認できます。

今回の実攻撃に関する注意喚起では、CERTが観測した攻撃で使用された具体的な2つのCVE番号までは特定されていません。一方、Tolmoの研究者は、CVE-2026-67279とCVE-2026-86060を組み合わせることで、認証なしでの乗っ取りを独自に再現しています。

この再現された攻撃経路は、SSHの状態管理に関する欠陥を起点としています。クライアント側から鍵の再交換(rekey)を要求した後、CVE-2026-67279によって未認証のクライアントが、本来は認証を必要とするはずのセッション状態に到達できてしまいます。その後、CVE-2026-86060を用いることで、そのセッションをRouterOSの完全な権限を持つものへと変換できます。

防御側にとっては、実際に悪用が進行していることとインターネットへの露出という2点から、これらの脆弱性は個々のスコアが示す以上に優先度の高い対応が求められます。これはCVSSだけに頼らない脆弱性管理の考え方が広まりつつあることとも重なります。

修正が適用されたRouterOSのバージョン

MikroTikは、以下のバージョンで修正が施されていると発表しています。

• 7.25beta3
• 7.24.2
• 7.23.4
• 6.49.21

MikroTikは、たとえ設定上ただちに影響を受けない場合であっても、アップグレードを推奨しています。デフォルト設定ではインターネットからのSSHアクセスはブロックされていますが、管理者が信頼できないネットワークに対してSSHを開放しているデバイスは、今回観測された攻撃において最も明確なリスクにさらされています。

すぐにパッチを適用できない場合、CERTはSSH、WWW/WWW-SSL、帯域幅テストへのアクセスを、信頼できる管理用ネットワークに限定するよう推奨しています。また、パッチ未適用のデバイスからの発信TLS接続や、RouterOSに組み込まれたSSHクライアントの使用も避けるべきだとしています。

公開されている管理サービスを減らすことで、当面の攻撃対象領域を縮小できますが、これはセキュリティアップデートの適用に代わるものではありません。

RouterOSデバイスに侵害の痕跡がないか確認する

アップデートによって既知の脆弱性は解消されますが、それ以前にデバイスが侵害されていたかどうかまでは判別できません。

パッチ適用済みのRouterOSリリースでは、起動時に設定を確認し、不正な変更を示す既知の痕跡がないかをチェックします。不審な設定が検知された場合、RouterOSは該当するエントリを無効化し、重大度の高いログメッセージを記録した上で、デバイスのステータスをFlaggedに設定します。

管理者は以下のコマンドでこのマーカーを確認できます。

/system/device-mode/print

Flaggedになっていないルーターを、自動的に「安全」とみなすべきではありません。CERTによれば、この仕組みが検知できるのは限定的な侵害の痕跡にとどまるとしています。

• login failure for user -2 from <ip> via ssh
• user <name> added by ssh:-2@<ip>
• opsという名前の、想定外の高権限ユーザーの存在
• 82.192.72.4からの攻撃成功事例
• 103.102.31.18からの悪用試行

CERTは、分析した攻撃成功事例(opsアカウントの作成を含む)について、その発信元を82.192.72.4まで追跡しています。この活動は少なくとも9月2日まで遡ることが確認されています。

管理者は、心当たりのないユーザー、スクリプト、スケジューラータスク、プロキシサーバー、トンネル、その他の設定変更についても確認すべきです。公表された痕跡が見つからないからといって、不正な活動がなかったとは断定できません。

MikroTikルーターが侵害された場合の対応

デバイスがFlagged状態になっている、あるいはその他の侵害の証拠が見つかった場合は、単に不審なアカウントや設定エントリを削除するだけでなく、インシデント対応の手続きを開始すべきです。

ルーターをリセットする前に、まずネットワークから隔離し、ログと設定情報を保全してください。調査に必要な証拠を収集する前にFlaggedマーカーを消去してはいけません。

証拠の保全が完了した後は、デバイスを工場出荷時の設定に戻し、信頼できる設定情報をもとに再構築してください。ルーター経由でアクセス可能だった可能性のあるパスワード、鍵、その他の機密情報はすべてローテーションしてください。

侵害された可能性のあるデバイスから取得したフルバックアップを、そのまま無条件に復元してはいけません。悪意のあるユーザー、スクリプト、スケジュールされたタスク、その他の不正な設定情報が、そのまま一緒に復元されてしまう恐れがあります。

これは、より広範なサイバーレジリエンスと復旧にも通じる原則です。設定内容自体の信頼性を確保できない限り、デバイスをオンラインに復帰させるだけでは不十分です。

まずパッチ適用、その後に調査を

影響を受けるRouterOSデバイスは、直ちにアップデートすべきです。中でもインターネットに露出したSSHは最優先で対応する必要があります。

9月2日以降に脆弱な状態で一般公開されていたルーターについては、パッチ適用に続けてログと設定情報のレビューを行うべきです。アップグレードに成功すれば、修正済みの攻撃手法は防げますが、攻撃者が事前に得たアクセス権限そのものを無効化することはできません。

RouterOSのバージョンを確認し、管理アクセスを制限し、Flaggedステータスをチェックし、公表されている痕跡を調査し、既知の正常な状態と一致しない設定がないか点検してください。

あわせて読みたい: Googleは、CVE-2026-85046が実際の攻撃で悪用されていることを確認したことを受け、2026年に入って6件目となるChromeの悪用済みゼロデイにパッチを適用しました。