MikroTik RouterOSの脆弱性CVE-2026-86060とCVE-2026-67277。SSH経由の権限昇格がKEV入りした理由、更新と露出確認の手順

2026年9月10日、CISAはMikroTik RouterOSの脆弱性2件をKnown Exploited Vulnerabilities Catalog(KEVカタログ)に追加しました。SSHのログイン経路で権限昇格が起きるCVE-2026-86060と、帯域測定機能btestで認証前の接続が通ってしまうCVE-2026-67277です。MikroTikは9月3日に修正版を出し、発見者であるポーランドのCERT Polskaは9月5日に、少なくとも9月2日から実際の攻撃が起きていると公表しています。

RouterOSは、拠点間VPNの終端や小規模ISPの集約ルーター、支店のインターネット出口として、価格の手ごろさから広く使われています。既定の構成ではSSHはインターネット側から遮断されていますが、保守の都合でSSHなどの管理サービスを手動で外部に開けた機器は影響を受けえます。この記事は、そうした機器を預かるネットワーク担当に向けて、MikroTikの公式アドバイザリ、CERT Polskaの2本の公表、CISAのKEVカタログ、NVDのレコードで確認できた内容だけを整理します。攻撃コードや再現手順は扱いません。記述は執筆時点(2026年9月13日)に確認できた範囲に限ります。

KEVカタログに記録された2件の中身#

CISAが配布するKEVカタログのJSONフィードに記録された値を並べます。同じ内容はWeb版のカタログでも確認できます。

執筆時点で確認したKEVカタログのJSONフィード(カタログバージョン2026.09.11)には、上表の値が記録されています。CVE-2026-86060のshortDescriptionは「allows an attacked to change the trusted RouterOS policy mask, leading to privilege escalation」、CVE-2026-67277のshortDescriptionは「allows kernel memory disclosure and denial of service in the btest service」です(原文の綴りのまま引用しています)。requiredActionは両件とも、ベンダーの指示に沿った緩和策の適用と、BOD 26-04およびForensics Triage Requirementsへの準拠を求めています。

2件の扱いには差があります。CVE-2026-86060はforensicTriageがYesで、更新するだけでなく侵害の有無を調べる作業まで想定されています。CVE-2026-67277はNoです。技術的な影響も違い、前者は管理者権限の奪取につながり、後者はメモリの一部漏えいとサービス停止が中心です。ただしBOD 26-04が3日の期限やトリアージを課す対象は米国連邦政府の行政機関の資産で、外部公開の有無などの条件で資産ごとに決まります。日本の民間組織にとっては義務ではなく、優先度を判断する材料として読むのが妥当です。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

MikroTrickという名前が指す範囲#

この件は情報源によって件数が違って見えるため、最初に整理しておきます。

CERT Polskaは「6件のうち2件を組み合わせると、SSHでの遠隔アクセスを受け付ける機器を認証なしで完全に掌握できる」と説明し、その組み合わせにMikroTrickという名前を付けました。一方で、組み合わせる2件がどのCVEかは公表文の中で番号を挙げて明示していません。CISAがKEVに入れた2件と、CERT Polskaが言う組み合わせの2件が一致するかどうかは、執筆時点の公開資料からは確認できませんでした。この記事では推測でつなげず、KEVに載った2件を中心に、残りの4件は対応範囲を決める材料として扱います。

CERT Polskaの公表は、ここ数日インターネットから到達できるRouterOS機器への攻撃を観測しており、攻撃者がこの組み合わせを使ってSSHが公開ネットワークに開いている機器を掌握していることの確認を得た、と述べています。公開済みの修正版が観測された攻撃を防ぐことも確認されたとしています。あわせて、MikroTikが今回初めて、MikroTikアプリを入れた利用者のスマートフォンへプッシュ通知を送ったことにも触れています。

MikroTik自身のアドバイザリは、公表時点で「更新の時間を確保するため詳細は公開しない」としていました。これに対しCERT Polskaは、公開された修正版パッケージを比較する差分解析によって、コミュニティが修正された不具合の一部を再構成できる状態になったため、公表を前倒ししたと説明しています。修正版の公開そのものが、攻撃者にとっての手がかりになる状況です。

CVE-2026-86060: SSHログイン経路の引数処理と権限昇格#

NVDとCERT Polskaに登録された説明は次のとおりです。

RouterOS contains an argument-handling flaw in the SSH login path involving usernames that begin with a prohibited character, allowing for the trusted RouterOS policy mask to be changed, leading to privilege escalation. Exploitation requires an unauthenticated SSH session to reach the RouterOS login helper.

RouterOSでは、ユーザーごとにどの操作を許すかをポリシーの組み合わせで管理しています。公表文によると、SSHのログイン経路で、使用が禁止された文字で始まるユーザー名を渡したときの引数の扱いに欠陥があり、その結果としてRouterOSが信頼するポリシーマスクが変更されます。ユーザー名が内部でどう解釈されてマスクに影響するのかという詳細は、執筆時点で公開されていません。CWE-88(コマンドの引数区切り文字の不適切な無害化)は、入力の一部が別の引数として解釈されてしまう型の弱点を指します。

説明文の最後の一文には注意が要ります。悪用には「認証されていないSSHセッションがRouterOSのログイン補助処理に到達すること」が必要とされています。つまり、SSHのポートに到達できる相手であれば、正規のアカウントを持っていなくても試せる位置にあるということです。CERT Polskaは、結果として得られるセッションがRouterOSの完全な管理者権限を持つと説明しています。KEVの名称は権限昇格ですが、影響の実態はSSHの到達性があれば管理者権限に届く、と読むのが適切です。

CVSSの値は次のとおりです。

CERT PolskaのベクトルはAT:P(攻撃の成立に前提条件がある)を含みますが、どの条件を指すのかは公表文に書かれていません。CVSS v3.1にはAT(Attack Requirements)に相当する指標がなく、NVDのベクトルはすべての項目が最も深刻な側に置かれた9.8です。v3.1とv4.0では算出方法が異なるため、数字の大小を単純に比べることはできません。

CVE-2026-67277: btestの認証前接続#

帯域測定機能(bandwidth-test、btest)は、RouterOS同士やツールとの間でスループットを測るための機能です。NVDとCERT Polskaの説明を要約すると、次の3つの欠陥が重なっています。

• 主セッションの認証が完了する前に、関連(related)接続を受け付けてしまう
• 認証なしで開始できるIPv4のUDPテストで、random-data=falseのとき、カーネルのパケットバッファのうち未初期化の末尾部分が送信される
• パケットサイズの範囲チェックが欠けており、符号なし整数のアンダーフローで異常に大きな断片化出力が生じ、RouterOSのカーネルが再起動しうる

CVSSはCERT PolskaのCVSS v4.0が8.8(AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N)、NVDのCVSS v3.1が8.2(AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H)です。機密性への影響がLow、可用性への影響がHighという評価で、CVE-2026-86060のような管理者権限の奪取とは性質が違います。KEVに載った以上、悪用の事実は記録されていますが、CISAのアラートやKEVのエントリは、どの攻撃でどう使われたかまでは記していません。

あわせて読みたい

CVSSスコアの読み方と脆弱性対応の優先度付け。基本値だけで判断しないために

同時に公表された残り4件と、対応範囲の決め方#

KEVには入っていないものの、同じ修正版で直る脆弱性がほかに4件あります。どの機能を外部に開けているかで、自組織にとっての重さが変わります。

CVE-2026-86060とCVE-2026-67277の影響範囲は、CERT Polskaの一覧でいずれも6.0.0以上6.49.21未満、7.0.0以上7.23.4未満、7.24以上7.24.2未満です。6件のうち3件がSSHにかかわり、WebFigとbtestにもそれぞれ認証なしで届く欠陥があります。CVE-2026-67276のNVDステータスは執筆時点でAwaiting Analysisで、NVD独自のスコアはまだ付いていません。

CERT PolskaのCVE一覧ページは、6件すべてを「CERT.PL own research」として掲載し、発見者をCERT PolskaのSławomir Rozbicki氏としています。修正版は6.49.21(Long-term)、7.23.4(Long-term)、7.24.2(Stable)と記載されています。CVE-2026-67276のNVD上の説明文には、影響は7.x系のみで、7.23.4と7.24.2で修正されたと書かれています。なお、悪用を公表した記事では、研究にOpenAIのGTACプログラムを通じたモデルを使った自動化環境を用いたこと、仮説はすべて実機で確認したことが説明されています。

攻撃の時系列#

確認できた日付を並べます。

攻撃の開始は修正版の公開より前に観測されています。修正版を入れる前の期間に外部からSSHへ到達できた機器は、すでに侵入されている可能性を前提に調べる必要があります。

修正版の選び方#

MikroTikのアドバイザリが挙げる修正版は、7.25beta3、7.24.2、7.23.4、6.49.21の4つです。現在使っているリリースチャネルに合わせて選びます。

beta版は検証用のチャネルです。本番の拠点ルーターでは、Long-termかStableの修正版を選ぶのが無難です。執筆時点より後にさらに新しい版が出ている可能性があるため、作業当日にMikroTikのダウンロードページと変更履歴で最新版を確認してください。

更新前に行う露出の確認と暫定対処#

更新の準備と並行して、どの管理サービスがどこから到達できるかを確認します。拠点ごとに設定が違うことが多いため、機器単位で見ていきます。

暫定対処の設定例を示します。アドレスは文書用の範囲に置き換えてあるため、実環境の管理ネットワークに合わせて読み替えてください。

# SSHとWebFigの接続元を管理ネットワークに限定する
/ip service set ssh address=192.0.2.0/24
/ip service set www address=192.0.2.0/24
/ip service set www-ssl address=192.0.2.0/24

# 使っていなければ帯域測定サーバーを止める
/tool bandwidth-server set enabled=no

MikroTikは、より望ましい形として、WireGuardのような強固なVPNを使ってルーターにアクセスし、管理ポートを一切開けない構成を挙げています。拠点ルーターの保守を外部の業者に任せている場合は、業者側の接続方法も含めて見直す機会になります。

あわせて読みたい

SSHサーバのハードニングと鍵の運用

更新後のFlagged確認と設定の点検#

修正版のRouterOSは、起動時に設定全体を調べて、既知の不正な変更の痕跡があればその設定を無効化し、ログにcriticalの記録を残し、Flagged状態にします。MikroTikのアドバイザリは、ログにFlaggedのcritical記録があればFlagged状態のドキュメントに従うよう求め、Flaggedでなくても更新後に見覚えのないスクリプト、ユーザー、設定を点検するよう求めています。

露出していた期間がある機器では、更新で再起動する前に記録を残しておきます。ログをメモリにだけ保持する設定では、再起動でログが失われるためです。

# 更新前: ログと設定を保存する(ファイルは別の端末へ取り出す)
/log print file=log-before-upgrade
/export file=config-before-upgrade

# 更新後: Flagged状態とcriticalログを確認する
/system/device-mode/print
/log print where topics~"critical"

# 見覚えのないユーザー、鍵、スクリプト、スケジューラを点検する
/user print
/user active print
/user ssh-keys print
/system script print
/system scheduler print

# プロキシとトンネルの追加がないかを点検する
/ip socks print
/ip proxy print
/interface print

/system/device-mode/print の出力に flagged: yes が含まれていれば、Flagged状態です。MikroTikのドキュメントによると、この状態では現在の設定は動き続けますが、帯域測定、トラフィック生成、パケットキャプチャが使えなくなり、スケジューラ、SOCKSプロキシ、PPTP、L2TP、IPsec、プロキシ、SMBの新規作成や有効化もできなくなります。いずれも侵入後の足場に使われやすい機能です。コマンドの書式は7系のパス表記で示しています。6系の機器では、書式の違いをMikroTikのマニュアルで確認してください。

CERT Polskaは、観測された攻撃が残したログの痕跡として次の2種類を挙げています。

login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>

さらに、「ops」という名前の高権限ユーザーの存在も侵害の指標としています。成功した攻撃は少なくとも9月2日から82.192.72.4から来ており、103.102.31.18からは攻撃の試行があったと記されています。これらの痕跡が1つでもあれば、ただちに調査すべき対象です。一方で、痕跡がないことは不正な活動がなかった証明にはなりません。

MikroTikのDevice-modeのドキュメントは、Flagged状態を解除するには /system/device-mode/update flagged=no を実行し、ボタン操作かハードリブートで確定させる必要があると説明しています。そのうえで、Flagged状態になったシステムは侵害されたものとみなし、解除の前にすべての設定を監査し、監査後にすべてのパスワードを変更して最新のRouterOSへ更新するよう求めています。

侵害が疑われるときの手順#

Flagged状態になった、ログに上記の痕跡がある、見覚えのないユーザーやスクリプトがあった、という場合は、CERT Polskaの推奨に沿って次の順で進めます。

あわせて読みたい

インシデント発生時の初動対応。最初の1時間で何をするか

拠点ルーターの運用で見直す点#

今回の件は、SSH、WebFig、btestという管理と保守のための機能が、認証前の段階で攻撃面になった事例です。個別の脆弱性に対処したあとも、次の運用を続けることで同種の問題への備えになります。

• 管理サービスを外部に開けない構成を標準にし、例外は台帳に記録して期限を切る
• 拠点ルーターの版番号とリリースチャネルを台帳で管理し、アドバイザリが出たら該当機器をすぐ引ける状態にしておく
• ログをルーター内のメモリだけに置かず、外部のsyslogサーバーへ転送して再起動や初期化の後でも調査できるようにする
• KEVカタログを定期的に取得し、MikroTikのように台帳で見落としやすいベンダーも照合の対象に含める

あわせて読みたい

境界に置くエッジ機器の脆弱性が侵入口として狙われる理由

修正版の公開から攻撃の観測、KEVへの追加まで、この件は1週間ほどで進みました。CERT Polskaが公表を前倒しした理由は、修正版の差分から不具合が読み解かれ始めたことでした。拠点のルーターは設置したまま長く触られない機器になりがちです。管理ポートを閉じる構成と、版番号をすぐ引ける台帳があれば、次に同じ種類のアドバイザリが出たときの初動が短くなります。