N-centralが緊急セキュリティ更新｜Agentを先に更新しProbeとの通信を維持

11月13日追記：HF2適用済みでもLegacy APIの設定確認が必要です。調査会社huntbackは11月12日、追加の攻撃チェーン「4EverAble2Shell」によるマイナー設置を報告しました。調査対象の21台のうち19台はHF2の2026.4.1.26だったとしています。これは以下のXXE修正とは別の追加情報であり、HF2のビルド確認だけで対応完了としないでください。

huntbackの調査報告はLegacy API有効時の攻撃を説明し、無効化の維持と侵害調査を勧めています。確認対象には/tmp/.xvd、/var/tmp/.xvd、xvd.serviceなどがあります。これは調査会社の観測で、すべての環境に共通する痕跡ではありません。検出時はマイナーの削除だけで閉じず、サーバー全体の侵害として記録を保全し、提供元と対応を協議してください。

N-ableのLegacy API公式資料では、再有効化の設定はAdministration > Mail and Network Settings > Network Security > LEGACY APISにあり、再有効化は悪用リスクを生むと警告しています。移行用に有効化していた環境は設定と依存する連携を確認し、無効化してください。公式資料はSOAP EIとEI2・RESTを区別しており、SOAP関連の全APIが同じ設定だとは扱いません。Agentを先に更新する以下のHF2手順も引き続き実施します。

N-ableは2026年11月10日、N-central 2026.4 Hotfix 2（HF2）を重要なセキュリティ更新として公開しました。ビルド番号は2026.4.1.26です。対象環境の運用担当者はサーバーの更新状況を確認し、ホステッド版を含めてAgentとProbeも更新してください。通信を維持するため、今回の公式手順は「Agentを先に、Probeを後に」です。

修正対象には、N-central 2026.4.1未満の複数のXXE脆弱性CVE-2026-125883が含まれます。管理サーバーだけを更新して作業を閉じると、端末側の更新が残ります。一方、Probeだけを先行更新すると、AgentやPatch Management Engine（PME）との版の不整合でオフラインパッチキャッシュなどが利用できなくなるため、修正と運用継続を一体で計画する必要があります。

XXEの修正対象と公式に分かっている範囲

N-ableのCVE-2026-125883公式勧告は、影響範囲をN-central 2026.4.1未満、修正版を2026.4.1としています。初回公表日は11月10日で、CVSS 4.0基本値は9.3です。ベクトルではネットワーク経由、低い攻撃複雑性、権限不要、利用者操作不要と評価されています。管理者が不審なリンクを開くことを前提とする問題ではありません。

分類はXML外部エンティティ参照の不適切な制限に関するCWE-611です。ただし、この短い公式勧告だけで、具体的な入口、被害組織、攻撃期間、すべての攻撃結果まで確定できるわけではありません。CVE-2026-125883自体の悪用状況と、冒頭に追記した別の攻撃チェーンの観測は区別します。以下は公開された影響版と更新情報を根拠にしたHF2の配備手順です。

個別勧告の2026.4.1と、配布物のビルド2026.4.1.26は表記の粒度が異なります。作業記録には製品系列だけでなくビルド番号も残し、2026.4という表示だけで修正済みと判断しないでください。本記事と構造化メタの9.3はCVE-2026-125883の値であり、HF2に含まれる全CVEの共通スコアではありません。

サーバーと端末側で作業の担当が異なる

HF2の公式リリースノートは、オンプレミスのサーバーをできるだけ早く更新するよう求めています。ホステッド版のサーバー更新はN-ableが担当しますが、両形態ともAgentとProbeの更新は利用者側の作業です。委託運用では「ホステッドなので対応不要」という理解になっていないか、保守契約の担当範囲を確認します。

導入形態・部品	今回の作業
オンプレミスのサーバー	利用者側でHF2へ更新
ホステッド版のサーバー	N-ableが更新。利用者は反映状況を確認
両形態のAgent／Probe	利用者側で更新。Agentを先行
PME	HF2に先立ち別途自動配布。手動更新操作は不要

PMEの自動配布とAgent・Probeの更新は同じ処理ではありません。自動配布される部品があることを、端末側全体が自動的に対応済みになるという意味に広げないでください。どのサーバー配下にどのProbeと端末があるか、担当者とともに対応づけることが、取り残しを防ぐ最初の確認になります。

Agentを先に更新する理由

HF2はAgentとProbeの通信方式も変更します。公式の互換性説明では、Probeが2026.4.1.26未満なら、AgentとPMEの版にかかわらず従来どおり通信を継続できます。新しいAgentとPMEも古いProbeと互換性があるため、端末側を先に段階展開できる構成です。

組み合わせ	AgentとProbeの通信
Probeが旧版	従来どおり通信を継続
Probe・Agent・PMEがすべて2026.4.1.26以降	更新後の方式で通信
Probeだけ更新済みでAgentまたはPMEが旧版	必要な更新が完了するまで通信不可

Probeを先に更新してしまうと、古いAgentだけでなく、古いPMEとの組み合わせも問題になります。公式が具体例に挙げる影響はオフラインパッチキャッシュです。これは管理下のすべての機能が全面停止するとの説明ではなく、その通信に依存する機能が利用できなくなるという範囲で理解してください。

本サイトの提案は、Probe単位で配下の端末をまとめ、Agentの更新結果とPMEの配布状態を確認してからProbeへ進むことです。長期オフラインや更新失敗の端末は別に管理し、一部の成功だけでグループ全体を完了扱いにしません。更新の対象選択と実施順を作業票に分けて書くと、並行作業でも順序を保ちやすくなります。

組み込みリモート制御は一時無効

リリースノートは、N-centralの組み込みリモート制御が一時的に無効となり、今後の修正で再度有効になる予定としています。Take Controlは引き続き動作すると説明されています。この二つを同じ機能として扱わず、保守現場で通常どちらを使っているか確認してください。

作業当日に普段の遠隔接続が使えないと分かる事態を避けるため、本サイトは更新前に代替の連絡・保守手段を確認することを提案します。Take Controlを利用できるという説明は、すべての契約や端末で準備なしに使えるという保証ではありません。自社の利用可否を確認したうえで、必要な担当者と作業時間を調整します。

また、HF2はレガシーのモバイルデバイス管理（MDM）を削除します。既存手順や社内台帳にその機能への依存が残っていれば、利用状況の確認が必要です。提供元は認証・権限検査、ファイルやログの検証、サーバー、Webのサインインなどの強化も説明しており、単一ファイルの差し替え程度の変更とは捉えないほうがよい更新です。

古いサーバーは直接更新できるかを先に確認

HF2は2026.4のビルド2026.4.0.27とHF1の2026.4.0.32を置き換えます。HF1を適用したという記録だけでは今回の修正を確認できません。HF2の対応表で直接更新が認められる開始版は次のとおりです。

更新元	HF2への経路
2025.4／2026.1／2026.2／2026.3	対応
2026.3.1 Hotfix 1～4	対応
2026.4の0.27／HF1の0.32	対応
それより古い版	まず対応する版へ更新

旧版向けアップグレード資料には段階更新の説明があります。ただし、同資料の一般的なProbe先行手順を今回のHF2へそのまま当てはめてはいけません。HF2固有の通信互換性とAgent先行という指示を優先し、古い環境で経路が不明なら提供元へ確認します。

更新前は証明書と復旧用データを確認

公式の事前チェックリストは、有効なFQDN、証明書の有効性と残存期間、通信先名と証明書のSubject Alternative Namesの整合を点検するよう案内しています。証明書の期限は21日より先であることが求められます。AgentやProbeは証明書エラーなしにHTTPSでサーバーへ接続できる必要があり、名前解決や証明書の問題を残したまま更新を始めないでください。

プライベートCAを使う場合、端末側の信頼ストアにルートCAが入っているかも確認対象です。更新が止まったときに証明書検証を無効化して通す手順へ置き換えるのではなく、通信先の名前、証明書チェーン、信頼の設定を整えます。更新失敗時はコンソールや通知メールにあるエラーを確認することも公式資料に示されています。

公式バックアップ手順では、更新前にサーバーをバックアップし、完了の通知を確認します。外部へ転送していない場合は安全な場所へ保存します。仮想マシンのスナップショットを使う場合は、メモリー上のDBキャッシュによる不整合を避けるため、停止してから作成するよう説明されています。

このため、スナップショットを撮るという作業自体にも停止時間の調整が必要です。本サイトの提案として、保管先、復旧に使うファイル、復旧担当者、更新失敗時の連絡先を作業前に確認してください。バックアップを開始しただけでは完了ではなく、成功と保存を確認してから次工程へ進みます。

公式の事前チェックリストでは、Report Managerのエクスポート、N-centralのバックアップ、復元の処理中はアップグレードが開始されないと説明されています。保守枠でジョブを重ねず、実行中の処理が完了したことを確認してから更新を始めてください。作業が進まない場合も、直ちに配布物の不具合と決めつけないための確認点になります。

更新後はサーバーの表示と管理機能を照合

公式の更新後チェックリストは、版情報、ネットワーク設定、利用者アカウント、顧客プロファイル、デバイス、サービスの報告、通知設定、レポートの確認を挙げています。一般資料の版表示例をHF2の期待値としてコピーせず、今回はリリースノートの2026.4.1.26と照合してください。

Agent／Probe Overviewレポートも配布結果の確認に使えます。サーバーへログインできることと、全端末の監視・パッチ配布が正常なことは別の確認です。本サイトでは、少なくとも更新前後の版、最終通信、通常の監視報告、利用しているパッチキャッシュ、保守接続の結果を対応づけて記録することを提案します。

これは攻撃を再現する検証ではなく、修正の配備と通常業務の継続を確かめる作業です。不審な操作や情報の持ち出しが疑われる場合、更新完了をもって侵害も解消したとは扱わず、関連記録を保全して提供元や担当部門へ相談してください。本サイトは実機での更新試験や、この脆弱性による被害確認を行っていません。

11月13日の追記を踏まえ、Legacy APIの無効化確認と侵害の兆候の調査を、サーバー・端末側の更新、Agent先行の順序、組み込みリモート制御の一時無効化と併せて保守計画に加えてください。委託先へ確認する場合も「パッチ適用済みか」だけでなく、サーバーのビルドと配下のAgent・Probe・PMEの状態を具体的に尋ねてください。