Cisco SD-WANの脆弱性CVE-2026-76504｜悪用確認、認証回避の対象と修正版・侵害の確認

CVE-2026-76504を悪用されると、認証されていない遠隔の攻撃者が、Cisco Catalyst SD-WAN Managerの管理用のAPIに管理者（admin）の権限で入れるおそれがあります。HTTPの要求に含まれるURLの符号化の扱いに誤りがあり、特定のAPIの入口を守る認証の決まりをすり抜けられることが原因です。Ciscoは2026年9月30日に公表し、CVSS 3.1の基本値を9.8としています。[1]

CVE-2026-20127は、Controller（旧vSmart）・Manager（旧vManage）・Validator（旧vBond）の間の相互認証（ピアリング）がうまく働かない脆弱性です。悪用されると、認証なしで内部の高い権限のアカウントでログインされ、NETCONFを通じてSD-WAN全体のネットワーク設定を書き換えられるおそれがあります。Ciscoは2026年2月26日に公表し、CVSS 3.1の基本値を10.0としています。[2]

CVE-2026-76504は、Cisco Catalyst SD-WAN Managerが対象で、設定に関係なく当てはまります。Ciscoが管理するクラウド（Cisco SD-WAN Cloud、Cisco Managed）は、Ciscoが20.15.605で直しており、利用者の作業は要りません。[1]

CVE-2026-20127は、Controller・Manager・Validatorが対象で、設定に関係なく当てはまります。自社で設置したもの（On-Prem）のほか、Ciscoが提供するクラウド（Cisco Hosted SD-WAN Cloud、Cisco Managed、FedRAMP環境）も対象の構成に挙げられています。[2]

製品名は20.12.1から変わっています。vManageはSD-WAN Manager、vSmartはSD-WAN Controller、vBondはSD-WAN Validatorです。[2]

Cisco PSIRTは、2026年9月にCVE-2026-76504が実際に悪用されていることを把握しました。この脆弱性は、Ciscoのサポート窓口（TAC）への問い合わせを調べる中で見つかったものです。[1]

米CISAは、CVE-2026-76504を2026年9月30日（米国の日付）にKEVへ追加し、侵害の調査（Forensic Triage）の対象としています。CVE-2026-20127は2026年2月25日（米国の日付）にKEVへ追加されています。[3]

CVE-2026-20127について、Ciscoは限られた範囲での悪用を把握しています。この脆弱性はオーストラリア信号局のサイバーセキュリティセンター（ACSC）が報告したものです。[2]

Ciscoは2026年10月28日（米国時間）、CVE-2026-20127を悪用した攻撃者（UAT-11473）の侵入後の活動の分析をCisco Talosのブログで公表し、告知（改訂2.1）に追記しました。攻撃者は認証の回避の後、Controllerのプロセス（vdaemon）に入り込む仕組みを置き、裏口と鍵の情報の収集に使っていました。[6][2]

JPCERT/CCとIPAの注意喚起の一覧には、2026年11月2日の時点でこの2件はありません。

Ciscoは、インターネットに面し、ポートが外から届くSD-WAN ManagerとControllerが侵害の危険にさらされているとしています。[1][2]

まず、自社のSD-WANの管理サーバー（Manager・Controller・Validator）がどこにあるか（自社設置か、Ciscoのクラウドか）と、どの名前・IPアドレス・ポートで外から届くかを一覧にします。保守を委託している構成も含めます。

修正版に上げる前に悪用されていないかを、Ciscoが示すログの点で確かめます。次の記録は通常の運用でも出ることがあるため、普段の状態と比べて判断します。[1][2][4]

1. 【CVE-2026-76504】/var/log/nms/containers/service-proxy/serviceproxy-access.log に、心当たりのないIPアドレスからの j_security_check への要求（例：POST /%6a_security_check）が無いか。%6a（j）は一例で、どの1文字を符号化しても悪用できます
2. 【CVE-2026-76504】/var/log/nms/vmanage-server.log に、心当たりのないIPアドレスからの j_security_check で、ユーザー名が viptela-reserved- で始まる記録が無いか
3. 【CVE-2026-20127】/var/log/auth.log の Accepted publickey for vmanage-admin の接続元が、管理画面の WebUI > Devices > System IP にある自社の機器のIPアドレスと一致するか
4. 【CVE-2026-20127】制御接続のピアリングの記録（特に peer-type が vmanage のもの）について、時刻が保守作業や設定変更の予定と合うか、public-ip が自社や取引先の機器か、peer-system-ip が構成どおりか、同じ送信元から繰り返されていないか

CVE-2026-20127については、米CISAが侵害の調べ方を示しています。悪用は2023年に始まった可能性が高いとして、調べる期間をそれに合わせるよう求めています。[5]

5. 【CVE-2026-20127】/var/volatile/log/vdebug・/var/log/tmplog/vdebug・/var/volatile/log/sw_script_synccdb.log に、予定に無い古い版への巻き戻しや再起動の記録が無いか[5]
6. 【CVE-2026-20127】/home/vmanage-admin/.ssh/authorized_keys に、管理者が登録していない鍵が無いか[5]
7. 【CVE-2026-20127】Cisco Talosが挙げるファイル（/tmp/system-vdaemon、/var/tmp/vdaemon.bin、/var/tmp/vdaemon.conf、/etc/sv/sshd/・/etc/sv/aaamgr/ の下の見慣れないもの、libdssl.so・rsshd・conf_sshd・aaamgrd）が無いか[6]

米CISAは、root権限のアカウントが侵害されていたときは、修正済みのイメージ（OVA・qcow2）からManager・Controller・Validatorを作り直し、拠点の機器を新しい構成へ移すよう求めています。[5]

判断に迷うときは、各管理サーバーで request admin-tech を実行して資料を集め、CiscoのTACに相談します。CVE-2026-76504で相談するときは、Severity 3で、件名にCVE番号を入れます。Ciscoは、TACの調査の結果を待たずに修正版へ上げるよう求めています。[1][2][4]

CVE-2026-76504の修正版は、20.9が20.9.10.1、20.12が20.12.8.2、20.15が20.15.6.1、20.18が20.18.4.1、26.1が26.1.2.1、26.2が26.2.1です。20.9より前は、修正版のある系列へ移ります。[1]

表の版は、それぞれの脆弱性が初めて直った版です。同じ系列では、CVE-2026-76504の修正版のほうが新しい版です。[1][2]

CVE-2026-76504のCVEの記録（採番：Cisco）は、修正版と同じ番号でも、名前に_LI_Imagesが付く版や末尾に.01が付く版（例：20.18.4.1.01、26.2.1_LI_Images）を影響ありに挙げています。これらの版を使っている場合は、Ciscoに確かめます。[8]

自社で設置したManagerは、各Managerでshow softwareを実行すると、入っている版の一覧（VERSION・ACTIVEなどの列）が出ます。クラスタで使っている場合は、すべてのManagerで確かめます。[7]Ciscoが管理するクラウドでは、管理画面のHelpで対応の状況と版を確かめられます。[1]

1. 上げる前に、すべてのManager（クラスタのすべての機器、予備の拠点のものを含む）でrequest admin-techを実行し、資料を残します。[4]
2. 上げる先は、今の系列の中の修正版（06の表）にします。Ciscoの対処の手引きは、今のメジャーリリースの中で上げるよう求めています。[4]
3. Ciscoの互換性の表（Catalyst SD-WAN Control Component Compatibility Matrix）で管理サーバー同士の組み合わせを確かめ、Cisco Catalyst SD-WAN Upgrade Matrixで上げる順番を決めます。[1]
4. 上げた後に、もう一度show softwareで版を確かめます。[7]

保守の会社に頼むときは、CVE-2026-76504とCVE-2026-20127の番号、いまの版、上げる先の版（06の表）、Manager・Controller・Validatorのどれが何台あるかを伝えます。あわせて、05の確認点でログを調べてもらい、上げる前のadmin-techの資料を残してもらいます。

Ciscoは、どちらの脆弱性にも回避策は無いとしています。直す方法は修正版に上げることだけです。[1][2]

CVE-2026-76504では、修正版に上げるまでの一時的で部分的な守りとして、Live Protect shieldを出しています。これを入れると、URLの符号化を使う正規の利用者がSD-WAN Managerにログインできなくなることがあります。[1]

緩和策として、自社設置の構成では、インターネットなど安全でないネットワークからの接続を止め、外から使う必要があれば、決まった信頼できる送信元だけに絞ってファイアウォールの内側に置きます。CVE-2026-20127では、ポート22と830への通信を、決まった管理サーバーのIPアドレスなどに限るよう求めています。Ciscoのクラウドでは、これらの緩和策はCiscoが入れています。[1][2]

CVE-2026-20127の表では、20.9より前、20.11、20.13、20.14、20.16はソフトウェアの保守が終わった系列です。Ciscoは、サポートされている系列へ上げるよう強く勧めています。[2]

CVE-2026-76504の表には、20.11・20.13・20.14・20.16の行がありません。これらを使っている場合は、表にある系列の修正版へ移ります。[1]