CVE-2026-76504 Cisco SD-WAN｜影響確認と侵害調査

はじめに

2026 年 9 月 30 日、Cisco は Cisco Catalyst SD-WAN Manager（旧 vManage）の API 認証バイパス脆弱性 CVE-2026-76504 を公開しました。CVSS 基本値は 9.8（Critical）で、Cisco PSIRT は 2026 年 9 月に実環境での悪用を把握したとしています。

SD-WAN Manager を運用している場合、対応は「修正版へ更新し、今後の悪用を防ぐこと」と「脆弱なバージョンを運用していた期間に侵害されていないかを調べること」の 2 つに分かれます。更新を済ませても、更新前に受けた侵害の有無は分かりません。本記事では、影響判定から到達経路の制限、ログ・情報の保全、修正版への更新、適用後確認までを、運用担当者が判断できる順序で整理します。

結論として、影響するソフトウェアリリースを使用している SD-WAN Manager は、システム構成にかかわらず影響を受けます。現在のバージョンを Advisory の修正版表と照合し、該当する場合は First Fixed Release 以降への更新を最優先で進めてください。更新とは別に、脆弱なバージョンを運用していた期間を対象に serviceproxy-access.log と vmanage-server.log を確認し、不審な痕跡があれば admin-tech を取得して Cisco TAC へ相談してください。

CVE-2026-76504 の概要と影響範囲

CVE-2026-76504 は、SD-WAN Manager の API におけるセッションベース認証の管理に存在する脆弱性です。HTTP リクエスト内の URI エンコードの扱いに不備があり、特定の API エンドポイントへのアクセスを制限する認証ルールを、細工したリクエストで回避される可能性があります。

Advisory の対象は SD-WAN Manager のみで、影響製品の項に記載された製品のみが影響を受けることが判明していると説明されています。SD-WAN Controller、SD-WAN Validator、WAN Edge、Meraki などへ影響範囲を広げて読む記載はありません。

API の admin 権限と OS の root 権限の違い

Advisory が示す影響は、Manager の API へ admin ユーザーとしてアクセスされることです。

参考: Cisco Security Advisory cisco-sa-sdwan-webauth-xr8beuuU
“bypass authentication and gain access to the API as the admin user”
（認証を回避し、admin ユーザーとして API へアクセスし得る）
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-webauth-xr8beuuU

本 Advisory は、OS の root 権限の取得については記載していません。API の admin 権限と OS の root 権限は別のものとして扱い、「root を奪われる脆弱性」と読み替えないことが重要です。ただし、Cisco の構成ガイドでは admin ユーザーが標準ユーザーグループ netadmin に自動で所属すると説明されており（Cisco Catalyst SD-WAN Systems and Interfaces Configuration Guide – Authentication）、Manager 上の管理操作に対する影響は大きいと考えられます。

同じ Manager の脆弱性として、netadmin 権限を前提に root へ昇格し得る CVE-2026-20245 が公表されています。今回の Advisory は両者の組み合わせに言及していないため連鎖を断定できませんが、影響範囲を見積もる際は CVE-2026-20245 の対応状況もあわせて確認することをおすすめします。CVE-2026-20245 の内容は『Cisco SD-WAN Manager 脆弱性｜CVE-2026-20245 のリスクと暫定対処』で整理しています。

提供形態ごとの扱い

Advisory と Hardening Guide は、提供形態ごとに異なる記載をしています。オンプレミス、Cloud Hosted、Cisco Managed、Cloud Pro を一括りにせず、自環境がどれに当たるかを先に確認してください。

Cisco の実悪用情報と CISA KEV の情報

実悪用に関する情報は、Cisco の公表と CISA のデータで出典が異なります。本記事の執筆時点で確認できた範囲を分けて示します。

Cisco の公表

Cisco PSIRT は 2026 年 9 月に本脆弱性の実環境での悪用を把握し、修正版への更新を強く推奨しています。脆弱性は Cisco TAC のサポートケース対応中に発見されたとしています。

CISA のデータ

CVE Record の CISA ADP コンテナには、KEV への追加日として 2026-09-30 が記録されています。同コンテナの SSVC は Exploitation が active、Automatable が yes、Technical Impact が total です（CVE-2026-76504 の CVE Record）。KEV カタログ原本は執筆時点で確認できていないため、連邦機関向けの対応期限は本記事では記載しません。

過去の SD-WAN 脆弱性との区別

SD-WAN では 2026 年に複数の脆弱性で実悪用が報告されています。peering 認証の脆弱性と CISA ED 26-03 に基づくハントは『Cisco SD-WAN 脆弱性｜CISA ED 26-03 のハント手順と対処』で扱っていますが、今回の CVE-2026-76504 は API の認証処理に関する別の脆弱性です。過去の件の修正版、IoC、調査開始時期は本件に流用せず、本 Advisory の情報で判断してください。

対象バージョンと修正版の確認

オンプレミスの Manager では、現在のバージョンを Advisory の Fixed Software 表と照合し、更新先と更新経路を別の資料で決めます。

系列ごとの First Fixed Release

Advisory Version 1.0 に記載された First Fixed Release は次のとおりです。

表に記載のない系列を運用している場合の扱いは、Advisory に明記されていません。推測で判断せず、Cisco TAC または保守窓口へ確認してください。

なお、CVE Record の影響バージョン一覧には 17.x・18.x 系の古いリリースのみが列挙されています。脆弱性スキャナーや資産管理ツールが CVE Record を参照している場合、現行系列が対象外と表示される可能性があるため、影響判定は Advisory の Fixed Software 表を基準にすることをおすすめします。

自環境のバージョン確認

Cisco のドキュメントでは、Manager のメニューから Maintenance > Software Upgrade を開き、Manager を選択してデバイスの現在のバージョンを確認する流れが示されています（Cisco Catalyst SD-WAN Monitor and Maintain Configuration Guide – Manage Software Upgrade and Repository）。クラスター構成の場合は、すべての Manager ノードを確認対象に含めてください。Cisco Managed の場合は、前述のとおりサービス GUI の Help 機能で確認します。

First Fixed Release と更新先の違い

First Fixed Release は、その系列で修正が含まれる最初のリリースです。自環境の更新先は、First Fixed Release 以降であることに加え、他の制御コンポーネントとの互換性と更新経路を満たすリリースを選ぶ必要があります。Advisory は、次の 2 つの資料を参照するよう案内しています。

Advisory の Software Downloads に関する注記でも、更新対象のメモリー容量や、現在のハードウェア・ソフトウェア構成が新リリースで引き続きサポートされるかを確認するよう案内されています。判断できない場合は、Cisco TAC または保守窓口へ確認してください。

ログによる侵害確認と TAC への相談

修正版への更新は今後の悪用を防ぐ対応で、更新前の侵害有無は別に調べる必要があります。Advisory は、インターネットに公開され、ポートが露出している Manager は侵害のリスクにさらされるとしたうえで、IoC が通常運用でも発生し得るため、平常時のネットワークの状態と照らし合わせて誤検知を避けるよう求めています。

確認する 2 種類のログ

Advisory が監査対象として挙げているログは次の 2 つです。確認期間は、脆弱なバージョンを運用していた期間を基準にします。

Advisory の例では、2 つのログに同じ時刻帯のエントリが記録されています。serviceproxy-access.log で見つかった不審なリクエストについて、同じ時刻帯の vmanage-server.log を突き合わせると、どのユーザーとして処理されたかを確認しやすくなります。

ログの取得方法や必要な権限は、自組織の運用手順と Cisco の案内に従ってください。本記事では、公式資料で確認できない取得コマンドや出力例は掲載しません。

%6a の文字列だけで検索しない

Advisory の IoC 例では、文字 j を URI エンコードした %6a が使われています。ただし Advisory は、これは一例にすぎず、リクエスト内でエンコードされた任意の 1 文字が悪用に使われ得ると明記しています。

%6a の検索で該当がないことは、侵害がないことの根拠になりません。また、security_check などの文字列で検索しても、その文字列内の文字がエンコードされていれば一致しません。未デコードのログに対する文字列検索だけでは、取りこぼしが生じます。

そこで、編集上の分析方法として次の流れをおすすめします。Cisco が Advisory で指定した手順ではない点に留意してください。

• ログ原本は変更せずに保全し、分析は複製したコピーで行います。
• コピー上でリクエスト URI をパーセントデコード・正規化し、j_security_check に対応するアクセスを抽出します。
• 抽出した各エントリについて、元の URI 表記、送信元、時刻を記録し、vmanage-server.log のユーザー情報と照合します。

デコード・正規化を行えない場合、単純な文字列検索で確認できる範囲は限られます。その場合は確認できた範囲とその限界を記録し、admin-tech とあわせて Cisco TAC へ相談してください。

正規操作との照合

抽出したエントリは、次の観点で正規操作と照合します。

• j_security_check は、Manager の REST API でセッションを確立する正規のログイン用パスです（Cisco DevNet – Catalyst SD-WAN Manager API Authentication）。アクセスの有無ではなく、送信元とパスの形式で判断します。
• 同じドキュメントでは、認証に失敗した場合もレスポンス本文にログインページが返ると説明されています。ステータスコード 200 だけで、認証の成否や侵害を判断しないでください。
• viptela-reserved で始まる名前は、構成ガイドで予約済みとされているユーザー名です。ログ上の出現だけでなく、未知・未許可の送信元からの処理と結び付いているかを確認します。
• 送信元 IP アドレスは、管理端末、ジャンプホスト、監視・自動化ツール、保守ベンダーの接続元など、API へアクセスする正規の送信元の一覧と照合します。

未許可の送信元、エンコードされたパス、予約済みユーザーでの処理が同じ時刻帯にそろう場合は、侵害の可能性が高いものとして扱い、次に示す手順で TAC へ相談してください。

痕跡が見つからない場合に判断できない範囲

ログに該当がない場合でも、確認できたのはログが残っている期間だけです。ローテーションや保存容量の制限で脆弱な期間の一部が残っていない場合、その期間の侵害有無は判断できません。Advisory の一般的な推奨事項でも、ログを外部サーバーへ送り、事後調査に十分な期間保持することが挙げられています。

外部の syslog サーバーやファイアウォールに通信記録が残っている場合は、Manager 上のログがない期間の補完に使えます。また Hardening Guide では、監査ログ（Audit Logging）が設定変更、テンプレートの適用・解除、ログイン操作を記録すると説明されています。確認できない期間が残る場合は、その範囲を記録したうえで TAC への相談内容に含めることをおすすめします。

admin-tech の取得と Cisco TAC への相談

Advisory は、侵害の有無の判断に支援が必要な場合、Cisco TAC で Severity 3 のケースを起票し、件名に CVE ID「CVE-2026-76504」を含めるよう案内しています。起票の前には、SD-WAN Manager（vManage）で次のコマンドを実行し、admin-tech ファイルを TAC へ提供できるようにしておくことが推奨されています。

request admin-tech

あわせて、次の情報を整理しておくと、TAC とのやり取りを進めやすくなります。

• 2 種類のログで見つかった不審なエントリと、その時刻・送信元
• 脆弱なバージョンを運用していた期間と、ログが残っていない期間やデコード・正規化できず確認範囲が限られた範囲
• API へアクセスする正規の送信元の一覧と、到達経路の構成
• 監査ログで確認できた、心当たりのない設定変更やテンプレート操作

アクセス制限・更新・適用後確認

ここまでの確認を、影響判定から適用後確認までの作業順序にまとめます。到達経路の制限は更新までの時間を補う緩和策で、脆弱性そのものを解消するものではありません。

ワークアラウンドなしと緩和策の違い

Advisory には、本脆弱性を解消するワークアラウンドはないと記載されています。一方でオンプレミス環境向けの緩和策として、インターネットなど信頼できないネットワークからのアクセスを制限し、インターネットからのアクセスが必要な場合はユーザーガイドに記載されたポートとプロトコルについて既知の信頼できるホストに限定するよう案内しています。

Cisco は、ワークアラウンドや緩和策を修正版が利用可能になるまでの一時的な手段と位置づけています。また、緩和策は環境によって機能や性能に影響し得るため、適用前に自環境での適用可否と影響を評価するよう求めています。

許可する管理元と必要な通信の確認

到達経路の制限は、特定のポートを一律に遮断するのではなく、許可する管理元と必要な通信を確認したうえで設定します。

参考: Cisco Catalyst SD-WAN Hardening Guide
“Configure the perimeter firewall to allow only the minimum necessary traffic.”
（境界ファイアウォールは、必要最小限の通信のみを許可するよう設定する）
https://sec.cloudapps.cisco.com/security/center/resources/Cisco-Catalyst-SD-WAN-HardeningGuide

Hardening Guide の Self-Hosted Deployment の記載をもとに、確認する通信を整理すると次のとおりです。

インターネットに公開していないことだけを理由に、影響なしと判断しないでください。本脆弱性は API へ HTTP リクエストが届けば悪用され得るため、社内ネットワーク、保守用 VPN、拠点側のネットワークなど、Manager へ到達できる経路上の端末が侵害されていれば悪用の起点になり得ます。どの経路から到達できるかを確認し、許可範囲を必要最小限に保つことをおすすめします。

影響判定から適用後確認までの手順

更新は今後の悪用を防ぐための対応で、更新前に受けた侵害の痕跡や変更を取り消すものではありません。ログによる侵害確認は、更新とは別の作業として完了させてください。

まとめ

CVE-2026-76504 は、Cisco Catalyst SD-WAN Manager の API へ未認証で admin としてアクセスされ得る脆弱性で、実環境での悪用が確認されています。対応は、修正版への更新による今後の悪用防止と、脆弱な期間の侵害確認の 2 つに分けて進める必要があります。

• API の admin 権限を得られる脆弱性で、OS の root 権限の取得とは区別して扱います。
• 影響するリリースの Manager は構成にかかわらず影響するため、現在のバージョンを修正版表と照合します。
• 更新先は First Fixed Release 以降から、互換性表と Upgrade Matrix で決めます。
• ワークアラウンドはなく、到達経路の制限は更新までの緩和策という位置づけです。
• ログ確認は %6a に限定せず、未許可の送信元や予約済みユーザーを正規操作と照合します。
• 痕跡がなくても、ログが残っていない期間の侵害有無は判断できません。
• 不審な痕跡があれば admin-tech を取得し、Severity 3 で Cisco TAC へ相談します。

以上、最後までお読みいただきありがとうございました。