不完全な修正から生まれたN-able N-centralの認証バイパスCVE-2026-18577

N-able N-centralの認証バイパスCVE-2026-18577が、2026年8月3日にCISAのKnown Exploited Vulnerabilities(KEV)カタログへ追加されました。N-centralはMSP(マネージドサービスプロバイダ)や社内IT部門が多数の端末をまとめて監視し遠隔操作するためのRMM(Remote Monitoring and Management)製品です。この脆弱性が生まれた経緯には、脆弱性対応の実務でたびたび起きる型が含まれています。先に公表されたCVE-2026-18556に対する修正が不完全で、認証回避が残ったまま別のCVEとして採番されました。

この記事は、RMMを運用する情報システム担当とMSP事業者に向けて、N-ableのステータス告知とリリースノート、同社のセキュリティ更新記事、CVEレコードとNVD、CISAのKEVカタログとアラート、HuntressとRapid7の技術ブログにもとづき、事実関係と実務上の対応を整理します。攻撃の再現手順や悪用コードは扱いません。記述は執筆時点(2026年8月6日)で一次情報から確認できた範囲に限ります。

CISAのKEVカタログに追加された事実#

CISAは2026年8月3日、KEVカタログに1件の脆弱性を追加しました。それがCVE-2026-18577です。翌8月4日には3件が追加され、そのうち1件が先行するCVE-2026-18556でした。KEVカタログへの追加は、悪用の証拠が確認されたものに限られるという運用条件のもとで行われます。執筆時点で参照できたカタログ(版2026.08.05、収録1661件)には、次の内容で収録されていました。

CVE-2026-18577の短い説明には、認証を代替経路で回避して認証バイパスとアカウント乗っ取りを許すこと、そしてこの脆弱性はCVE-2026-18556に対する不完全な修正の結果であることが明記されています。要求されている措置は、ベンダーの指示に従って緩和策を適用したうえで、CISAのBOD 26-04とForensics Triage Requirementsに沿うこと、と記載されています。クラウドサービスについてはBOD 26-04の該当するガイダンスに従うこと、緩和策が入手できない場合は当該製品の使用をやめること、資産ごとのインターネット露出を評価してBOD 26-04のパッチ適用ガイドラインを順守することも同じ欄に書かれています。

BOD 26-04は米国連邦民間行政機関を拘束する運用指令であり、日本の組織に法的な義務が生じるわけではありません。ただし優先順位の付け方としては参考になります。CISAのVulnrichmentが2026年8月4日付でCVE-2026-18577に付与したSSVCの評価は、Exploitation(悪用)がactive、Automatable(自動化可能性)がyes、Technical Impact(技術的影響)がtotalでした。悪用が現に起きており、大量自動化が効き、得られる支配力も全面的である、という3拍子がそろった評価です。前月にKEVへ追加されたFortiOSのケース(CVE-2025-68686、KEV追加日2026年7月27日)がAutomatableをno、Technical Impactをpartialとされたのと比べると、緊急度の性格がまったく異なります。

KEVやEPSSを使った優先順位付けの考え方は次の記事で整理しています。

CVE-2026-18577の基本情報#

CVEを採番したCNAはN-ableです。CVEレコードの公開は2026年8月2日、最終更新は2026年8月4日で、KEV追加を受けたCISAのADP情報が加わっています。NVDでの状態はAnalyzedです。CVEレコードの表題は「Incomplete patch leads to administrative account takeover」で、説明文は、CVE-2026-18556に対する不完全な修正が、2026.3.1までのN-centralで認証バイパスとアカウント乗っ取りを許す、と述べています。ただしCVEレコードの構造化データのほうは、影響を受ける版を2026.3以下、影響を受けない版をビルド2026.3.1.7としています。この食い違いについては後述します。

深刻度は情報源によって物差しが異なるため、読み分けが要ります。

2つの数値が近いのは偶然で、評価している中身は違います。NVDが付けたCVSS 3.1では機密性と完全性と可用性のすべてがHighで、管理者権限を奪われた製品がどうなるかをそのまま反映しています。N-ableが付けたCVSS 4.0は、脆弱なシステム自身への影響を機密性Highのみとし、後続システムへの影響(SC/SI/SA)をそれぞれLowとする配分になっています。加えてE:A(Attacked)という悪用状況の指標が付いており、これは実際の攻撃が観測されている状態を意味します。CVSS 4.0はCVSS 3.1のScope(S)を、脆弱なシステムへの影響と後続システムへの影響という2組に分けた体系で、同じ脆弱性でも数値の成り立ちが変わります。

両者に共通するのはAC:H(攻撃条件の複雑さが高い)です。CVSS 3.1の仕様では、この値は攻撃者の制御が及ばない条件がそろわないと攻撃が成功せず、事前の情報収集や環境の準備に測定できる程度の労力を要する状態を指します。N-centralの場合にどの条件が該当するかは、公開情報からは確認できません。CISAのSSVCがAutomatableをyesと判定している以上、実務上は自動化された走査の対象になりうると考えて動くのが安全です。

ベクトルの各項目の意味と、環境条件を織り込んだ読み方は次の記事で解説しています。

先行するCVE-2026-18556についても数値を確認しておきます。CNAのN-ableはCVSS 4.0で8.2 High(CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N)、NVDはCVSS 3.1で7.4 High(CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)を付けています。CVEレコードの表題は「Unauthenticated administrative account takeover」で、影響範囲は2026.1までと記載されています。

不完全な修正が別のCVEになる構造#

この2件の関係を整理すると、脆弱性対応の実務で起きやすい落とし穴が見えてきます。

最初に見つかったCVE-2026-18556は、代替経路を使った認証バイパスでした。CVEレコードの影響範囲は2026.1までと記載されているため、2026.2以降では塞がれていたと読めます。ただしN-able自身がどの版で修正したかを明言した記述は、執筆時点の一次情報からは確認できませんでした。その翌日、N-ableはCVE-2026-18556に対する修正が不完全であったとしてCVE-2026-18577を公表し、2026.3.1で動いていないすべてのインスタンスが影響を受けると案内しました。2件は別のCVEとして採番されており、CVE-2026-18556の影響範囲の記載は執筆時点でも2026.1までのままです。公開情報から確認できるのは「先行する修正が不完全だった」というところまでで、認証がどのように回避されたかという技術的な内訳は公表されていません。

この2件に共通するCWE-288という分類は、なぜ不完全な修正が起きやすいかを一般論として説明してくれます。Authentication Bypass Using an Alternate Path or Channelは、正規の認証を通る経路とは別に、認証を経ずに同じ機能へ到達できる裏口が存在する欠陥を指します。裏口が1つだけとは限らないところに、この分類の厄介さがあります。見つかった1本の経路だけを塞ぐ形の修正では、認証処理そのものを通らずに済む別の入口が残る余地があります。ここまでは分類の一般的な性質であって、N-centralの実装が実際にそうだったと確認できているわけではありません。

実務側から見ると、影響が2つあります。1つは、同じ事案でも後から公表されるCVEで影響範囲が広がることです。CVE-2026-18556の記載だけを見て「自社は2026.2以降だから対象外」と判断していた組織は、CVE-2026-18577では対象に戻ります。もう1つは、パッチ適用の完了報告が安全の証明にならないことです。Huntressは、影響が当初は安全と考えられていたビルドにも及ぶと記載しています。先行するCVEへの対応を済ませた版であっても、認証を回避されうる状態にあったわけです。

同じRMM製品での認証回避としては、OIDCトークンの署名検証が欠けていたSimpleHelpの事例があります。実装の欠陥の中身は違いますが、認証を通らずに管理権限へ到達するという結果は共通しています。

発覚から修正公開までの時系列#

一次情報から確認できた日付を並べます。時刻はCVEレコードのdatePublic(公表日時)に記録されたUTCです。CVEレコードがCVEプログラムへ登録された日時(datePublished)はこれより少し後で、CVE-2026-18556が2026-08-01 19:59 UTC、CVE-2026-18577が2026-08-02 22:06 UTCです。

検知から修正公開までが2日という速さは評価できる一方で、修正を適用する側の速度は追いついていません。Huntressは、米国東部時間8月3日0時45分の時点で、同社が把握するパートナーと顧客の到達可能なクラウドサーバーのうち55.6パーセントが未適用だったと記載しています。同日14時15分の更新では、クラウド版はほぼ適用済みになったものの、到達可能なサーバー全体で約13.6パーセントが未適用のまま残っていたとしています。自社運用のN-centralが手動更新である以上、この差は運用体制の差としてそのまま現れます。

RMMが乗っ取られたあとに起きること#

CVE-2026-18577が重く扱われる理由は、脆弱性そのものの精緻さではなく、乗っ取られる対象がRMMサーバーであることにあります。

N-ableは、攻撃者が管理者権限を得たあとにTake Control機能を使い、N-centralが管理する環境内のシステムへ接続したと記載しています。Take ControlはN-centralに組み込まれたリモート操作機能で、管理対象の端末へ画面共有と操作を行うためのものです。管理者として正規にログインできた者が使う前提で作られているため、認証を回避された時点で、この機能は攻撃者の手の中にある正規のリモート操作手段になります。攻撃者が新しいマルウェアを持ち込む必要はありません。

続けてN-ableは、攻撃者がCloudflareトンネル用のサービスを新規登録し、環境内への永続的な足がかりを作ったと記載しています。Cloudflare Tunnel(cloudflared)は、内部のサーバーを外部へ公開する際に受信ポートを開けずに済ませるための正規のツールで、内側から外向きに接続を張ってCloudflareのネットワーク経由で到達可能にします。Cloudflareの公式ドキュメントによれば、cloudflaredはポート7844へのTCPとUDPの外向き接続を使い、HTTP/2またはQUICでCloudflareのネットワークにつながります。受信を全面的に遮断した構成でも成立するため、インバウンドだけを見る監視では捉えられません。裏を返せば、7844番への外向き接続とcloudflaredの常駐は、エグレスの制御とログで見つけられる余地があります。MITRE ATT&CKの分類でいえば、正規のリモート操作ツールの悪用がT1219(Remote Access Tools)、トンネルによる通信の隠蔽がT1572(Protocol Tunneling)に対応します。

Huntressは、初期アクセスを得た攻撃者が侵害された組織の環境内で複数のホストへ素早く動いたと記載しています。あわせて、攻撃者はドメインコントローラーのような重要なサーバーを標的にするための偵察を行っており、労力を優先順位付けする程度には戦略的だとも述べています。

ここに、この事案のサプライチェーン性が現れます。RMMは、多数の顧客環境へ正規の経路で命令を配れる位置に置かれています。MSPが運用するN-centralが1台侵害されれば、そのインスタンスが管理するすべての端末が同じ攻撃者の射程に入ります。Huntressも、侵害されたN-centralサーバーは管理下のあらゆる端末に対してスクリプトの実行やツールの配布やリモートセッションの開始に使われうると記載しています。CISAらの共同勧告AA22-131Aが、MSPとその顧客の双方に対して、委託関係を通じた侵害の連鎖を前提とした防御を求めているのはこのためです。IPAの「情報セキュリティ10大脅威 2026」でも、サプライチェーンや委託先を狙った攻撃は組織向けの脅威として上位に挙げられています。

信頼している供給元を経由して侵入される構造そのものは次の記事で扱っています。

N-ableのセキュリティ更新記事は、2026年7月31日にAdlumin MDRが顧客環境の異常な活動を検知したこと、攻撃者がTake Control機能を使ってN-centralの管理対象環境内のシステムへ接続したこと、Cloudflareトンネル用のサービスを新規登録して永続化を図ったこと、影響が確認された顧客は限られた数であり同社サポートが直接連絡していること、そしてWindows端末向けにIoCを自動確認するカスタムサービステンプレートを提供するものの結果が正常であっても侵害されていない保証にはならないことを記載しています。

影響を受ける版と修正版#

N-ableのステータス告知とリリースノートが示す内容は次のとおりです。

ここで版の呼び方に注意が要ります。CVEレコードの説明文は影響範囲を「2026.3.1まで」と書いていますが、N-ableのステータス告知とリリースノートは「2026.3.1」をホットフィックス適用後のリリース名として使っており、影響を受けるのは「2026.3.1で動いていないすべてのインスタンス」だとしています。同じ「2026.3.1」という表記が、CVE説明文では影響を受ける側の上限、ベンダー表記では修正済みの版を指しているわけです。CVEレコードの構造化データは影響を受ける版を2026.3以下、影響を受けない版をビルド2026.3.1.7としており、こちらはベンダー表記と整合します。自組織の判定はビルド番号2026.3.1.7を基準に行うのが確実です。

古い版を使い続けている環境では、中間の版を経由する多段の更新が必要になります。Rapid7は、脆弱なN-centralを運用する組織は通常のパッチ適用計画の外で緊急に対処すべきだとしています。適用に時間がかかる場合でも、その間に管理コンソールをインターネットから到達可能なまま放置しない判断が要ります。

今日確認する手順#

自組織が管理するN-central環境に対する構成確認とログ確認に限った手順を整理します。攻撃の再現は行いません。

痕跡の探索に使えるIoCは、N-ableとHuntressの双方が公開しています。N-ableはステータス告知で4件のIPアドレス(173.249.252[.]200、87.249.138[.]34、37.19.210[.]32、68.235.46[.]214)を、ファイアウォールログでのインバウンド接続の確認対象として挙げています。N-ableはその後の追加のセキュリティ更新で37.153.90[.]88と92.118.112[.]181の2件を加えており、Huntressはこの6件のIPを自社の探索と手引きに取り込んだうえで、mousears.synology[.]me、wagoosh.direct.quickconnect[.]to、who-ripped-one.direct.quickconnect[.]toという3件のドメインとあわせてIoC一覧に掲載しています。Windowsのアプリケーションイベントログでは、イベントID 4102がMSP Support経由の接続、8192と8193がTake Controlセッションの開始と終了に対応する記録としてHuntressが示しています。

ただしHuntressは、N-ableが当初悪性として挙げた4件のIPについて、実際にはMullvadまたはNordVPNの出口ノードだったと後から報告しています。87.249.138[.]34はNordVPN、37.19.210[.]32はMullvadに直接ひもづくとされています。商用VPNの出口ノードは無関係な利用者も共有するため、この4件との通信が見つかっただけでは侵害の証拠になりません。ログ照合の結果は、時刻や対象ホストや操作内容といった他の材料と突き合わせて判断します。同社はIoCの遮断についても、攻撃者は基盤を入れ替えるため一時的で部分的な対策にすぎず、安心材料にしてはならないとしています。

IoCの照合は現時点で分かっている手口の裏を取る作業であり、網羅を保証するものではありません。N-able自身も、同社が提供するIoC確認テンプレートの結果が正常であっても、環境が影響を受けていない保証にはならないと明記しています。

侵害を疑ったときに最初の数時間で何をどの順で行うかは、次の記事にまとめています。

N-ableのステータス告知は、N-central 2026.3 Hotfix 1(ビルド2026.3.1.7)を2026年8月2日に公開したこと、2026.3.1でないすべてのインスタンスがCVE-2026-18577の影響を受けること、2025.4と2026.1と2026.2と2026.3から直接アップグレードできること、ホスト版はN-ableの計画に沿って自動更新され自社運用版は手動更新であること、利用者のドキュメントフォルダのsvchost.exeとCloudflaredという名前のサービスを侵害の指標として確認すること、4件のIPアドレスからのインバウンド接続をファイアウォールログで確認すること、そして該当する指標が見つかった場合はN-ableサポートへ直ちに連絡するとともに自組織のセキュリティチームを動かすことを記載しています。

RMMを運用する側の恒久的な備え#

この事案は、RMMという製品分類が持つ構造的なリスクを改めて示しました。管理の効率を上げる仕組みは、そのまま攻撃の効率も上げます。CISAらの共同勧告AA23-025Aは、正規のRMMが攻撃者にとって扱いやすい道具になる理由として、自己完結型の可搬実行ファイルとして入手できるため管理者権限の要件やソフトウェア管理の統制を回避できること、RMMの利用が一般にウイルス対策やマルウェア対策の防御を作動させないこと、独自のマルウェアを用意せずに永続化とC2の手段を確保できることを挙げています。CVE-2026-18577の事案で観測されたTake Controlの悪用は、外部から持ち込んだRMMではなく、その組織が業務で使っているRMMがそのまま使われた形です。

正規ツールが攻撃に転用される経路と、未許可の導入を見分ける方法は次の記事で扱っています。

恒久的な運用として押さえておく項目を整理します。

チェック項目の多くは、全顧客環境へ到達できる権限をどう絞るかという1点に集約されます。権限を絞る設計の考え方は次の記事で扱っています。

まとめ#

CVE-2026-18577は、CVE-2026-18556に対する修正が不完全だったために残った認証バイパスです。認証を経ないリモートの攻撃者がN-centralの管理者アカウントを乗っ取れるため、NVDはCVSS 3.1で8.1 High、N-ableはCVSS 4.0で8.2 Highを付けています。CISAは2026年8月3日にKEVカタログへ追加し、SSVCの評価はExploitationがactive、Automatableがyes、Technical Impactがtotalでした。

対処は2026.3 Hotfix 1(ビルド2026.3.1.7)への更新です。ホスト版はN-ableの計画に沿って自動更新されますが、自社運用のN-centralは管理者が手動で更新します。古い版からは中間の版を経由する必要があるため、経路と所要時間を先に見積もります。

そして、更新だけでは終わりません。管理者権限を得た攻撃者はTake Controlで配下の端末へ到達し、Cloudflareトンネルのサービスを登録して居座ったと報告されています。RMMサーバーの更新と並行して、管理者アカウントの棚卸し、リモート操作セッションの履歴確認、管理対象端末側のログとIoCの突き合わせまで行って、初めて一連の作業が完了します。RMMは、1台の侵害が配下の管理対象すべてへ広がりうる位置に置かれた仕組みです。その前提で守りを組み立て直すことが、この事案から引き出せる要点になります。