2026年9月30日、リヤド時間の午後4時に、Cisco は Cisco Catalyst SD-WAN Manager の CVE-2026-76504 に関するセキュリティアドバイザリーを公開しました。複数の拠点を持つ企業が、拠点ネットワーク全体を一つの画面から運用するために使うシステムです。深刻度スコアは 10 点中 9.8、悪用にはアカウントもパスワードも不要で、Cisco は 9月中に実際の悪用を把握したとしており、回避策はありません。同日、サウジアラビアの国家サイバーセキュリティ庁（NCA）は深刻度「緊急」の警告 2026-7889 を発出し、各組織にアドバイザリーを確認して更新を適用するよう求めました。

核心の問いは技術ではない：誰がパッチを当てるのか？

二週間前、私たちは別の Cisco アプライアンス、つまり ID とアクセスを管理する機器で悪用された脆弱性について書き、そこで脆弱性管理の基本を取り上げました。今回、最も重要な問いは技術的なものではありません。そもそも自社で拠点ネットワークを運用していないかもしれません。通信事業者や IT 企業がマネージドサービス契約に基づいて代わりに運用している場合があります。その場合、今夜システムをアップグレードするのは誰か、アップグレード前に誰かが侵入していないかを確認するのは誰か、そしてどちらも行われなかったとき契約には何と書かれているのでしょうか。

Cisco が実際に公開した内容

このニュースは数時間前のものなので、以下の事実は報道記事ではなく、Cisco のアドバイザリーと NCA の警告そのものに基づいています。

  • 製品：Cisco Catalyst SD-WAN Manager（旧称 vManage）。アドバイザリーは、構成方法にかかわらず影響を受けると明記しています。
  • 原因：HTTP リクエストにおける URI エンコードの不適切な処理により、細工されたリクエストが特定の API エンドポイントを保護するための認証ルールを回避でき、攻撃者は admin ユーザーの権限で API に到達します。
  • 前提条件：なし。認証されていないリモートの攻撃者で、CVSS 基本スコアは 9.8 です。
  • 状況：実際に悪用されています。Cisco PSIRT は 2026年9月に悪用を把握したとし、この脆弱性は Cisco Technical Assistance Center のサポートケースを解決する過程で見つかったと述べています。
  • 回避策：なし。修正方法は修正済みリリースへのアップグレードです。
  • 国内の警告：2026年9月30日付の NCA 警告 2026-7889。商業と投資、金融と経済、医療から、教育、運輸、製造まで、事実上すべてにあたる 14 の対象分野を挙げています。

アドバイザリーによる修正済みリリースは次のとおりです。

現在のリリーストレイン最初の修正済みリリース
20.9 より前修正済みリリースへ移行
20.920.9.10.1
20.1220.12.8.2
20.1520.15.6.1
20.1820.18.4.1
26.126.1.2.1
26.226.2.1

最初の行に注目してください。20.9 より前のリリースを使っている場合、目の前にあるのは小さな更新ではなく、別のリリーストレインへの移行です。計画が必要で、しかも先送りはできません。

なぜこのシステムなのか

SD-WAN ネットワークは、利用できるあらゆる回線を使って拠点、倉庫、本社を結び、そのすべてを一つの中央システムから管理します。ポリシーが書かれるのはそこです。どの通信をどの回線に流すか、どの拠点がどのシステムにアクセスできるか、各拠点のルーターにどの設定を配信するか。中央での一つの変更がすべての拠点に届きます。それこそが狙いです。

同じ特徴が危険でもあります。管理者権限でこのシステムの API に到達した者が相手にするのは、一台の機器ではなく、ネットワーク全体の構成を管理するコンソールです。拠点の POS、倉庫への回線、本社の外からの会計システムへのアクセスは、すべてこのシステムが制御するネットワーク上を流れているかもしれません。日々の経営からどれほど遠く見えても、重要資産リストの最上位に置くべきものです。

Cisco のクラウドか自社のデータセンターか：それが誰が動くかを決める

アドバイザリーはシステムの運用形態を二つに分けており、その違いは非常に実務的です。

  • Cisco のクラウドの場合：アドバイザリーによると、この脆弱性は構成にかかわらず SD-WAN Manager に影響し、クラウドについては二つのケースが説明されています。Cisco Catalyst SD-WAN Cloud Hosted 環境では、Cisco がすでにアクセス制限による緩和策を適用していますが、緩和策は修正ではないため、上の表の修正済みリリースへのアップグレードは依然として必要であり、誰がそれを実施するのかを確認すべきです。Cisco SD-WAN Cloud (Cisco Managed) では、リリース 20.15.605 で脆弱性が解消され、Cisco はユーザーの操作は不要としており、バージョンはサービス画面の Help 機能で確認できます。アップグレードがベンダー側の責任になるのは、この最後のケースだけです。それでも、書面での確認を取り、それ以前の期間のログのレビューを求めるのはあなたの役目です。
  • オンプレミス（自社拠点またはプロバイダーのデータセンター）の場合：ここでは、契約に定めがない限り、誰もあなたの代わりにシステムをアップグレードしてくれません。アップグレードまでの間、Cisco が示す緩和策は、インターネットなどの安全でないネットワークからのシステムへのアクセスを制限し、SD-WAN の制御コンポーネントをファイアウォールなどのフィルタリング装置の背後で保護することです。

つまり最初の問いは、Cisco を使っているかどうかではありません。ネットワーク管理システムがどこで動いていて、そのアップグレードの責任を誰が負っているかです。答えを知っているのがプロバイダーだけなら、それが最初に埋めるべき穴であり、しかも技術的な穴ではありません。

アップグレードしても、事前に侵入されたかどうかは分からない

Cisco は 9月中に悪用を把握し、月の最終日に修正を公開しました。言い換えれば、適用できる更新が存在する前から、この脆弱性は悪用されていたということです。今夜のアップグレードは扉を閉めます。しかし、誰かがすでにその扉を通り、アカウントや設定変更を残していったかどうかは教えてくれません。

そのため Cisco は、IT チームやプロバイダーがシステム上の二つの特定のログ、serviceproxy-access.log と vmanage-server.log で探すべき指標を公開しました。

  • 不明または許可されていない IP アドレスからの j_security_check へのリクエスト。
  • リクエストパス内の URI エンコードされた文字。たとえば %6a_security_check で、%6a はエンコードされた文字 j です。エクスプロイトはこの方法で認証ルールをすり抜けます。Cisco は %6a はあくまで一例だと強調しています。リクエスト内の任意の一文字のエンコードが使われ得るため、チームは %6a だけでなく、j_security_check のあらゆるエンコードの変種を探すべきです。
  • 特に vmanage-server.log では、不明なアドレスから viptela-reserved- で始まるユーザー名に対して行われた j_security_check へのリクエスト。これらはシステムに組み込まれたサービスアカウントなので、その名前がログに現れること自体は侵害の兆候ではありません。重要なのは送信元が不明であることです。

Cisco はまた、これらの指標が通常の運用中に現れることもあると警告しているため、結論を出す前にネットワークの普段の活動と比較する必要があります。

同じ教訓は今週、米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が 9月27日に既知の悪用された脆弱性（Known Exploited Vulnerabilities）カタログに追加した Citrix NetScaler の二つの重大な脆弱性でも浮かび上がりました。CISA は、脅威アクターがこれらを世界中で積極的に悪用していると述べ、可能であればパッチ適用前に侵害の兆候を確認するよう各組織に促し、侵害を疑う組織は更新を適用する前にフォレンジック証拠を保全すべきだとしました。更新によって何が起きたかの痕跡が消える可能性があるからです。このルールはここにも当てはまります。確認し、ログのコピーを保存し、それからアップグレードする。ただし、確認をアップグレードを何日も遅らせる理由にしてはいけません。

ネットワークがマネージドサービスなら：契約には何と書かれているか

NCA の必須サイバーセキュリティ管理策（Essential Cybersecurity Controls）2024年版は、政府機関とその関連会社、および重要国家インフラを所有、運用またはホストする民間部門の組織に対して拘束力を持ちます。NCA は王国内のその他すべての組織にも活用を強く推奨しています。自社が拘束されない場合でも、これは自社の技術の一部を運用するプロバイダーとの契約に何を盛り込むべきかについて、最も明確な国内の参照基準です。

  • 障害が発生した場合に自社のデータやサービスに影響し得る第三者との契約では、サービスレベル契約を含め、次の点を定めます。秘密保持とサービス終了時のデータの安全な削除、サイバーセキュリティインシデント発生時の連絡手順、そして第三者が自社のサイバーセキュリティ要件とポリシーを適用する義務（管理策 4-1-2）。
  • 特に IT アウトソーシングおよびマネージドサービスのプロバイダーとの契約では：契約前に、緩和策を確認したうえでサイバーセキュリティのリスク評価を行うこと。また、リモートアクセスを使って監視や運用を行うサイバーセキュリティのマネージドサービスセンターは、完全に王国内に置かれなければなりません（管理策 4-1-3）。
  • 脆弱性管理では：脆弱性を深刻度で分類し、その分類に従って修正すること、新たな脆弱性の情報について信頼できる情報源を購読すること、そして更新を適用する前に本番以外の環境で検証すること（管理策 2-10-3）。

脆弱性管理の管理策が言っていないことに注目してください。重大な更新を適用する期限はまったく定めていません。その数字は自社の契約に書き込む必要があります。そうしなければ、プロバイダーはあなたが必要とするときではなく、自分ができるときにパッチを当てることになります。

今日プロバイダーに送るべきメッセージ

これらの質問をするのに技術者である必要はなく、会議を待つ必要もありません。回答は書面で求めてください。

  • 当社のネットワークは Cisco Catalyst SD-WAN Manager で動いていますか？ それはどこで動いていますか。Cisco のクラウド、当社の拠点、それとも御社のデータセンターですか？
  • どのリリースで動いていて、いつ修正済みリリースにアップグレードされますか？ 日付と時刻で教えてください。
  • 管理画面は現在インターネットからアクセスできる状態ですか？ そうであれば、アップグレードまでアクセスを制限しましたか？
  • Cisco が挙げた二つのログを公開された指標に照らして確認し、アップグレード前にコピーを保存しましたか？ 何が見つかりましたか？
  • この警告を最初に知らせてくれたのは誰でしたか。御社でしたか、それとも私たちが読んだニュースでしたか？ 次回私たちに通知するための合意済みの手順は何ですか？

最後の質問が最も重要です。警告をプロバイダーからではなく記事で知ったのであれば、問題はこの一つの脆弱性よりも大きいということです。

Origami の見方

私たちは業務システムを開発しています。ネットワーク機器の販売や運用は行っていません。しかし、複数拠点を持つ顧客のために開発するすべてのシステムは、私たちが設計していないネットワークの上で動いています。拠点の POS はサーバーにデータを送り、倉庫は在庫を更新し、電子インボイスはプラットフォームへ送信されます。そして、ネットワークのパッチを誰が当てるのかという問いへのいつもの答えは「プロバイダーがすべて対応します」です。安心できる答えですが、答えにはなっていません。

サウジアラビアの経営者にとって、私たちはこの脆弱性を、アウトソーシングは作業を移しても責任は移さないということを思い出させるものと捉えています。マネージドサービスは多くの企業にとって正しい選択です。ただし、契約に三つの測定可能な事項が含まれていることが条件です。重大な更新を適用する明確な期限、自社のシステムに影響するすべての警告についての書面通知、そしてインシデントのたびに何を確認し何が見つかったかを示す報告書です。これらの条項は優れたプロバイダーにとって何のコストにもならず、脆弱性よりも先に弱いプロバイダーをあぶり出します。

まとめ

  • 自社拠点またはプロバイダーで Cisco Catalyst SD-WAN Manager を運用しているなら、修正済みリリースへのアップグレードは予定作業ではなく緊急作業であり、20.9 より前のリリースは修正済みトレインへの移行が必要です。
  • アップグレードまでは、アドバイザリーに記載のとおり、インターネットからのシステムへのアクセスを遮断し、制御コンポーネントをファイアウォールの背後に置いてください。
  • 修正が公開される前から悪用が始まっていたため、アップグレード前に両方のログを確認し、コピーを保存してください。
  • ネットワークがマネージドサービスなら、上記の質問を今日送り、次回の更新時に重大な更新の期限と通知手順を契約に加えてください。

出典