MikroTik RouterOS の MikroTrick - SSH経由で未認証乗っ取りされる CVE-2026-67276/86060 と CISA KEV 追加への対応

はじめに

ラトビアのネットワーク機器メーカーMikroTikは2026年9月3日、ルーター用OSのRouterOSについて「重要なセキュリティ更新」を公開しました。修正版は6.49.21(Long-term)・7.23.4(Long-term)・7.24.2(Stable)・7.25beta3です。MikroTik自身は当初、利用者が更新する時間を確保するために詳細を伏せていました。

2日後の9月5日、脆弱性を発見したポーランドの国家CSIRTであるCERT Polskaが、6件のCVEと解説記事を公開しました。このうち2件を組み合わせると、SSHがインターネットから到達可能なRouterOS機器を、認証なしで完全に乗っ取れます。CERT Polskaはこの攻撃チェーンを「MikroTrick」と名付け、少なくとも9月2日から実際の攻撃に使われていることを確認したと発表しました。

米CISAは9月10日、CVE-2026-86060とCVE-2026-67277をKnown Exploited Vulnerabilities(KEV)カタログに追加しています。本記事では、MikroTikのアドバイザリ、CERT Polskaの2本の記事、NVD、CISA KEVのJSONフィードを一次情報として、脆弱性の中身と実務での対応手順を整理します。

概要(早見表)

MikroTikはアドバイザリで「ほとんどの構成はリスクにさらされていない」「一般家庭の利用者にとって差し迫ったリスクではない」と説明しています。理由として、デフォルト設定ではインターネットからSSHポートがブロックされている点を挙げています。逆に言えば、リモート管理のためにSSHを手動で開けている機器が主な標的です。

6件のCVE一覧

CVSSはCNAであるCERT Polska(cvd@cert.pl)がCVSS 4.0で付けた値です。NVDが独自にCVSS 3.1で評価済みのものは併記しました(2026年9月14日にNVD APIで取得)。

影響バージョンの範囲は、CERT Polskaのアドバイザリでは次のように書かれています。

• 6.x系: 6.0.0以上6.49.21未満(CVE-2026-86060、67277、67279)
• 7.x系: 7.0.0以上7.23.4未満(CVE-2026-67276は7.9以上、CVE-2026-67281は7.20以上から)
• 7.24系: 7.24以上7.24.2未満(6件すべて)

CVE-2026-67276、67278、67281は7.x系のみが対象です。6.x系はMikroTrickのうち認証バイパス側(CVE-2026-67276)の影響を受けません。ただし、CVE-2026-86060、67277、67279の影響は受けます。

MikroTrickの技術的な仕組み

CVE-2026-67276: RSA公開鍵の「指数」を見ていなかった

SSHの公開鍵認証では、クライアントが「この公開鍵で認証したい」と鍵を提示し、その鍵に対応する秘密鍵で作った署名を送ります。サーバーは、提示された公開鍵が登録済みの鍵と一致するかを確かめたうえで、その公開鍵を使って署名を検証します。流れの詳細はSSHの仕組みの解説記事で扱っています。

RSAの公開鍵は、法(modulus)nと公開指数(exponent)eの2つの値でできています。NVDとCERT Polskaの説明によると、RouterOSは提示された鍵と登録済みの鍵を照合するときに、鍵の種類とmodulusだけを比較し、exponentを比較していませんでした。しかも署名の検証には、クライアントが提示した鍵をそのまま使っていました。

RSA署名の検証は、署名値sに対して「sのe乗をnで割った余り」を計算し、それがメッセージのハッシュを所定の形式でパディングした値と一致するかを見る処理です。ここでe=1の鍵を提示すると、計算結果はs自身になります。つまり攻撃者は、パディング済みのハッシュ値をそのまま署名として送るだけで検証を通過できます。秘密鍵は不要です。NVDの説明も「exponentを1にした鍵を提示し、有効な署名を偽造して、秘密鍵なしで対象ユーザーとしてSSHのコマンドチャネルを開ける」としています。RSAと署名の基礎は公開鍵暗号とデジタル署名の入門記事も参照してください。

攻撃の前提は、ユーザー名と、そのユーザーに登録されたRSA公開鍵のmodulusを知っていることです。公開鍵は本来、公開しても安全な情報です。そのため、ほかのサーバーやサービスで同じ鍵を使い回していると、そこから取得される可能性があります(一般論としての推測です。今回の攻撃者がmodulusをどう入手したかは公表されておらず、未確認です)。得られる権限は、なりすました対象アカウントと同じです。

CVE-2026-86060: 細工したユーザー名で管理者権限のセッションになる

もう一方のCVE-2026-86060は、SSHのログイン処理で「禁止されている文字から始まるユーザー名」の扱いに不備があるというものです。NVDの説明では、この引数処理の欠陥によって、RouterOSが信頼しているポリシーマスク(ユーザーの権限セット)を書き換えられ、権限昇格につながります。CERT Polskaは「結果として得られるセッションはRouterOSの完全な管理者権限を持つ」と説明しています。CWE-88(引数インジェクション)に分類されている点から、ユーザー名が内部のログインヘルパーに引数として渡る際に、区切りとして解釈されていたと考えられます。

具体的にどの文字が禁止文字で、どう解釈されたのかは公表されていません(未確認)。後述する侵害痕跡のログに -2 というユーザー名が現れることから、ハイフンで始まるユーザー名が使われたと読み取れますが、これは推測です。

2つを組み合わせると何が起きるか

CERT Polskaの説明では、CVE-2026-67276で対象アカウントとしてSSHにログインし、CVE-2026-86060で完全な管理者権限へ引き上げることで、認証情報を持たない攻撃者が機器を完全に制御できます。なお、NVDはCVE-2026-86060単体についても「悪用には、未認証のSSHセッションがRouterOSのログインヘルパーに到達すればよい」と記載し、CVSS 3.1で9.8(PR:N)と評価しています。そのため、6.x系を含めてCVE-2026-86060単体でどこまで悪用できるのかは、公開情報だけでは判断できません(要確認)。

CVE-2026-67277: bandwidth-testのメモリ漏えい

bandwidth-test(btest)は、RouterOS同士で通信速度を測定するための機能です。公式ドキュメントでは、サーバーのenabledとauthenticateの既定値はどちらもyesです。

CVE-2026-67277では、主セッションの認証が終わる前に「関連(related)」接続を受け付けてしまうため、未認証のクライアントがIPv4のUDPテストを開始できました。random-data=falseを指定すると、カーネルのパケットバッファの未初期化の末尾部分がそのまま送信されます。さらに、パケットサイズの範囲チェックが逆転していて検証されないことから符号なし整数のアンダーフローが起き、異常に大きな断片化パケットを出力したり、RouterOSのカーネルが再起動したりします。CISA KEVではメモリ漏えいとDoSとして登録されています。

残り3件

• CVE-2026-67281(WebFig): /jsproxyで新しく割り当てたセッションに、初期化されていない古いプリンシパルへのポインタが残ります。アロケーターの状態を整えたうえで、暗号化URI内の親ディレクトリ指定でWebFigのファイル名前空間から抜け出し、認証情報を含む設定ストアなどrootが所有するファイルを読めます。
• CVE-2026-67279(SSHサーバー): クライアントが要求した再鍵交換(rekey)のあと、ユーザー認証を一度も試みていないのに接続プロトコルの段階へ進んでしまいます。その結果、未認証でexecリクエストを送り、RouterOSが管理するファイルを作成・上書きできます。
• CVE-2026-67278(X.509検証): 不正な形式のPKCS#1 v1.5署名を受け付けます。信頼ストアにe=3のルートCAが含まれているため、RouterOSが外向きに張るTLS接続を制御・リダイレクトできる攻撃者は、秘密鍵なしで中間CAを偽造し、任意のホスト名の証明書を発行できます。

CERT Polskaは研究手法として、プロトコルを状態機械としてモデル化し、段階を飛ばしたり、繰り返したり、順序を入れ替えたりしたときの挙動を調べるやり方が特に有効だったと述べています。CVE-2026-67277(認証前に関連接続を受け付ける)とCVE-2026-67279(認証なしで接続プロトコルへ進む)は、まさにこの種の欠陥です。

悪用状況

CERT Polskaは次のように説明しています。

• 内部チャネルで得た技術的な指標から実悪用の可能性をつかみ、MikroTrickが公開ネットワークからSSHに到達できる機器の完全な乗っ取りに使われていることを確認した
• 公開された修正版は、観測された攻撃を防げることを確認した
• ops アカウントの作成を含め、これまでに観測された成功した攻撃はIPアドレス82.192.72.4から行われている。別のIPアドレス103.102.31.18もチェーンの悪用の試みに使われた
• 今回の修正版で、MikroTikは初めて、MikroTikアプリを入れた利用者のスマートフォンにプッシュ通知を送った

CISA KEVのJSONフィード(カタログバージョン2026.09.11)を2026年9月14日に確認したところ、CVE-2026-86060のエントリはフォレンジック調査を求めるforensicTriageがYes、CVE-2026-67277はNoでした。いずれもknownRansomwareCampaignUseはUnknownです。

一方、MikroTrickのもう片方であるCVE-2026-67276は、確認した時点のKEVには含まれていませんでした。CISAがKEVの対象をこの2件にした理由は公表されていません(未確認)。KEVに載っていないからといって、CVE-2026-67276を後回しにしてよいわけではありません。

攻撃者が乗っ取った機器を何に使っていたのか(プロキシ化、ボットネットへの組み込み、通信の盗聴など)は、CERT Polskaの記事では明らかにされていません(未確認)。ただし、CERT Polskaが更新後の確認対象として「ユーザー、スクリプト、スケジューラーのタスク、プロキシサーバー、トンネル」を挙げている点は、調査の手がかりになります。

対策と確認手順

以下のコマンドはRouterOS 7系のCLI表記です。6.x系ではスラッシュの代わりに半角スペース区切り(例: /system package update)の表記も使われます。

1. バージョンを確認して更新する

# 現在のバージョンを確認
/system/resource/print
 
# 更新の有無を確認してインストール(自動で再起動する)
/system/package/update/check-for-updates
/system/package/update/install

更新先は、使っているチャネルに応じて次のとおりです。

• Long-term(6.x系): 6.49.21
• Long-term(7.x系): 7.23.4
• Stable: 7.24.2
• Testing: 7.25beta3

MikroTikは「Check for updates」メニューから更新できると案内しています。RouterBOARD機器では、RouterOSの更新とは別にファームウェア(RouterBOOT)の更新もありますが、今回の修正に必須かどうかはアドバイザリに記載がありません(要確認)。

2. 侵害の痕跡を調べる

MikroTikとCERT Polskaの説明によると、修正版のRouterOSは起動時に設定を走査し、既知の不正変更の兆候を見つけると次の処理を行います。

1. 疑わしい設定エントリを無効化する
2. ログにcriticalのメッセージを書き込む
3. device-modeのflaggedをyesにする

更新後は次のコマンドで確認します。

# flagged: yes なら侵害されたとみなす
/system/device-mode/print
 
# CERT Polskaが示したログの痕跡を探す
/log/print where message~"via ssh"
/log/print where message~"ssh:-2@"
 
# 不審なユーザー(特に ops)と登録済みSSH鍵
/user/print
/user/ssh-keys/print
 
# スクリプト、スケジューラー、プロキシ、トンネル
/system/script/print
/system/scheduler/print
/ip/proxy/print
/ip/socks/print
/interface/print

CERT Polskaが公表した、観測された攻撃がログに残した痕跡は次の2種類です(ipとnameには実際の値が入ります)。

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からの接続も確認してください。

注意点が2つあります。

• Flaggedにならなくても安全とは限りません。CERT Polskaは、この検知機構は侵害後に残る痕跡の一部しか見ないため、マーカーがないことは安全の証明にならないと明言しています。MikroTikも、Flaggedでない場合でも未知のスクリプトやユーザー、覚えのない設定がないかを確認するよう求めています。
• ログが消える前に退避してください。ログの保存先設定によっては再起動で失われるため、調査が必要な機器では、更新による再起動の前にログと設定を保全しておくのが安全です。

公式ドキュメントによると、Flagged状態の機器では既存の設定は動き続けます。ただし、bandwidth-test・traffic-generator・snifferは実行できず、スケジューラー、SOCKSプロキシ、PPTP、L2TP、IPsec、プロキシ、SMBについては、エントリの有効化や新規作成ができなくなります。Flaggedの解除は/system/device-mode/update flagged=noを実行し、機器のボタンを押すか電源を物理的に入れ直して確定させます。CERT Polskaは、分析と証拠の保全が終わるまでFlaggedマーカーを解除しないよう求めています。

3. すぐに更新できない場合の暫定策

CERT Polskaは、更新までの間は次の対策をとるよう推奨しています。

• SSH、WWW/WWW-SSL、bandwidth-testサーバーを無効にするか、信頼できる管理用ネットワーク以外からのアクセスを遮断する
• 未修正の機器からTLS接続を開始しない。組み込みのSSHクライアント(/system sshと/system ssh-exec)を使わない。特に信頼できないネットワークを通る通信や、信頼できないホストへの接続では避ける

# 使っていない管理サービスを止める
/ip/service/disable www
/ip/service/disable www-ssl
 
# bandwidth-testサーバーを止める
/tool/bandwidth-server/set enabled=no
 
# SSHを管理用ネットワークからのみに限定する(サービス側の制限)
/ip/service/set ssh address=192.0.2.0/24
 
# ファイアウォールでも管理用アドレスリスト以外からのSSHを落とす
/ip/firewall/address-list/add list=mgmt address=192.0.2.0/24
/ip/firewall/filter/add chain=input protocol=tcp dst-port=22 src-address-list=!mgmt action=drop place-before=0 comment="drop ssh from non-mgmt"

192.0.2.0/24はドキュメント用のアドレスなので、実際の管理用ネットワークに置き換えてください。SSHを別ポートで待ち受けている場合はdst-portも合わせます。公式ドキュメントには、/ip/serviceのaddressは該当しない送信元からのアクセスを拒否するだけで、パケット自体はネットワーク層で破棄しないため、外部からのアクセスを遮断するにはファイアウォールを使うよう書かれています。リモートから操作する場合は、作業中のセッションを自分で締め出さないよう、ルールの順序と送信元アドレスを確認してから追加してください。

MikroTikは根本的な方針として、管理ポートを一切インターネットに開けず、WireGuardなどの強固なVPN経由で管理するよう推奨しています。いずれにしても、CERT Polskaが強調しているとおり、これらは攻撃面を減らす一時的な措置で、修正版への更新の代わりにはなりません。

4. 侵害が疑われる場合

Flaggedマーカー、ログ、設定などから侵害の可能性がある場合、CERT Polskaは次の順で対応するよう求めています。

1. 機器をネットワークから隔離する
2. リセットする前に、ログと設定を保全する(手順はCERT Polskaの記事「MikroTik - securing logs and configuration」で案内されています)
3. 観測した攻撃の情報を、該当するCSIRTの案内に従って報告する
4. 工場出荷状態に戻し、信頼できる検証済みの設定から再構築する
5. 使っていたパスワード、鍵、その他のシークレットをすべて変更する

特に、侵害された可能性のある機器から取った完全な設定バックアップを、そのまま復元しないよう注意喚起されています。バックアップに攻撃者のユーザーやスクリプトが含まれていれば、再構築しても元の状態に戻ってしまうからです。VPNの事前共有鍵やRADIUSの共有シークレットなど、ルーターに保存していた認証情報も変更の対象になります。

この件から読み取れること

ネットワーク機器の管理面は依然として最大の攻撃面: 今年もSonicWall SMA1000のCVE-2026-83548/83549など、境界に置かれた機器の脆弱性が悪用されています。ルーターは一度乗っ取られると通信の盗聴や踏み台に使われやすく、エンドポイントのEDRのような監視も効きません。管理インターフェースをインターネットに出さないことが、未知の脆弱性に対しても最も効く対策です。

暗号の実装は「比較の漏れ」で崩れる: CVE-2026-67276は、暗号アルゴリズムそのものではなく、鍵を照合する処理が値の一部しか見ていなかったことが原因です。CVE-2026-67278のe=3のルートCAと不正な形式の署名の組み合わせも、署名の形式検証の甘さに起因します。自前で署名検証を書く場合は、鍵や署名のすべての構成要素を厳密に検証する必要があります。

LLMを使った脆弱性探索が現実の成果を出している: CERT Polskaは、今回の脆弱性をSławomir Rozbicki氏がOpenAIのGTAC(Government and Trust Agency Collaboration)プログラムで利用できるGPT-5.5-cyberとGPT-5.6-solを使って発見したと明かしています。隔離したラボで、エージェントが仮想マシンの作成と復元、バージョン間の比較、RFCとバイナリの解析、脆弱性を確認するスクリプトの作成を自動化し、研究者が対象領域を選んで監督する体制だったとのことです。モデルの位置づけはOpenAI GPT-5.6の解説記事を参照してください。防御側がこうした手法で脆弱性を見つけられるなら、攻撃側も同じように使えると考えるべきで、パッチ公開から悪用までの猶予はさらに短くなっていくと予想されます(推測)。

まとめ

• CERT PolskaがMikroTik RouterOSの脆弱性6件を発見し、MikroTikは2026年9月3日に6.49.21・7.23.4・7.24.2・7.25beta3で修正しました。
• SSH公開鍵認証でRSAのexponentを比較しないCVE-2026-67276と、細工したユーザー名で管理者権限を得るCVE-2026-86060を組み合わせた「MikroTrick」で、SSHに到達できる機器を未認証で乗っ取れます。
• 成功した攻撃は少なくとも9月2日から観測されており、CISAは9月10日にCVE-2026-86060とCVE-2026-67277をKEVに追加しました。
• 更新後は/system/device-mode/printのflagged、ログのssh:-2@、ops ユーザー、スクリプト・スケジューラー・プロキシ・トンネルを確認します。Flaggedでないことは安全の証明になりません。
• 侵害が疑われる場合は、隔離と保全を行ってから工場出荷状態に戻し、検証済みの設定で再構築し、すべてのシークレットを変更します。
• 攻撃者がmodulusをどう入手したか、禁止文字の具体的な内容、乗っ取り後の利用目的は未確認です。

参考リンク

• September 2026 vulnerability(MikroTik公式アドバイザリ)
• Critical vulnerabilities in MikroTik RouterOS are being actively exploited. Immediate update recommended(CERT Polska)
• Vulnerabilities in Mikrotik RouterOS software(CERT Polska CVDアドバイザリ)
• CVE-2026-67276(NVD)
• CVE-2026-86060(NVD)
• CVE-2026-67277(NVD)
• CISA Adds Two Known Exploited Vulnerabilities to Catalog(CISA、2026年9月10日)
• Known Exploited Vulnerabilities Catalog(CISA)
• BOD 26-04: Prioritizing Security Updates Based on Risk(CISA)
• Device-mode(MikroTik公式ドキュメント)
• Services(MikroTik公式ドキュメント)
• Bandwidth Test(MikroTik公式ドキュメント)
• Hackers exploit RouterOS flaws to hijack MikroTik devices without authentication(Help Net Security)
• Hackers exploit new MikroTik RouterOS flaws to hijack routers(BleepingComputer)
• SSH の仕組み - 鍵交換・ホスト鍵検証・公開鍵認証を一次ソースで理解する
• 公開鍵暗号とデジタル署名 入門 - なぜ鍵を公開しても安全なのか
• SonicWall SMA1000 の CVE-2026-83548 / CVE-2026-83549 - CVSS 10.0 のSSRFと連鎖RCE
• OpenAI GPT-5.6 とは - Sol / Terra / Luna と音声モデル GPT-Live の位置づけ