9Routerの初期パスワードが『123456』、CVE-2026-63732で乗っ取りの恐れ

Claude CodeやCursor、Clineといった開発ツールを複数のAIサービスに振り分けてつなぐ人気の無料ツール「9Router（ナインルーター）」に、初期パスワードが「123456」のまま誰でもログインでき、そこからサーバーを乗っ取れる欠陥が公表されました。CVE-2026-63732、危険度は10点満点中9.9。この記事でこれまで扱ってきた6件に続く、7件目の重大な欠陥です。

やっかいなのは、この「123456」がプログラムの中に直接書き込まれていた点です。ソースコードを読めば誰でも分かり、利用者が自分でパスワードを設定しない限り、世界中のどの9Routerでも同じ値が通ります。しかも欠陥は単独ではなく、この合言葉を入口に、本来は手元のパソコンからしか触れないはずの機能まで届いてしまう「連鎖」になっています。行き先は、サーバー上で攻撃者の命令が動く状態です。

そしてもう一つ、読者にとって重要な事実があります。公的なデータベースが「修正版」として挙げている0.4.60というバージョンは、実際には公開されていません。当サイトでnpmの配布記録とGitHubのリリース一覧を突き合わせて確認したところ、0.4.59の次に出ているのは0.4.62でした。つまり「0.4.60へ上げる」という指示は、そのままでは実行できません。上げるべきはnpmで入手できる最新版の0.5.40（2026年7月20日公開）で、あわせてダッシュボードのパスワードを自分で設定することが必要です。

なお、この製品ではすでに実際の攻撃も観測されています。ログイン不要でサーバーを乗っ取れる別の欠陥（CVE-2026-59800／危険度9.8）について、攻撃監視組織のShadowserver Foundationが2026年7月4日に悪用を観測したと報告しています。古い版をインターネットに公開したままにしている場合は、記事を読み進める前に更新と公開停止を進めてください。

初期パスワードは「123456」だった：CVE-2026-63732の概要

まず、今回新しく分かった1件の中身を整理します。9Routerには管理用の画面（ダッシュボード）があり、そこに入るためのパスワードを利用者が設定します。問題は、利用者がまだ設定していないとき、プログラムに書かれた「123456」がそのまま正解として通ってしまうことでした。設置したまま何も触っていない状態が、そのまま「誰でも入れる状態」だったわけです。

「ハードコードされた既定パスワード」は、脆弱性の中でも性質が悪い部類に入ります。プログラムを読めば誰でも値が分かる。変更しない限り全台で同じ値が通る。そして利用者は、自分がその状態にあることに気づきにくい。この3つが重なるからです。そこへさらに「連鎖」という言葉が付いており、合言葉ひとつでは届かない場所に、これを起点にして届く構造になっています。中身は次章で分解します。

「123456」を探して回っている相手がいる

「123456」で入れる機械がインターネット上にある、という状況をいちばん喜ぶのは、他人の契約したAIサービスを勝手に使うために鍵を集めている人たち、そして開発者のパソコンやサーバーを踏み台にして社内へ入り込もうとする侵入者です。高度な技術は要りません。世界中のIPアドレスを片端から叩いて、既定値のまま放置された機械を見つけるだけで済むからです。この種の探索は人手ではなく、自動で回るプログラムがやっています。

まず「123456」で管理画面に入り、次に通信の宛先を偽って本来は手元専用の機能を呼び出し、最後にAIツール連携の仕組みへ細工した命令を登録してサーバー上で走らせる。見つけたあとに踏まれるのは、この3段です。開発元の説明ページには、この3段をそのまま実行できる手順が公開されています。攻撃を試すための材料が揃っている、という意味では待ってくれる状況ではありません。

まとめて預けたAPIキーが相手の手に渡ったあと、何が起きるかは立場によって違います。9Routerを使っている個人は、預けていたAIサービスの鍵を持ち去られ、身に覚えのない利用料を請求されます。組織で動かしていた場合は、その1台がそのまま社内ネットワークへの入口になります。9Routerは複数のAIサービスの鍵を1か所にまとめて持つ性質があるため、1台破られたときに失うものが多くなりやすい。開発ツールや中継ソフトを起点に組織へ広がっていく流れは、月間9500万ダウンロードのLiteLLMが配布経路ごと乗っ取られた事例でも起きたことで、OSSのサプライチェーンを点検するという観点からも、こうした中継ツールは優先的に見るべき対象です。

CVE-2026-63732は技術的に何が起きているのか

開発元のアドバイザリ（GHSA-4922-8r65-fq26）は、この1件を3つの独立した欠陥の組み合わせとして説明しています。ここではその3つを順に見て、最後に「なぜ3つ揃うと危険度が跳ね上がるのか」を整理します。

CVE-2026-63732：初期パスワード「123456」から3段でサーバー乗っ取りへ（危険度9.9）

1つめは、既定パスワードそのものです。ログイン処理を担うsrc/app/api/auth/login/route.jsは、データベースにパスワードが保存されていないとき、環境変数INITIAL_PASSWORDか、それも無ければ文字列"123456"を正解として比較します。設置して起動しただけの状態では保存済みのパスワードが無いため、「123456」を送れば本物のログイン用クッキーが発行されます。米国立標準技術研究所（NIST）が整理する分類では、既定の認証情報の使用（CWE-1392）にあたります。

2つめは、「手元からのアクセスかどうか」の判定です。9Routerには、危険な機能を並べた「手元専用リスト」があり、そこに含まれる窓口は9Routerを動かしている本人のパソコンからしか呼べない建前になっています。ところが判定を担うsrc/dashboardGuard.jsのisLocalRequest()は、当時「通信の宛先として送られてきたHostという表示が localhost かどうか」だけを見ていました。この表示は送る側が自由に書けるものなので、遠くからHost: localhost:20128と書いて送るだけで「手元からのアクセス」として通ります（送信元を偽る認証回避、CWE-290）。

3つめは、AIツール連携（MCP）のプラグイン登録です。登録時に指定できる「実行するプログラム名」はnodeやpythonなどの許可リストで絞られているのに、そのプログラムに渡す「引数」側は一切検査されていませんでした。nodeは許可されているので、引数に-eと任意のプログラムを並べれば、そのままchild_process.spawn()で実行されます（命令の実行、CWE-78）。

この3つを順につなぐと、次の3手で終わります。①「123456」でログインしてクッキーを得る → ②Hostの表示を偽って手元専用の登録窓口を呼び、命令を仕込んだプラグインを登録する → ③そのプラグインの通知用窓口（SSE）を叩いて実行させる。正規の利用者が何かをクリックする必要はありません。実行される命令は9Routerを動かしているユーザーの権限で走るため、Dockerで動かしている環境では管理者権限（root）になることがあると開発元は書いています。

さらに見落とせないのが、2つめの「手元専用リスト」が破られるとほかの危険な窓口も同時に開いてしまう点です。開発元は具体的に次の窓口を挙げています。

つまり命令実行だけの話ではなく、AIとのやり取りをまるごと横から覗く配線に切り替えることもできるということです。AI連携の仕組み（MCP）を入口にした乗っ取りは、Kubernetes操作用のMCPサーバーや認証なしでツールを実行できたmcp-pinotでも同じ形が繰り返されています。

数値と説明文が食い違っている箇所（過大評価を避けるための注記）

この1件は、公表資料の間で表現が揃っていません。読むときの注意点として3つ挙げます。第一に、「認証が必要か」の扱いです。NVDの説明文は「遠隔の、認証されていない攻撃者」と書いているのに、危険度の計算式（ベクタ）はPR:L＝「低い権限が必要」になっています。開発元のアドバイザリの表題も「Authenticated（認証済み）Remote Code Execution」です。どちらが正しいというより、既定パスワードでログインする行為が形式上は「認証」に数えられるだけで、そのパスワードが公開値である以上、実務上は認証なしとほぼ同じと読むのが妥当です。

第二に、対象バージョンの範囲です。開発元は「0.4.59」の1点だけを対象として挙げていますが、NVDとVulnCheckは「0.4.60より前のすべて」としています。既定パスワードの処理は古い版から入っていたため後者の書き方が実態に近いものの、開発元の記述だけを見ると「うちは0.4.5xじゃないから関係ない」と誤読しやすい形です。第三に、分類（CWE）です。開発元はCWE-78・CWE-290・CWE-1392の3つを挙げているのに、NVDにはCWE-78しか載っていません。この欠陥の性格を最もよく表しているのは既定パスワードのCWE-1392なので、NVDだけを見ると要点が落ちます。

なお、NVDでのこのCVEの状態は「Deferred」で、危険度9.9も9.4もNVDが独自に付けた値ではなく、CVE番号を割り当てたVulnCheckが付けた値です。米CISAの評価（SSVC）は7月27日時点で「悪用は観測されていない」「自動化されていない」「技術的影響は全面的」となっています。

「修正版 0.4.60」は公開されていない（当サイトで確認）

NVD・VulnCheck・開発元アドバイザリはいずれも「0.4.60で修正」と書いています。ところがその0.4.60を実際に入手することはできません。確認した内容は次の通りです。

• npmの配布記録（registry.npmjs.org/9router）に0.4.60は無く、公開日の記録も残っていません。0.4.59（2026年5月21日）の次に出ているのは0.4.62（5月26日）です
• GitHubのタグ・リリースにもv0.4.60は無く、v0.4.62が次の公開版
• これは今回だけの話ではありません。ほかのアドバイザリが修正版として挙げている0.4.72と0.4.82も、npm・GitHubのどちらにも存在しません
• 逆に、npmとGitHubで食い違っている版もあります。0.4.44と0.5.6はGitHubにタグがあるのにnpmには無く、0.4.45はnpmにあるのにGitHubにタグがありません

つまりこの製品では、アドバイザリが書いている修正版の番号と、実際に入手できる版がしばしば一致しません。「指定された版に上げる」という当たり前の対処が、そのままでは通らないということです。だからこそ最新版へ寄せる方針が現実的になります。

さらに重要なのは、0.4.62へ上げてもこの連鎖は塞がらないことです。連鎖の2つめ（Hostの偽装）と3つめ（プラグイン引数の未検査）については、開発元自身が別のアドバイザリ（GHSA-63p9-g54h-prrp／CVE-2026-62312）で「0.5.2で修正」と書いています。同じ欠陥に対して「0.4.60」と「0.5.2」という2つの修正版が併存している状態で、後者が実際に公開されている版です。

最新版でも「123456」は残っている（更新だけでは終わらない理由）

運用の現場で効いてくるのはここです。最新版0.5.40のログイン処理を読むと、「パスワード未設定なら123456を正解とする」という記述はそのまま残っています。0.4.80で加わったのは、mustChangePasswordという項目を応答に付ける処理だけです。しかもこの項目が付くのは「パスワード未設定」かつ「環境変数も未設定」かつ「手元以外からのアクセス」という条件が揃ったときで、その場合でもログイン自体は成功し、認証用クッキーは先に発行されます。画面側で「パスワードを変えてください」と促す仕組みであって、入口を閉じる仕組みではありません。

一方、2つめの「手元からのアクセスかどうか」の判定は作り直されています。0.5.40の判定処理では、Hostの表示ではなくサーバー側が接続元のIPアドレスを自分で書き込んだ値を基準にし、経由した中継が検出されたら「手元ではない」と判断する形に変わっています。ただしこの場所は一度で直っていません。CVE-2026-49353では「前回の修正が不完全」と指摘され、その後もCVE-2026-55641（修正版0.4.82）、CVE-2026-56675（修正版0.5.2）、そして作り直しで新たに導入されたX-9r-Real-Ipという表示を偽るCVE-2026-56681（修正版0.5.6）と、同じ判定が何度も直されています。

したがって対策は「最新版へ更新する」だけでは足りません。更新したうえで、必ず自分でダッシュボードのパスワードを設定してください。設定していなければ、最新版でも「123456」は通ります。

9Routerとは何か、どれくらい使われているのか

9Routerは、Claude CodeやCursor、Cline、Copilotといった「AIにコードを書かせる開発ツール」と、その裏で動くAIサービス（Claude、GPT、Geminiなど40以上）との間に入る、振り分け役（プロキシ）のソフトです。利用回数の上限に達したら別の無料・格安サービスへ自動で切り替えたり、送るデータを圧縮して消費量を減らしたりして、「AIコーディングを無料・低コストで使い倒す」ことをうたっています。MITライセンスの無料ソフトで、利用者が自分のパソコンやサーバーで動かして使います。

便利さの裏返しとして、9Routerは接続先の各AIサービスのAPIキー（利用のための秘密の鍵）や、OAuthというログイン連携のトークンを、自分の中のデータベースにまとめて保存します。ここが破られれば、複数サービスの鍵が一度に流出します。AIをまとめて扱う中継ソフトが攻撃者の標的になるのは、同種の中継ツールLiteLLMの乗っ取りの脆弱性や、AI基盤vLLMのAPIキー回避の欠陥でも繰り返し見られた構図です。

規模は正直に書きます。GitHubのスターは約2万4000（2026年7月29日時点）で、2026年1月に公開されたばかりのプロジェクトとしては伸びが速い方です。ただしスター数は「気になった人の数」で、稼働台数ではありません。日本語の解説記事はほとんど見当たらず、国内で広く業務利用されている形跡も確認できませんでした。企業の基幹システムのように「日本中が影響を受ける」類の話ではありません。とはいえ、使っている人にとっては、預けた全サービスの鍵がまとめて危険にさらされるという重さは変わりません。個人の開発環境や小さなチームで、AI利用料の節約のために入れている、という使われ方が実態に近いはずです。

これまでに公表されていた6件の脆弱性

ここからは、この記事がこれまで扱ってきた6件です。順番は下げましたが内容は変わりません。CVE番号で検索して来た方はこの章を参照してください。

CVE-2026-59800：ログイン不要でサーバー乗っ取り、実際に攻撃を観測（危険度9.8）

この製品の脆弱性群の中で、すでに現実の攻撃が確認されているのがこの欠陥です。9Routerには、社内ネットワーク接続サービス「Tailscale」を導入するための/api/tunnel/tailscale-installという窓口があります。ところが、この窓口はログインを一切求めないまま、受け取った値をサーバー上の命令として実行してしまう作りでした。攻撃者はここへ細工したWebのリクエストをひとつ送るだけで、認証なしにサーバー上で任意の命令を動かせます（OSコマンドインジェクション、CWE-78）。危険度はCVSS 3.1で9.8、4.0で9.2。対象はv0.4.44より前で、v0.4.44で修正されています。攻撃監視組織のShadowserver Foundationは、2026年7月4日にこの欠陥を突く実際の悪用を観測したと報告しており、インターネットに公開された9Routerが自動的なスキャンの標的になっていることを示しています。

CVE-2026-55500：データベースを丸ごと書き出せ、全ての鍵が流出（危険度9.9）

9Routerには、設定用の/api/settings/databaseという窓口があり、ここからデータベースの書き出し（エクスポート）と取り込み（インポート）ができます。問題は、この窓口を守る仕組みが「トークンを持っているか」だけを確認し、「重要な操作をしてよい相手か」までは確認していなかったことです。その結果、権限の低い利用者でも、APIキー・OAuthトークン・OIDCの秘密情報を平文で含んだデータベース全体を書き出せてしまいます。取り込み側も無防備で、攻撃者が用意した中身でデータベースをまるごと上書きすることも可能です。米国立標準技術研究所（NIST）はこれを、機密情報の不正な露出（CWE-200）として整理しています。対象はv0.4.71以前で、NVDは開発元の対応としてv0.4.80での修正を挙げています。

CVE-2026-46339：ログイン不要でサーバー上の命令を実行（最悪評価10.0）

9Routerには、外部ツールと連携するための/api/cli-tools/や/api/mcp/という窓口があります。ところが、ログインを求める仕組みがあらかじめ決められた8つの窓口しか守っておらず、これらの連携用の窓口は無防備なままでした。攻撃者は、ログインせずに悪意ある「プラグイン（任意のコマンドを仕込んだ拡張）」を登録し、別の窓口を呼び出すだけで、サーバー上で自由に命令を実行できてしまいます。危険度はCVSSの上限に達する10.0。対象はv0.4.30〜v0.4.36で、外部連携（MCP）の機能を追加した際に持ち込まれた欠陥で、v0.4.37で修正されています。ログインも利用者の操作も不要という、最も突かれやすいタイプです。

CVE-2026-49352：ハードコードされた共通の合言葉で認証を突破（危険度9.8・実証コード公開）

9Routerは、ログイン状態を証明するトークンを、秘密の合言葉（JWTシークレット）で署名します。問題は、利用者がこの合言葉を自分で設定していない場合に、プログラムに直接埋め込まれた既定の合言葉「9router-default-secret-change-me」がそのまま使われることでした。この文字列は誰でも知ることができるため、攻撃者はこれを使って正規のログイントークンを自分で偽造し、管理画面やAPIへ自由にアクセスできてしまいます。NISTはこれを、ハードコードされた認証情報の使用（CWE-798）として整理しています。対象はv0.2.21〜v0.4.44で、v0.4.45で修正されました。すでに実証コード（攻撃を再現するサンプル）が公開されており、この合言葉を放置している古い版は、先ほどのデータベース書き出し（55500）と組み合わせて、事実上ログイン不要で全ての鍵を抜かれる恐れがあります。今回のCVE-2026-63732が「既定のパスワード」で、こちらが「既定の署名鍵」です。同じ製品で、既定値を埋め込んだままにするという同種の誤りが2度繰り返されていることになります。

CVE-2026-62312：認証後にHost偽装とプラグイン引数で命令実行（危険度8.8）

送信先を偽る「Hostヘッダー」の詐称で本来はローカル限定のはずの窓口に到達し、そこから未検証のプラグイン引数を通じて命令実行に持ち込む二段構えの手口です。認証済みの利用者が悪用できる欠陥として、危険度8.8、v0.5.2で修正とされています。今回のCVE-2026-63732は、この2段の手前に「既定パスワードでログインできる」という1段を足したもので、その結果として「認証済みの利用者しか使えない」という前提が崩れ、危険度が8.8から9.9へ上がっています。報告者は同じdarealDanhで、開発元アドバイザリも7月3日と7月10日に相前後して公開されました。

CVE-2026-55501：ログイン試行の回数制限を回避（危険度7.3）

ダッシュボードのログイン回数制限が、相手の身元をX-Forwarded-Forという「送信側が自由に書ける表示」から判定していたため、値を毎回変えるだけで制限の枠が新しくなり、5回で止まるはずのロックを無効化して無制限にパスワードを試せるという欠陥です。対象はv0.4.80より前で、v0.4.80で修正されました。単独の危険度は7.3ですが、パスワードを何度でも試せる状態は、既定パスワードの問題と組み合わさると効き方が変わります。

結局どのバージョンまで上げれば全部塞がるのか

答えは1行で書けます。npmで入手できる最新版0.5.40（2026年7月20日公開）まで上げ、そのうえで自分でパスワードを設定してください。理由は、修正版が7件でばらばらな上に、公表された修正版のうち0.4.60・0.4.44・0.5.6はnpmから入手できないためです。「その版に上げる」が実行できないものが混ざっているので、個別に追うより最新版へ寄せる方が確実です。

右端の「npmで実際に入る版」の列は、npmの配布記録とGitHubのタグを突き合わせて当サイトが補ったものです。CVE-2026-59800の修正版は0.4.44と公表されていますが、GitHubにv0.4.44のタグはあるのにnpmには0.4.44が無く、npmから入れる場合は0.4.45が最初の修正済み版になります。逆にCVE-2026-49352の修正版0.4.45は、npmにはあるのにGitHubにタグがありません。公表された番号をそのまま指定してもインストールできない場合があるので、この列を目安にしてください。CVE-2026-63732については、既定パスワードそのものが最新版にも残っているため、版を上げるだけでは足りず、パスワード設定が対策の本体になります。

なお、この記事で扱っている7件は、開発元がGitHubで公開しているアドバイザリ一覧の一部です。同ページには2026年7月29日時点で19件が並んでおり、修正版が0.5.4や0.5.6とされるものも含まれます。最新版へ寄せるべき理由は、この記事の7件だけを見ても足りないからです。

国内の登録状況と、悪用の兆候はどうなっているか

国内の公的機関の扱いを確認しました。脆弱性情報データベースJVN iPediaには、CVE-2026-63732を含めて9Routerの脆弱性は1件も登録されていません（キーワード検索で該当0件）。JPCERT/CCおよびIPAからの注意喚起も出ていません。日本語の報道・技術記事も見つからず、少なくともCVE-2026-63732について日本語でまとまった解説は、本稿が最初になります。

悪用の可能性を示す指標も見ておきます。EPSS（今後30日間に悪用される確率の推定値）は7月28日時点で0.74%、全CVEの中での位置はほぼ中央（51パーセンタイル）です。同じ製品の中で最も高いのはCVE-2026-46339の2.40%、実際に悪用が観測されたCVE-2026-59800は1.34%でした。実悪用が確認されたCVE-2026-59800でも1%台に留まっており、この製品では指標が実態に追いついていないと見るべきです。数値の低さを安心材料にしないでください。米CISAの実際に攻撃された脆弱性リスト（KEV）には、7月27日版（1655件）の時点で9Routerの脆弱性は1件も載っていません。KEVの最新状況は当サイトのダッシュボードで確認できます。

筆者の見解ですが、この製品からは今後もCVEが出ると考えています。根拠は2つあります。1つは、今回の7件目が「後から出てきた」経緯です。開発元のアドバイザリは7月3日に公開されていたのに、CVE番号が割り当てられたのは7月23日で、しかも割り当てたのは開発元でもGitHubでもなくVulnCheckという別の組織でした。GitHub側のアドバイザリには現在もCVE番号が紐づいていません。番号が後から別ルートで付く事案が現に起きている以上、公開済みでも番号が付いていないものはまだあると考える方が自然です。もう1つは、「手元専用かどうか」を判定する同じ場所が0.4.44・0.4.72・0.5.2・0.5.6と繰り返し直され、そのたびに新しい欠陥が出ている点です。ここは事実ではなく見立てとして読んでください。

裏が取れた事実と、未確認のまま残る点

0.5.40へ上げても、パスワードは自分で変える

やることは3つです。1つめ、npmで入手できる最新版（0.5.40）へ更新する。7件の修正版がばらばらで、しかも公表された修正版のうち0.4.60・0.4.44・0.5.6はnpmから入手できないため、個別に追うより最新へ寄せる方が確実です。2つめ、ダッシュボードのパスワードを自分で設定する。これが今回の対策の本体です。未設定のままだと最新版でも「123456」が通ります。3つめ、インターネットへの公開をやめる。トンネル、VPSへの設置、クラウド同期を使っている場合は外してください。9Routerは手元の環境だけで動かす前提のツールで、外に開くほど今回のような穴が突かれます。

加えて、古い版を外部に公開していた期間がある場合は、保存していたAPIキーやトークンの入れ替え（再発行）を済ませてください。すでに抜かれている可能性を否定できないためです。各AIサービスの管理画面でキーを作り直し、古い鍵を無効化しておくと安心です。中継ツールに鍵を預ける構成は便利ですが、預けた先が破られると被害が一度に広がる点は、通信ライブラリで認証情報が漏れる脆弱性やAIコーディングツールClineのAPIキー窃取の脆弱性とも共通します。

よくある質問

まとめ

今回新しく分かったCVE-2026-63732は、AIコーディングを安く使うための人気の中継ツール9Routerに、初期パスワード「123456」がプログラムの中に書き込まれていたという話です。危険度は9.9。この合言葉ひとつを入口に、通信の宛先を偽って手元専用の機能へ届き、AIツール連携のプラグイン登録から命令実行まで、3手でつながります。再現手順も公開されています。

読者にとっての実務的な結論は2つです。1つは、公表された修正版0.4.60は存在しないので、npmの最新版0.5.40へ上げること。もう1つは、最新版でも「123456」の記述は残っているので、更新とは別に自分でパスワードを設定することです。あわせて、インターネットへの公開をやめ、外部公開していた期間があるならAPIキーを作り直してください。この製品では別の欠陥（CVE-2026-59800）で実際の悪用も観測されています。

複数のAIサービスの鍵を1か所に預ける便利さには、預け先が破られたときに被害が集中する危うさが表裏一体でついてまわります。9Routerに限らず、AIの中継役を自分で立てるなら、その1台が「鍵束」であることを前提に置いた方が安全です。新たなCVEの公表や悪用の動きがあれば、この記事に追記します。

更新履歴

参照元

• ▸ NVD - CVE-2026-63732（既定パスワードからの連鎖・今回追加）
• ▸ GitHub Security Advisory - GHSA-4922-8r65-fq26（CVE-2026-63732・再現手順あり）
• ▸ VulnCheck - 9router before 0.4.60 Remote Code Execution via default password
• ▸ 9Router 公開アドバイザリ一覧（GitHub・2026年7月29日時点で19件）
• ▸ npm レジストリの配布記録（0.4.60が存在しないことの確認）
• ▸ 9Router リリース一覧（GitHub）
• ▸ 最新版0.5.40のログイン処理（「123456」の記述が残る）
• ▸ 最新版0.5.40の手元判定処理（Host依存から接続元IP基準へ）
• ▸ GitHub Security Advisory - GHSA-63p9-g54h-prrp（CVE-2026-62312・0.5.2で修正）
• ▸ NVD - CVE-2026-55500
• ▸ GitHub Security Advisory - GHSA-qvfm-67h2-2qfx（CVE-2026-55500）
• ▸ GitHub Security Advisory - GHSA-fhh6-4qxv-rpqj（CVE-2026-46339）
• ▸ NVD - CVE-2026-59800（無認証RCE・Shadowserverが実悪用を観測）
• ▸ NVD - CVE-2026-55501（ログイン回数制限の回避）
• ▸ GitLab Advisory - CVE-2026-49352（既定JWTシークレット）
• ▸ CISA Known Exploited Vulnerabilities Catalog（9Routerは未登録）
• ▸ FIRST EPSS（悪用確率の推定値）
• ▸ JVN iPedia（9Routerの登録は無し）
• ▸ 9Router 公式リポジトリ（GitHub）