CVE-2026-20182：vHub認証バイパスによる無認証Cisco SD-WAN制御プレーン侵害

エグゼクティブサマリー

CVE-2026-20182は、Cisco Catalyst SD-WANコントローラに影響する重大な認証バイパス脆弱性です。この脆弱性はvdaemonサービス内に存在し、vbond_proc_challenge_ack()内の検証ロジックの不足が原因です。vHub（device_type = 2）として識別されるピアは、認証の前に証明書検証と信頼検証をバイパスされたまま認証済みとしてマークされます。CHALLENGE_ACKメッセージは意図的に認証完了前に処理されるため、脆弱なコードパスは有効な認証情報または信頼された証明書なしで遠隔から到達可能です。

リモート攻撃者は、任意の証明書を使用してDTLSセッションを確立し、vHubデバイスであることを主張する細工されたCHALLENGE_ACKメッセージを送信することで、この欠陥を悪用できます。これによってコントローラは誤ってpeer→authenticated = trueを設定し、無認証のシステムが暗号検証またはデバイスID検証なしで信頼されたSD-WAN基盤コンポーネントとして受け入れられるようになります。

Cisco Catalyst SD-WANを理解する

Cisco Catalyst SD-WANはCiscoのソフトウェア定義ワイドエリアネットワーク(SD-WAN)プラットフォームで、組織がブランチオフィス、データセンター、クラウド環境、リモートユーザー間の接続を一元管理できるようにします。

手動ルーター設定と高額なMPLSサーキットに大きく依存する従来のWANアーキテクチャとは異なり、Catalyst SD-WANは集中管理されたソフトウェアコントローラを使用して、企業ネットワーク全体でルーティング、セキュリティ、トラフィック管理を自動化します。

プラットフォームは複数のコアコンポーネントで構成されています：

vManage — SD-WANファブリックを設定・監視するために使用される一元管理ダッシュボード。
vSmart — ルーティングインテリジェンスとポリシー配布を担当する制御プレーンコントローラ。
vBond — SD-WANデバイスをネットワークに認証・接続するオーケストレーションサービス。
WANエッジルーター — ブランチロケーションとクラウド環境に配置された物理または仮想ルーター。

Catalyst SD-WANは遅延、ジッター、パケット損失、リンク品質などのリアルタイムメトリクスに基づいて、アプリケーション向けの最適なネットワークパスを動的に選択します。これにより企業はVoIP、Microsoft Teams、Zoom、クラウドアプリケーションなどのサービスのパフォーマンスを最適化できます。

SD-WANコントローラはルーティングポリシー、セグメンテーション、信頼関係、デバイスオンボーディングを管理するため、企業ネットワークの「脳」として機能します。その結果、CVE-2026-20182などのこれらのコントローラに影響する脆弱性は、成功した悪用により攻撃者が企業全体のネットワーク操作を広範に制御できる可能性があるため、極めて重大と考えられます。

vdaemonサービス

Cisco SD-WAN認証バイパス脆弱性はvdaemonサービス内に存在します。このサービスはSD-WAN制御プレーン内の安全な通信を担当するコアコンポーネントです。このサービスはDTLS（データグラム転送層セキュリティ）をUDPポート12346上で使用して通信し、コントローラ間およびデバイスオーケストレーショントラフィックに使用されます。

セキュリティ研究者のJonah BurgessとRapid7のStephen FewerがCVE-2026-20182を発見し、この問題は以前にパッチされた脆弱性のバイパスではないことを確認しました。代わりに、vdaemonネットワーキングスタックの同様の領域にある完全に別の欠陥です。

SD-WAN DTLS認証フロー

脆弱性はvSmartおよび関連コントローラで使用されるSD-WAN DTLS認証プロセス内に存在します。

認証ステップ

1. DTLSハンドシェイク開始
攻撃者は任意または無効な証明書を使用してUDP/12346でCisco vSmartコントローラへのDTLSコネクションを開始します。

2. vSmartからのCHALLENGEレスポンス
証明書検証が内部的に失敗しても、vdaemonサービスは誤って認証プロセスを継続し、ランダムなチャレンジデータを含むCHALLENGEメッセージ（msg_type=8）を送信します。

3. 細工されたCHALLENGE_ACKレスポンス
攻撃者はCHALLENGE_ACK（msg_type=9）で応答しながら以下を設定します：

device_type = 2

これはピアをvHubデバイスとして識別し、重大な検証チェックをスキップするロジックパスをトリガーします。

4. 認証状態の設定
コントローラはCHALLENGE_ACK_ACK（msg_type=10）を送信し、内部的に悪意のあるピアを認証済みとしてマークします：

peer→authenticated = 1;

5. 認証済みHelloエクスチェンジ
攻撃者はHelloメッセージ（msg_type=5）を送信します。ピアは認証済みと見なされているため、コントローラはコネクションを受け入れ、ピア状態を以下に移行させます：

new-state: up

6. 不正なピアがSD-WANファブリックに正常に参加
攻撃者は合法的なSD-WAN制御プレーンピアとして扱われ、vSmartコントローラとのルーティング、オーケストレーション、ポリシーメッセージを交換する可能性があります。

CVE-2026-20182とは

CVE-2026-20182はCVSSスコア10.0の重大なCisco SD-WAN認証バイパス脆弱性です。この欠陥はCisco Catalyst SD-WANコントローラに影響し、SD-WAN制御プレーン認証を担当するvdaemonサービス内に存在します。

この脆弱性により、リモートの無認証攻撃者がDTLS認証プロセス中に証明書および信頼検証メカニズムをバイパスし、信頼されたSD-WAN制御プレーンピアになることができます。

成功した悪用により、攻撃者は影響を受けるSD-WANコントローラへの高い特権アクセス権を取得し、認証されたオーケストレーションメッセージを交換し、ネットワーク動作を操作し、SD-WAN基盤への永続的なアクセスを維持できる可能性があります。

影響を受けるプロダクト

CVE-2026-20182は以下の両方に影響します：

Cisco Catalyst SD-WANコントローラ
Cisco Catalyst SD-WANマネージャー

デバイス設定に関わらず脆弱性は存在します。これはSD-WAN制御プレーンで使用されるコアvdaemon認証ロジック内に問題が存在するためです。

Ciscoによると、この脆弱性は以下を含むすべての主要なSD-WAN展開モデルに影響します：

展開タイプ	影響を受ける
オンプレミス展開	はい
Cisco SD-WAN Cloud-Pro	はい
Cisco SD-WAN Cloud（Ciscoマネージド）	はい
Cisco SD-WAN for Government (FedRAMP)	はい

脆弱性は特定のオプション機能または設定ではなく認証メカニズム自体に影響するため、公開されている脆弱なSD-WANコントローラはすべて無認証のリモート悪用の対象となる可能性があります。

根本原因分析

DTLSハンドシェイクが完了した後—これは任意または信頼されていないクライアント証明書を誤って受け入れます—Cisco vdaemonサービスは256ランダムバイトを含むCHALLENGEメッセージを送信し、ピア検証中に使用される認証局(CA) RSA公開鍵コンポーネントを含む複数のTLV構造を含みます。

クライアントはCHALLENGE_ACKメッセージで応答する必要があります。脆弱性はこのパケットの処理中に以下の関数内で存在します：

vbond_proc_challenge_ack()

この関数はデバイスタイプ固有の証明書検証ロジックを実行します。ただし、接続するピアがvHubデバイス（device_type = 2）として識別される場合、予想される証明書検証パスはスキップされ、無認証のピアが信頼されたSD-WAN制御プレーンの参加者になることを許可します。

vdaemonメッセージヘッダー構造

vdaemonプロトコルは固定12バイトのメッセージヘッダー形式を使用します：

バイトオフセット	バイトサイズ	フィールド	メモ
0	1	msg_type	下位ニブル=メッセージタイプ、上位ニブル=プロトコルバージョン
1	1	device_info	上位ニブル=device_type、下位ニブル=フラグ
2	1	flags	標準値：0xA0
3	1	padding	常に0x00
4 – 7	4	domain_id	ビッグエンディアンuint32
8 – 11	4	site_id	ビッグエンディアンuint32

悪用に関与する重大なフィールドは：

device_info

具体的には、このバイトの上位ニブルがピアdevice_typeを制御します。

サポートされているデバイスタイプ

vdaemonプロトコルはdevice_infoフィールドの上位ニブル内でエンコードされた複数のデバイスロールを定義します：

値	デバイスタイプ	ロール
1	vEdge	データプレーンルーター
2	vHub	ハブルーター
3	vSmart	制御プレーンコントローラ
4	vBond	オーケストレーター/信頼アンカー
5	vManage	管理プレーン
6	ZTP	ゼロタッチプロビジョニング

悪用中、攻撃者は具体的に以下を設定します：

device_type = 2

これにより、vHubピアに関連付けられた脆弱なコードパスが重大な証明書検証チェックをバイパスしたかのように実行されます。

その結果、悪意のあるピアはチャレンジレスポンスシーケンスを正常に完了し、無効な証明書を提示しているにもかかわらずSD-WAN制御プレーン内で認証されます。

以下はvbond_proc_challenge_ack()の逆コンパイルコード的な記述です。このDTLSハンドシェイク完了後の受信CHALLENGE_ACKメッセージ処理を担当する関数です。

DTLSセッションが確立されると、関数はOpenSSLルーチン（以下など）を使用してピア証明書シリアル番号を抽出します：

X509_get_serialNumber()
ASN1_INTEGER_to_BN()
BN_bn2hex()

証明書シリアルを抽出した後、関数はデバイスタイプ固有の検証パスの一連に入ります。問題は、すべての主要なSD-WANデバイスタイプが何らかの形式の証明書またはID検証を受けることです。ただしvHub（device_type == 2）を除き、すべての検証ロジックをスキップし、最終的に認証済みとしてマークされます。

if ( *(_DWORD *)(a3 + 8) == 3 
|| *(_DWORD )(a3 + 8) == 5 ) // [1] { 
v24 = is_serial_duplicate(
          v22,
          *(_DWORD *)(a3 + 8),
          ...
      );
if ( v24 )
{
    if ( (unsigned __int8)
         vbond_peer_dup_check(
             a1,
             a2,
             v24,
         ) ) // [2]
    {
        v19 = 36;
        goto LABEL_179; // 重複ピアを拒否
    }
}
}
if ( *(_DWORD *)(a3 + 8) == 3 && *(_DWORD *)(a1 + 8) == 3
|| *(_DWORD *)(a3 + 8) == 5 && *(_DWORD *)(a1 + 8) == 3
|| *(_DWORD *)(a3 + 8) == 5 && *(_DWORD *)(a1 + 8) == 5
|| *(_DWORD *)(a3 + 8) == 5 && *(_DWORD *)(a1 + 8) == 4
|| *(_DWORD *)(a3 + 8) == 3 && *(_DWORD *)(a1 + 8) == 4 ) // [3] { v19 = vdaemon_dtls_verify_peer_cert(a2);
if ( v19 )
    v18 = 0;
vdaemon_send_challenge_ack_ack(
    a1,
    *(_QWORD *)(a2 + 1232),
    a2,
    v18
);
if ( v18 != 1 )
    goto LABEL_179;
vbond_send_ssh_keys_to_vmanage_peer(a1, a2);
} if ( *(_DWORD *)(a3 + 8) == 1 // [4] 
&& ( dword_2A1A28 == 4
 || dword_2A1A28 == 3 
|| dword_2A1A28 == 5 ) ) {
if ( vdaemon_verify_peer_bidcert(a2, ...) )
    goto LABEL_179;
}
return 0LL; 
LABEL_179: return v19;

コード説明

これは以下の一部です：

vdaemon!vbond_proc_challenge_ack()

SD-WAN認証中のCHALLENGE_ACKメッセージを処理します。

1. vSmart/vManage検証

if ( device_type == 3 || device_type == 5 )

このブロックは以下の場合にのみ実行されます：

3 = vSmart
5 = vManage

関数はピア証明書シリアルが既に存在するかどうかを確認します：

is_serial_duplicate()

別のピアが既に同じ証明書を使用している場合：

vbond_peer_dup_check()

コネクションを拒否し、以下にジャンプします：

LABEL_179

これが失敗パスです。

2. 完全な証明書検証

vdaemon_dtls_verify_peer_cert(a2);

これは以下を実行します：

証明書チェーン検証
信頼されたCA検証
SD-WAN信頼チェック

これは以下のような特定のコントローラ関係にのみ適用されます：

vSmart ↔ vSmart
vManage ↔ vSmart
vManage ↔ vBond

検証が失敗した場合：

goto LABEL_179;

これはピアを拒否します。

3. vEdgeハードウェア検証

if ( device_type == 1 )

vEdgeデバイスは以下を通じて検証されます：

vdaemon_verify_peer_bidcert()

これは以下を検証します：

TPM/ハードウェア証明書
ボードID
OTPアイデンティティ
チャレンジシグネチャ

失敗するとコネクションが拒否されます。

脆弱性

以下に対する検証ブロックはありません：

device_type == 2

これは以下に対応します：

vHub

その結果、vHubピアは以下をバイパスします：

証明書検証
重複チェック
ハードウェア検証

関数は単にすべての検証ロジックをスキップして実行を継続します。

以下の表はvbond_proc_challenge_ack()内のCHALLENGE_ACKメッセージ処理中に各SD-WANデバイスタイプに適用される認証および検証ロジックをまとめています：

デバイスタイプ	値	実行される検証	結果
vEdge	1	ハードウェア/仮想エッジ証明書検証、TPM検証、チャレンジレスポンスシグネチャ検証、ボードID チェック、OTP検証	認証前に検証
vHub	2	検証が実行されない	peer→authenticated = 1に直接フォールスルー
vSmart	3	証明書チェーン検証、シリアル検索、重複ピアチェック、DTLSピア証明書検証	認証前に検証
vBond	4	信頼アンカー処理は別のロジックパスで実行	他の場所で検証
vManage	5	証明書チェーン検証、シリアル検索、重複ピアチェック、DTLSピア証明書検証	認証前に検証

重大な問題はvHub（device_type == 2）に対する検証パスが完全に欠落していることです。他のすべての主要なSD-WANデバイスロールとは異なり、vHubピアは以下を決して経験しません：

証明書チェーン検証
重複シリアルチェック
ハードウェアID検証
信頼アンカー実装

その結果、vHubとして識別されるピアはすべての認証チェックをバイパスし、最終的に以下に到達します：

peer→authenticated = 1;

この無条件の認証割り当てはCVE-2026-20182の認証バイパス脆弱性の根本原因です。

したがって、リモートの無認証攻撃者は任意の自己署名または攻撃者制御の証明書を使用してvSmartコントローラへのDTLSセッションを確立し、CHALLENGE_ACKメッセージ内でvHub（device_type = 2）であると主張することで認証をバイパスできます。有効な認証情報、Cisco発行証明書、またはSD-WAN展開の事前知識は必要ありません。

この問題の悪用可能性を完全に理解するために、CHALLENGE_ACKパケットが実際に脆弱な以下に到達できることを確認する必要があります：

vbond_proc_challenge_ack()

認証が完了する前のハンドラー。

答えは以下内に実装されたプリディスパッチ認証ゲートにあります：

vdaemon!vbond_proc_msg()
if ( *(_BYTE *)(v100 + 70) != 1
 && *(_DWORD *)(a3 + 4) != 5
 && *(_DWORD *)(a3 + 4) != 8
 && *(_DWORD *)(a3 + 4) != 9
 && *(_DWORD *)(a3 + 4)
 && *(_DWORD *)(a3 + 4) != 10
 && *(_DWORD *)(a3 + 4) != 7
 && *(_DWORD *)(a3 + 4) != 11 )
{
    return 20;
}

この条件は実質的に認証前のホワイトリストです。メッセージは以下の場合にのみ拒否されます：

ピアが認証されていない、および
受信メッセージタイプが認証フェーズ中に明示的に許可されていない

重大なことに、以下のメッセージタイプは認証前に許可されます：

CHALLENGE
CHALLENGE_ACK
NEW_CHALLENGE_ACK
CHALLENGE_ACK_ACK
データ
TEAR_DOWN

最も重要なことに：

CHALLENGE_ACK = メッセージタイプ9

このメッセージタイプはホワイトリストに明示的に含まれています。

これは無認証の攻撃者がCHALLENGE_ACKパケットを直接送信し、信頼を確立せずに脆弱な以下に到達できることを意味します：

vbond_proc_challenge_ack()

この動作は意図的です。認証ハンドシェイク自体はピアが認証されると見なされる前に発生する必要があるためです。

攻撃者が不足しているvHub検証パスを悪用し、以下をトリガーすると：

peer→authenticated = true;

最終ステップはHELLOメッセージ（メッセージタイプ5）を送信してピアをアクティブな制御プレーン状態に移行させることです。

HELLOハンドラーは二次認証チェックを実行します：

if ( *(_BYTE *)(v100 + 70) != 1 )
{
    return 0LL;
}
これ

は以下を検証します：

peer→authenticated == true

通常の処理を許可する前に。

悪用既にvHubバイパスを通じて認証フラグを設定しているため、HELLOメッセージは成功し、ピアはUP状態に移行します—実質的に完全に信頼されたSD-WAN制御プレーンピアになります。

認証後のSSHキー注入

認証バイパスを正常に悪用し、不正なピアをUP状態に移行させた後、攻撃者は認証されたSD-WAN制御プレーンメッセージハンドラーへのアクセスを得ます。特に危険な認証後のプリミティブの1つは以下による永続的なSSHキー注入です：

MSG_VMANAGE_TO_PEER（メッセージタイプ14）

処理者：

vdaemon!vbond_proc_vmanage_to_peer()

逆コンパイルされたコードは、ハンドラーが攻撃者制御のSSH公開鍵をvmanage-adminアカウントのauthorized_keysファイルに直接追加していることを明らかにします：

// vdaemon!vbond_proc_vmanage_to_peer()
stream = fopen(
    "/home/vmanage-admin/.ssh/authorized_keys",
    "a+"
); // [1]
if ( stream )
{
    if ( (unsigned __int8)
         read_key_data(
             (const char *)(a3 + 32),
             stream
         ) != 1
         && *(_BYTE *)(a3 + 32) )
    {
        if ( dword_241120 > 6 )
        {
            syslog(
                191,
                "%s[%d]: %%%s-%d: sshkey not present, writing to file",
                "vbond_proc_vmanage_to_peer",
                2368LL,
                aVdaemonDbgMisc,
                7LL
            );
        }
        fputs(
            (const char *)(a3 + 32),
            stream
        ); // [2]
    }
    fclose(stream);
}

ファイルは以下を使用して開かれます：

"a+"

ファイルを追加モードに配置します。これは攻撃者制御のSSHキーが既存の認証キーと共に追加されることを意味し、正当な管理アクセスを中断することなく永続性を可能にします。

[2]で、攻撃者制御バッファは以下に直接書き込まれます：

/home/vmanage-admin/.ssh/authorized_keys

を使用して：

fputs()

基本的な重複チェック以外にサニタイズ、フィルタリング、または検証はありません。

注入されたキーデータは固定769バイトのメッセージ構造内で配信されます：

オフセット	サイズ	フィールド
0–767	768バイト	キーバッファ(“\n” + ssh_pubkey + “\n” + “\x00” + パディング)
768	1バイト	TLVカウント(0)

先頭の改行は既存のauthorized_keysファイルが改行で終了しない場合でもSSHキーが正しく追加されるようにします。埋め込みのnullバイトはfputs()の文字列を終了し、残りのバイトは固定サイズバッファを埋めるためにゼロパディングされます。

重大なことに、この機能はデバイスタイプに関わらず認証されたSD-WANピアで利用可能です。vHub認証バイパスを悪用した後、攻撃者はこのメッセージハンドラーを悪用して、任意のSSH公開鍵をターゲットvSmartコントローラの特権に注入できます：

vmanage-admin

アカウント。

vmanage-adminは自動通信用の内部高特権サービスアカウントであるため：

vManage
vSmart
vBond

このプリミティブは認証バイパスを一時的な制御プレーン侵害から永続的で認証情報に依存しないSD-WAN基盤への特権アクセスに変換します。

悪用後の機能

Cisco SD-WAN認証バイパス脆弱性の悪用に成功すると、攻撃者は信頼されたSD-WAN制御プレーンピアになり、Cisco Catalyst SD-WAN環境内で高い特権内部機能へのアクセスを得ることができます。

左側では、攻撃者はvHub認証バイパス脆弱性を悪用することで侵害を開始します。細工されたCHALLENGE_ACKメッセージを通じて、攻撃者はSD-WAN信頼検証をバイパスし、vSmartコントローラへの認証アクセスを得ます。

ダイアグラムの中央では、侵害されたvSmartコントローラがプリマリ制御プレーン目標を表します。信頼されたピアとして認証されると、攻撃者はSD-WANオーケストレーション機能および企業WANマネジメント操作への特権アクセスを得ます。

その後、侵害はSD-WAN基盤全体にわたる複数の悪用後機能に拡大します：

ルーティング操作 — 攻撃者はルートアドバタイズメントを修正し、パス選択を変更し、SD-WANトラフィックフローを操作できます。
トラフィックリダイレクション — 企業トラフィックは攻撃者制御の基盤を通じてリダイレクト、インターセプト、またはリルーティングされる可能性があります。
セグメンテーション変更 — セキュリティセグメンテーションおよびポリシー境界を修正またはバイパスできます。
SSHキー永続性 — 攻撃者はSSH公開鍵をvmanage-adminアカウントに注入して長期的な特権アクセスを維持できます。
NETCONFの悪用 — 攻撃者はNETCONF管理インターフェースと相互作用して設定変更とオーケストレーション操作を実行できる可能性があります。
完全な制御プレーン侵害 — vSmartはSD-WANファブリック全体のルーティングおよび信頼関係をオーケストレーションするため、コントローラの侵害は企業全体のWAN環境に影響を与える可能性があります。

ダイアグラムの下部セクションは、以下を含む広範な企業への影響をハイライトしています：

データ公開
サービス中断
側方移動
悪意のある設定展開
企業全体のWAN侵害

全体的に、ダイアグラムはCVE-2026-20182が単一の認証バイパスからCisco SD-WAN制御プレーンおよび関連企業基盤の完全な侵害に拡大する方法を示しています。

Metasploitエクスプロイトモジュール

Cisco Catalyst SD-WANコントローラに影響する重大な認証バイパス脆弱性であるCVE-2026-20182用の新しいMetasploitオーキシリアリーモジュールが開発されました。

モジュール機能

Metasploitモジュールは認証バイパス後の完全なアクセスワークフローを自動化します。以下を含みます：

自己署名証明書を使用したDTLSハンドシェイク実行
vHubとして細工されたCHALLENGE_ACKパケット送信
SD-WAN認証バイパス
不正なピアをUP状態に移行
攻撃者制御のSSH公開鍵を以下に注入：
/home/vmanage-admin/.ssh/authorized_keys
SD-WANコントローラへの永続的な特権アクセス確立
以下のNETCONF管理サービスへのアクセス提供：TCP/830

検証

モジュールは以下に対して正常にテストされました：

Cisco Catalyst SD-WAN Controller 20.12.6.1

脆弱性検出と悪用の両方が正常に完了しました。

脆弱性チェック

msf auxiliary(admin/networking/cisco_sdwan_vhub_auth_bypass) > check
[+] 10.10.10.10:12346 - ターゲットは脆弱です。

認証バイパス成功 – vHub CHALLENGE_ACKは検証なしで受け入れられました

悪用

msf auxiliary(admin/networking/cisco_sdwan_vhub_auth_bypass) > run
[*] 192.168.80.11に対してモジュール実行中
[*] フェーズ1：自己署名証明書によるDTLSハンドシェイク
[*] DTLSハンドシェイク成功（自己署名証明書が受け入れられました）
[*] フェーズ2：サーバからのCHALLENGE待機中
[*] CHALLENGE受信（580バイト）
[*] フェーズ3：vHubとしてCHALLENGE_ACK送信中
[*] フェーズ4：サーバレスポンス待機中
[*] フェーズ5：認証済みピアとしてHello送信中
[+] Helloレスポンス受信 - vHubピアとして認証
[*] フェーズ6：vmanage-admin authorized_keysへのSSH公開鍵注入中
[*] RSA 2048ビットSSHキーペア生成中
[+] 認証バイパスおよびSSHキー注入完了

永続的なNETCONFアクセス

悪用後、攻撃者は注入されたSSHキーを使用してNETCONF管理サービスに認証できます：

ssh -i attacker_key.pem vmanage-admin@TARGET_IP -p 830

成功したアクセスは有効なNETCONFセッションを返します：

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    ...
  </capabilities>
  <session-id>16</session-id>
</hello>

これは注入されたvmanage-admin SSH認証情報を通じたSD-WAN管理プレーンへの正常な認証アクセスを確認します。

エクスプロイトはCVE-2026-20182が単なる認証バイパスではなく、企業SD-WAN基盤への永続的な特権アクセスを提供できる完全な制御プレーン侵害脆弱性であることを示しています。

セキュリティへの影響

認証バイパス
リモート攻撃者は有効な認証情報または信頼されたCisco発行証明書なしでSD-WAN認証をバイパスできます。
許可されない制御プレーンアクセス
攻撃者はvHub認証パスを悪用することで、信頼されたピアとしてSD-WAN制御プレーンに参加できます。
ネットワークトラフィック操作
悪意のある行為者はルーティング動作を修正し、トラフィックをリダイレクトし、SD-WANファブリック全体でWANオーケストレーションポリシーを操作できます。
通信のインターセプション
侵害されたコントローラはブランチ、クラウド環境、データセンター間の機密企業トラフィックを監視、インターセプト、またはリルーティングすることを攻撃者に許可できる可能性があります。
永続的なSSHアクセス攻撃者は任意のSSH公開鍵を特権vmanage-adminアカウントに注入でき、長期的な認証情報に依存しないアクセスを可能にします。
大規模なサービス中断
許可されない設定変更またはオーケストレーション悪用はネットワークの不安定性、セグメンテーション障害、または企業規模の停止を引き起こす可能性があります。
完全なSD-WANファブリック侵害
vSmartコントローラはルーティング、信頼関係、デバイスオンボーディングをオーケストレーションするため、成功した悪用は企業全体のSD-WAN基盤の侵害をもたらす可能性があります。

修復

Ciscoは影響を受けるCisco Catalyst SD-WAN展開全体でCVE-2026-20182に対処するソフトウェアアップデートをリリースしました。Ciscoによると、現在利用可能な回避策またはこの脆弱性の悪用を完全に防ぐ設定ベースの緩和策はありません。問題はSD-WAN認証ロジック自体に存在するため、固定されたソフトウェアリリースへのアップグレードが唯一の効果的な修復です。

公開されている運用組織：

vSmart
vBond
vManage

コントローラは脆弱性の以下の理由から緊急パッチを優先すべきです：

リモート到達可能性
無認証の攻撃サーフェス
制御プレーン影響
アクティブな悪用状態

以下の表はCiscoが提供する最初の固定ソフトウェアリリースをまとめています。

固定ソフトウェアリリース

Cisco Catalyst SD-WANリリース	最初の固定リリース
20.9より前	サポートされている固定リリースに移行
20.9	20.9.9.1
20.10	20.12.7.1
20.11*	20.12.7.1
20.12	20.12.5.4 / 20.12.6.2 / 20.12.7.1
20.13*	20.15.5.2
20.14*	20.15.5.2
20.15	20.15.4.4 / 20.15.5.2
20.16*	20.18.2.2
20.18	20.18.2.2
26.1.1	26.1.1.1

*でマークされたリリースはCiscoが推奨する新しいサポートされるトレーンに移行すべきです。

推奨インシデント対応アクション

成功した悪用は認証されたSD-WAN制御プレーンアクセスをもたらすため、ディフェンダーは脆弱なインターネット公開システムが既に侵害されている可能性があると仮定すべきです。

1. 直ちにアップグレード

すべて外部到達可能な修正：

vSmart
vBond
vManage

コントローラを運用上可能な限り早く固定リリースにパッチします。

2. DTLSおよび認証ログをレビュー

SD-WANログを以下について検査します：

予期しないDTLS接続
不明なピア識別子
疑わしいCHALLENGE_ACK活動
異常なピア状態移行

特に注意を払うべきはピアが予期せずに以下に移行することです：

state = UP

正当なオンボーディング活動なしで。

3. 認可されたSSHキーを監査

攻撃者が認証後にSSHキーを注入できるため、管理者は以下を検査すべきです：

/home/vmanage-admin/.ssh/authorized_keys

以下について：

不明な公開鍵
最近追加されたエントリ
疑わしいオートメーションアーティファクト

許可されないキーは成功した侵害と永続性を示す可能性があります。

4. 制御プレーンピアを調査

レビュー：

アクティブなSD-WANピア
ピアシリアル番号
コントローラ関係
予期しないvHubピア

不正な制御プレーン登録を示す可能性のある異常について。

5. 認証情報と信頼資料をローテーション

侵害が疑われる場合：

SSHキーをローテーション
証明書を再生成
API認証情報をローテーション
SD-WAN信頼関係を再確立

特に：

vmanage-admin
内部オートメーションアカウント
コントローラ間信頼チェーン

6. フォレンジック証拠を保存

侵害されたシステムをパッチする前に、組織は以下を収集すべきです：

コントローラログ
DTLSセッションデータ
メモリキャプチャ
SD-WAN設定スナップショット
SSHauthorized_keys履歴

これはインシデント対応とルート原因分析をサポートします。

結論

CVE-2026-20182はCisco Catalyst SD-WANに影響する高い影響の認証バイパス脆弱性です。CHALLENGE_ACKフェーズ中にvHubとして識別することで、無認証の攻撃者は証明書検証をバイパスし、信頼されたSD-WAN制御プレーンピアになることができます。認証されると、攻撃者は特権オーケストレーションメッセージを交換し、SD-WAN動作を操作し、内部サービスアカウントへのSSHキー注入を通じて永続的なアクセスを得る可能性があります。Cisco SD-WANコントローラは企業WAN環境全体のルーティング、セグメンテーション、信頼関係を管理するため、成功した悪用はSD-WAN制御プレーンの完全な侵害をもたらす可能性があります。公開されたCisco SD-WAN展開を運用している組織は影響を受けるシステムを直ちにアップグレードし、脆弱なインターネット公開コントローラを他に証明されるまで潜在的に侵害されたものとして扱うべきです。

翻訳元: https://www.resecurity.com/blog/article/cve-2026-20182-unauthenticated-cisco-sd-wan-control-plane-compromise-via-vhub-authentication-bypass