Hackers Exploiting MikroTik RouterOS Vulnerability in the Wild to Gain Complete Network Access
2026/09/07 CyberSecurityNews — MikroTik が公表したのは、未認証のリモートアクセスを可能にする MikroTik RouterOS の脆弱性の情報であり、攻撃者による積極的な悪用が確認されたと警告している。2026年9月3日に MikroTik は、RouterOS に影響を及ぼす深刻なセキュリティ脆弱性を発見し、7.25 beta 3/7.24.2/7.23.4/6.49.21 など、各リリース・チャネルで修正版を提供したことを明らかにしている。ネットワーク管理者に求められるのは、侵害がネットワーク全体の掌握へ発展する前に、脆弱なデバイスへ直ちにパッチを適用することである。

MikroTik は最初のアドバイザリで、現時点では技術的な詳細を意図的に開示していないと明言し、その目的は、攻撃者が公開情報を基に脆弱性を解析する前に、管理者がアップデートするための時間を確保することにあるとしていた。しかし、こうした慎重な対応にもかかわらず、情報公開後には実際の悪用が確認され、さらにフォーラム利用者や研究者が攻撃の仕組みを短期間で解明した。
MikroTik RouterOS の脆弱性
MikroTik 公式サポート・フォーラムでの詳細な議論によると、この脆弱性は複数の RouterOS サービスが使用するコア・ライブラリに存在する。このコードベースを利用して構築された、外部へ公開されているサービスが、攻撃のエントリーポイントとして悪用される可能性がある。
この脆弱性をリバース・エンジニアリングしたフォーラム投稿者の1人は、脆弱性が SSH に関連することを確認している。未認証のリモート攻撃者は、パスワード認証/SSH 鍵ベース・ログインのいずれかを使用しているルーターに対して、シェル・アクセスを取得する可能性がある。インターネットなどの信頼できないネットワークから SSH サービスへ到達可能な場合、パッチ未適用のルーターは脆弱な状態にある。なお、この脆弱性の悪用に際して、認証情報の窃取/ユーザー操作などは必要ない。
ラトビアの国家 CERT も警告を発出し、MikroTik Router を標的とする攻撃活動が著しく増加していることを裏付けている。同機関は組織/一般ユーザーの双方に対して、MikroTik がリリースしたパッチ適用済み Build への速やかなアップデートを求めている。同機関のガイダンスに記載されたバージョン・リストは、MikroTik の情報と一致しており、7.x の stable ブランチ/long-term ブランチの双方に修正が提供されていることを示している。
MikroTik ユーザー・コミュニティでは、実環境での悪用を示す証拠が短期間で確認されている。ある管理者が Reddit で報告したのは、2026年9月2日 08:00 UTC 頃に、「0」と名付けられた別の不正アカウントにより、「ops」という未認可のユーザー・アカウントが作成されたことだ。Write/Policy の両権限が付与されたことが判明し、侵入元が IP アドレス 82.192.72.4 からの SSH 接続であることまで追跡されている。
この管理者によると、不正アカウントは主にログインに使用されていたとみられるが、設定に明らかな悪意のスクリプトは確認されなかった。彼らのチームは RouterOS 自体では検出できない可能性がある、より深い侵害が発生している可能性を疑い、デバイスがクリーンな状態であることを保証するために、最終的には Netinstall による再インストールが必要になった。
現時点の RouterOS には、このシナリオを検出するための組み込みの検出機構が搭載されている。アップグレード後の OS は、起動時に設定全体を自動的に検査し、未認可の改ざんを示す兆候が見つかった場合には、デバイスをフラグ付き状態に設定して System Log に Critical エントリーを記録する。さらに、この状態のデバイスでは、管理者が手動で監査を実施するまで、新しい Scheduler エントリー/SOCKS プロキシ/PPTP/L2TP/IPsec/プロキシ/SMB 設定などの有効化をブロックするなど、運用上の制限が適用される。
MikroTik のガイダンスでは、デバイスが Flagged と表示された場合には、すでに侵害されていることを前提として、全設定項目の監査と全パスワードのローテーションを実施し、その後に Flagged State を解除する必要があるとしている。
その一方で、Flagged Status が一度も表示されていないルーターについても、安全と判断すべきではない。MikroTik と独立した研究者がともに推奨しているのは、アップデート後に設定を手動で確認し、認識されていないユーザー/スクリプト/スケジュール・タスクが存在しないかを調査することである。その理由は、一部の侵害アーティファクトが自動検出を発生させない可能性があるためである。
そのため、組織全体へのパッチ展開が完了するまでの重要な補完的防御策として、SSH などの管理インターフェースへのパブリック・インターネットからのアクセスを制限し、鍵ベース認証を強制するとともに、管理者アクセスを信頼できる管理ネットワークに限定する必要がある。また、MikroTik の導入規模が大きいことや、悪用のハードルが低いことが確認されている点も考慮すべきである。
セキュリティ・チームにとって必要なことは、今回の問題を通常のメンテナンス・アップデートではなく、インターネットへ公開された環境に対する緊急性の高いリモート・コード実行 (RCE) につながるシナリオとして扱うことである。
具体的には、7.24.2/7.23.4/6.49.21 以降へアップグレードした後に、全デバイスの設定を監査するとともに、リモート管理アクセスを強化する必要がある。Flagged Status が検出されなかったデバイスについても監査を省略すべきではない。
これまでに解説してきた一連の対応は、次回のメンテナンス・ウィンドウまで待つべきものではなく、直ちに実施すべきものである。
ルーター用 OS である MikroTik RouterOS のコアライブラリに致命的な欠陥が発覚しました。今回の記事では、SSH などの管理サービスを介した認証不要のシェルの奪取/攻撃者によるシステム全体の掌握リスクといった問題の影響が示されています。また、実環境での悪用も確認されています。対応策としては、修正版である 7.24.2 や 7.23.4 以降への緊急アップデート/全設定項目の詳細な監査/管理インターフェースへのアクセス制限設定/全パスワードの変更などが効果的です。安全なネットワーク運用の維持に向けて、速やかな対処が求められます。
You must be logged in to post a comment.