自社のネットワークに常時接続している機器やソフトのうち、自社が買ったものではないものが何本あるか。答えられる会社は多くない。
米CISAのKnown Exploited Vulnerabilities（KEV）カタログに、N-able N-centralの脆弱性が2件、相次いで収載された。
- CVE-2026-18577：2026年8月3日収載、是正期限2026年8月6日
- CVE-2026-18556：2026年8月4日収載、是正期限2026年8月7日
いずれも登録名は「Authentication Bypass Using an Alternate Path or Channel」——代替経路による認証バイパスである。認証を回避されるということは、本来ログインできないはずの相手が管理機能に到達できるということだ。
N-central は、運用管理を請け負う事業者や情報システム部門が、多数の端末やサーバを遠隔から監視・操作するための製品である。つまり、守るために導入された道具である。
本稿は、この製品を使っている会社よりもむしろ、「使っているのは自社ではなく委託先」という会社に向けて書いている。
この記事を読むべき人
- 情報システムの運用・保守を外部の事業者に委託している中堅・中小企業
- 委託先が自社の端末に何らかの管理用ソフトを入れているが、名前も機能も把握していない会社
- 「セキュリティは委託先に任せてある」と考えている経営者
- 委託契約の中に、委託先が使うツールの脆弱性対応に関する記載があるか確認したことがない会社
- 情報システム担当者が1人、あるいは兼任で、委託先の管理状況まで見る余力がない会社
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
「1回直したはずが、直っていなかった」
今回の経緯で最も実務的な示唆があるのは、先行して出された修正が不完全だったという点である。
N-able が公開しているステータス情報によれば、同社は2026年8月2日にホットフィックス（2026.3.1.7）を公開し、続いて2026年8月6日に2つ目のホットフィックス（2026.3.1.10）を公開している。2つ目は追加のハードニングを含むものとされ、1つ目を適用済みの環境にも必要とされている。
⚠️ **なぜ2本目が必要になったのかについて、N-able の公開情報は、攻撃側が手法を変化させていくことへの継続的な監視と、追加のハードニングに言及するにとどまる。**具体的な原因や、新たな攻撃経路を発見したという記述はない。
一方、因果関係については、ベンダーではなくCISAが明記している。KEVカタログの CVE-2026-18577 の説明欄には、「This vulnerability is the result of an incomplete patch for CVE-2026-18556.」——この脆弱性は CVE-2026-18556 に対する不完全な修正の結果である——と記載されている。
**つまり、「先行する修正が不完全だった」という事実は、二次報道ではなく公的機関の一次情報で確認できる。**ただし、**N-able 自身の公開情報はこの因果に言及していない。**出典の階層としては、CISAの記載を根拠とするのが正確である。適用の手順と対象範囲は、N-able の公開情報で直接確かめてほしい。
ただし、**原因が何であれ「1本目を適用した後に、2本目が必要になった」という経過そのものは、公開情報で確認できる事実である。**そして、多くの会社の運用がこの可能性を前提にしていない。
一般的な脆弱性対応の運用は、「修正版が出た → 適用した → 完了」で閉じる。**この流れには、適用後にベンダーが追加の修正を出したときに気づく仕組みが含まれていない。**一度「対応済み」と記録した案件を、もう一度見に行く動機がない。
実務的に取り得る対策は、そう複雑ではない。**悪用が確認されている案件については、「適用済み」にした後も一定期間、ベンダーの告知を追う対象として残しておく。**すべての案件でこれをやると負担が大きいので、対象はKEV収載相当のものに絞る。
委託先が持ち込むツールは、誰の資産か
ここからが本題である。
運用管理を外部に委託している場合、委託先は自社の端末に管理用のエージェントソフトを導入し、遠隔から操作できる状態を作る。これは委託業務を遂行するために必要な仕組みであり、それ自体は問題ではない。
問題は、この仕組みが「自社の資産一覧」に載っていないことが多い点にある。
自社で購入した機器やソフトは、資産管理の対象になる。しかし委託先が業務のために導入したツールは、購入者が委託先であるため、自社の台帳から漏れやすい。結果として、自社のネットワークに常時接続し、全端末を遠隔操作できる仕組みが、誰の管理下にあるかが曖昧なまま運用される。
この状態で今回のような脆弱性が出ると、次の問いに誰も答えられない。
- そのツールは自社環境に入っているのか
- 入っているとして、影響を受けるバージョンなのか
- 修正版は適用されたのか、いつ適用されたのか
- 適用されるまでの間、何が起きた可能性があるのか
**「委託先に聞けば分かる」というのは、聞ける体制があるときにだけ成立する。**今回のように是正期限が3日程度しかない案件で、しかも8月上旬という時期に、問い合わせて即答が返る前提を置くのは楽観的である。
集中管理の裏返し
遠隔運用管理の仕組みは、少人数で多数の端末を管理するための道具である。その効率の源泉は、1か所から全体を操作できることにある。
しかし、効率を生む構造は、そのまま被害範囲を決める構造でもある。1か所から全端末を操作できるということは、その1か所を取られたら全端末に到達されるということと同義である。
報道によれば、今回の事案では、攻撃者が製品の遠隔操作機能を悪用して管理下の端末へアクセスし、外部との通信経路を確立して継続的なアクセスを維持しようとした例が確認されたとされる。これも二次報道に基づく情報だが、集中管理の構造上、起こり得る事象として理解しておく必要がある。
この構造は、委託先が複数の顧客を1つの管理基盤で見ている場合、さらに拡大し得る。自社が直接狙われなくても、委託先の管理基盤が侵害されれば、侵害された権限が到達できる範囲の顧客・端末が影響範囲になり得る。
**ただし「顧客全体が必ず影響を受ける」という意味ではない。**到達できる範囲は、テナントの分離、権限の設計、多要素認証、ネットワーク側の制御、契約上の作業範囲によって変わる。**発注側の統制で縮小できる余地がある、というのが正確な理解である。**そして今回の事案について、顧客全体が影響を受けたという一次確認は取れていない。
**これは「委託先を疑え」という話ではない。**集中管理を選んだ以上、そういう構造になっているという事実を、発注側が理解しているかどうかの話である。
委託契約で確認したい6項目
経営者が委託先との契約で確認しておきたい項目を整理する。これらは、いずれも平時に1回確認すれば済む。
**項目1：委託先が自社環境に導入しているソフト・機器の一覧を、書面で受け取っているか。**製品名とバージョンが分かる形で。一覧がなければ、脆弱性情報が出たときに該当判定ができない。
**項目2：それらの脆弱性が公表された場合、委託先から自社へ通知する義務があるか。**通知の有無と、通知のタイミングの定義。
**項目3：修正版の適用は、委託料に含まれるか、別途費用か。**別途費用の場合、緊急時に見積もり承認の手続きが挟まる。その手続きにかかる時間が、そのまま対応の遅れになる。
項目4：委託先の管理基盤が侵害された場合、自社への報告義務と報告期限が定められているか。「自社が影響を受けたと判明した場合」なのか「委託先の基盤で事象が発生した時点」なのかで、知る時期が大きく変わる。
**項目5：委託先が他社と共用の管理基盤を使っているか、自社専用か。**共用の場合、他社の事情で自社が影響を受ける経路が存在する。共用が悪いのではなく、その事実を把握したうえで契約しているかが論点である。
**項目6：契約終了時に、導入されたソフト・アカウントをどう撤去するか。**撤去の手順と確認方法が決まっていないと、契約が終わった後も遠隔操作できる仕組みが残る。これは実務上、最も見落とされる項目である。
自社でRMM製品を運用している場合
自社の情報システム部門が直接この種の製品を運用している場合は、別の観点が加わる。
**インターネットからの到達性を絞れているか。**運用管理の基盤は、社外からもアクセスできると便利である。しかし今回のように認証バイパスが成立する脆弱性が出た場合、**インターネットに面していることが、そのまま攻撃可能性になる。**業務上必要な接続元に限定できるかを確認したい。
**管理基盤自体の監視をしているか。**管理対象の端末は監視していても、監視している側の基盤にログイン監査が入っていないことがある。**認証バイパスは、通常の失敗ログイン監視には引っかからない。**管理者権限での操作履歴を見ているかが分かれ目になる。
**適用の優先順位で、管理基盤を最上位に置いているか。**業務システムのほうが重要に見えるため、運用ツールの更新は後回しにされやすい。しかし被害範囲で見れば、管理基盤のほうが広い。
担当者が1人の会社は、どこまでやるべきか
ここまで挙げた確認項目を全部やる余力がない、という会社のほうが多い。その前提で、優先順位を付ける。
情シスが1名だけ、あるいは他の業務と掛け持ちという会社が、まず取るべき順序を示す。
最優先：委託先が自社環境に入れているソフトの名前を聞く。 これだけは、電話1本で終わる。**製品名が分かれば、脆弱性情報が流れてきたときに「自社に関係あるか」を自分で判定できるようになる。**この1歩の有無が、その後のすべてを分ける。名前を知らない状態では、どれだけ情報を集めても自社と結び付けられない。
次点：侵害時の報告義務を、書面で確認する。 契約書を開いて、委託先側で事象が起きた場合の報告に関する条項を探す。あればその内容を、なければ「ない」という事実を記録する。「ない」と分かっていること自体が、経営判断の材料になる。ある前提で動いて、実はなかった、という状態が最も危うい。
その次：契約終了時の撤去手順。 これは緊急性が低い代わりに、忘れると長期にわたって残る。次の契約更新の議題に載せておけば足りる。
後回しでよいもの：委託先の管理基盤が共用か専用か、適用作業の費用区分。 重要ではあるが、**知ったところで自社が今すぐ取れる行動が少ない。**上の3つが片付いてから着手して問題ない。
**この順序の考え方は単純である。「自社が単独で行動できるようになること」を先に置く。**委託先の内部事情に関する項目は、聞いても自社の打ち手が増えにくいため、後になる。担当者が1人の会社では、打ち手に直結しない情報収集に時間を使う余裕がない。
通報を受けたときに最初にやること
委託先から「当社の管理基盤で事象が発生しました」という連絡が来た場合、発注側が最初にやるべきことは、原因の追及ではない。
**最初にやるのは、影響範囲を確定するための質問である。**具体的には次の4点を、その場で聞く。
1. いつからいつまでの期間が対象か。 期間が分からないと、自社側でログを見返す範囲が決まらない。
2. 自社の環境に対して、実際に操作が行われた形跡があるか。 「可能性がある」と「形跡がある」は別である。どちらなのかを明確にしてもらう。
3. 遠隔操作機能が使われた記録は残っているか。 管理基盤側のログでしか分からないため、こちらから確認する手段がない。
4. 現時点で、自社環境への接続は遮断されているか。 継続中なのか止まっているのかで、こちらの初動が変わる。
**この4点を聞かずに「調査結果を待つ」となると、待っている間に自社側でできることが何も進まない。**逆にこの4点が分かれば、自社のログ確認の範囲、パスワード変更の要否、業務の一時停止の要否を、自社の判断で決められる。
よくある質問
Q. 自社はN-able N-centralを使っていない。関係ないか。 A. 自社が契約していなくても、**運用を委託している事業者が使っている可能性がある。**まず委託先に、自社環境に導入されている管理用ソフトの製品名を確認したい。製品名が分かって初めて、該当するかどうかを判定できる。
Q. 委託先に確認したら「対応済み」と言われた。それで十分か。 A. 何を、いつ、どのバージョンに、どの範囲で適用したかまで確認したい。**今回のように修正が複数回に分かれた案件では、「対応済み」が1回目の修正だけを指している可能性がある。**日付とバージョンを記録として残してもらうのが確実である。
Q. 是正期限が3日しかない案件に、委託先が間に合うと思えない。 A. 間に合わないこと自体より、**間に合わなかった場合に何が起きるかを誰も把握していないほうが問題である。**適用が遅れる間、管理基盤がインターネットから到達可能なままなのか、接続元を絞れるのか。ここを確認するだけでも状況は変わる。
Q. 委託先を替えれば解決するか。 A. 解決しない。**遠隔運用管理の仕組みを使う以上、どの事業者に委託しても同じ構造になる。**論点は事業者の優劣ではなく、その構造を前提とした取り決めが契約にあるかどうかである。
Q. 契約書に脆弱性対応の記載がない。今から追加できるか。 A. 契約更新のタイミングで協議するのが通常の流れになる。**ただし、契約改定を待たずに、運用上の取り決めとして書面で確認を交わすことは可能である。**通知の義務と、導入ソフトの一覧の提供だけでも先に取り付ける価値がある。
Q. 資産一覧に委託先のツールを載せると、管理の手間が増えないか。 A. 増える。**ただし、増える手間は「一覧に1行足す」程度である。**一方で、載せていない場合に発生するのは、脆弱性が出るたびに委託先へ問い合わせて回答を待つ時間である。継続的に見れば、載せておくほうが軽い。
Q. 管理基盤が侵害されたかどうかは、発注側から確認できるのか。 A. 直接の確認は難しい。**だからこそ、報告義務と報告期限を契約で定めておくことが実質的な唯一の手段になる。**技術的に検証できないものを、契約で担保する形になる。
委託先との責任分界を整理したいとき
運用を外部に委託すること自体は、人手の限られた会社にとって合理的な選択である。**問題は、委託した範囲と、自社に残る責任の境目が文書になっていないことにある。**今回のような事案は、その境目が曖昧なまま放置されている会社ほど、状況の把握に時間がかかる。
委託先が持ち込んでいるツールまで含めて資産を洗い出し、外からどこに到達できるかを把握したい場合は委託先のツールまで含めた資産棚卸しで対応している。委託契約の中身と、委託先が負っている責任の範囲が自社のリスクに釣り合っているか。ここを社外の目で確かめたい場合は委託契約の内容を第三者に確認してもらうで受け付けている。
脆弱性情報の判定と対応の優先順位付けを継続的に外部へ持たせたい場合は継続的な脆弱性対応の委託、既に不審な事象が確認されている場合は侵害が疑われる場合の対応支援が該当する。情報システムの運用体制そのものを見直す段階であれば、情報システム運用体制の設計で体制設計から扱っている。
なお、遠隔サポートツールに関する脆弱性はSimpleHelpのOIDC実装に起因するリスクでも別の事例を扱っている。委託先を含めたサプライチェーン全体の考え方はサプライチェーン経由のランサムウェア被害を参照してほしい。本稿は、委託先が持ち込む運用管理ツールの責任分界に絞っている。
参照した情報
- CISA Known Exploited Vulnerabilities Catalog（JSON配信）: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
- CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- N-able Status（N-central 2026.3 Hotfix 1 に関する告知）: https://status.n-able.com/2026/08/02/n-central-2026-3-hotfix-1-mitigation-for-cve-2026-18577/
- N-able ブログ（N-central Security Update）: https://www.n-able.com/blog/n-central-security-update-august-6-2026
CVE-2026-18577（2026年8月3日収載、是正期限2026年8月6日）およびCVE-2026-18556（2026年8月4日収載、是正期限2026年8月7日）の収載日・是正期限・登録名「Authentication Bypass Using an Alternate Path or Channel」・対象製品は、KEVカタログのJSON配信（カタログバージョン2026.08.11）から2件分を抽出して確認したものである。また、CVE-2026-18577 が CVE-2026-18556 に対する不完全な修正の結果である旨も、同カタログの当該エントリの説明欄の記載に基づく。
ホットフィックスのバージョン番号（2026.3.1.7 および 2026.3.1.10）、公開日（2026年8月2日および同8月6日）、および2つ目が1つ目の適用済み環境にも必要である旨は、上記N-ableのステータス情報の記載に基づく。
**CVE-2026-18577 が CVE-2026-18556 に対する不完全な修正の結果である旨は、上記CISAのKEVカタログの当該エントリの説明欄に「This vulnerability is the result of an incomplete patch for CVE-2026-18556.」と記載されている。これは公的機関による一次情報である。**ただし、N-able自身の公開情報はこの因果に言及していない。
**一方、攻撃者が遠隔操作機能を悪用して管理下の端末へアクセスしたとされる事象は、セキュリティ関連メディアによる報道でのみ確認したものであり、本稿では確定的な事実として扱っていない。**適用すべきバージョンと手順は、N-able の公開情報で確かめてほしい。
CVSS値、影響を受ける具体的なバージョン範囲、攻撃の技術的詳細、および悪用の観測範囲については、本稿では扱っていない。委託契約で確認したい6項目、自社運用時の3つの観点、担当が1名の場合の優先順位、通報を受けた際の4つの質問、および「適用済み案件を一定期間追い続ける」という運用の考え方は、いずれもGXOが実務の中で組み立てたものであって、N-ableやCISAが定めた基準ではない。「是正期限」という表現はKEVカタログ上で米国連邦政府機関に向けて指定されたものであって、国内の民間企業が法的に負う期限を意味しない。
