CVE-2026-20349｜Cisco ASA/FTD DoS の悪用確認と対処の手順

はじめに

2026 年 8 月 11 日、Cisco は Secure Firewall ASA Software および Secure FTD Software の Remote Access SSL VPN サービスに存在する脆弱性 CVE-2026-20349 を公開しました。同日、CISA は本脆弱性を Known Exploited Vulnerabilities（KEV）カタログへ追加しており、実際の攻撃に使われていることが確認されています。回避策は提供されておらず、対処の選択肢は Hot Fix の適用に絞られる状況です。

リモートアクセス VPN の終端としてインターネットに面している機器が対象となるため、影響を受ける構成であれば攻撃者から直接到達可能な位置にあります。認証を必要としない攻撃であることから、VPN ユーザーのアカウント管理では防げません。

本脆弱性は、細工された HTTP リクエストによって機器を予期せず再起動させられるもので、影響は可用性に限定されます。情報の窃取や設定の改ざんにはつながりませんが、リモートアクセス VPN が停止するため、在宅勤務や拠点間接続を VPN に依存している環境では業務影響が直接発生します。Remote Access SSL VPN または IKEv2 リモートアクセス VPN のクライアントサービス、Zero Trust Network Access のいずれかを有効にしている機器が対象となるため、まず自組織の設定を確認したうえで、該当する Hot Fix の適用計画を立てることをおすすめします。

CVE-2026-20349 の概要と悪用状況

本脆弱性は、Remote Access SSL VPN サービスが HTTP リクエストを処理する際のエラーチェックが不十分であることに起因します。認証されていない攻撃者がネットワーク経由で機器を再起動させられるため、サービス拒否（DoS）につながります。

攻撃条件と CVSS 8.6 が示すもの

CVSS v3.1 のベース スコアは 8.6（HIGH）で、ベクターは CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H です。各メトリックを分解すると、攻撃の難易度と影響範囲が明確になります。

注目すべきは、機密性と完全性への影響がいずれも None である一方、スコープが Changed になっている点です。ASA/FTD が再起動すれば、その機器を経由するリモートアクセス VPN セッションだけでなく、通過するトラフィック全体が影響を受けます。ファイアウォールという設置位置そのものが、DoS の影響を増幅させる構造になっています。

攻撃の成立条件は、細工された HTTP リクエストを Remote Access SSL VPN サービスへ送信することのみです。

参考: Cisco Security Advisory cisco-sa-asaftd-vpn-dos-dzv4mQFF
“sending a crafted HTTP request to the Remote Access SSL VPN service”
（細工された HTTP リクエストを Remote Access SSL VPN サービスへ送信する）
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpn-dos-dzv4mQFF

Cisco は 2026 年 8 月時点で PSIRT が実際の悪用を認識したとしており、アドバイザリの公開時点ですでに攻撃が観測されていた状況です。この点は、パッチ公開が先行する通常のアドバイザリとは前提が異なります。

KEV 登録と BOD 26-04 の対応期限

CISA は本脆弱性を 2026 年 8 月 11 日付で KEV カタログに追加し、対応期限を 2026 年 8 月 14 日としています。追加から 3 日という、KEV の中でも短い部類の設定です。

この期限は、2026 年 6 月に発行された BOD 26-04 に基づき、外部公開・KEV 掲載・自動化可否・技術的影響の 4 変数で決まります。このうち 3 つは CISA が Vulnrichment として CVE レコードに付与しており、本脆弱性では次の値が格納されています。

"options": [
  { "Exploitation": "active" },
  { "Automatable": "yes" },
  { "Technical Impact": "partial" }
]

悪用は実際に発生しており、攻撃の自動化も可能と判定されています。一方、技術的影響は Partial control です。機器を再起動させるサービス拒否は、完全な制御の奪取には当たらないという整理になります。

残る「外部公開の有無」は各組織が判定する変数です。インターネットに面したリモートアクセス VPN 終端であれば 3 日、外部から到達できない機器であれば 14 日が対応期限の目安となります。技術的影響が Partial であるため、いずれの場合もフォレンジック調査を伴う最短階層には該当しません。期限が決まる仕組みと 16 通りの組み合わせについては、関連記事『BOD 26-04 の対応期限の読み方』で整理しています。

BOD 26-04 が対象とするのは米国連邦政府の行政機関ですが、同じ CVE でも資産の公開状況で緊急度が変わるという考え方は、対象機器が多く一度に適用できない場合の優先順位付けに使えます。インターネットに面した機器から着手し、内部限定の機器は次の階層として扱う、という整理です。

なお、KEV エントリでは本脆弱性がランサムウェア キャンペーンで使われているかは Unknown とされています。

CWE-244 と説明文の関係

CVE レコードおよび KEV エントリでは、本脆弱性の弱点分類として CWE-244（Improper Clearing of Heap Memory Before Release、通称 Heap Inspection）が割り当てられています。KEV カタログ上の脆弱性名も Heap Inspection Vulnerability という表記です。

一方、MITRE の CWE-244 の定義は、パスワードや暗号鍵といった機微データをクリアしないままヒープ領域を解放することで、メモリダンプ等を通じて情報が露出する弱点を指します。参照先は以下のとおりです。

https://cwe.mitre.org/data/definitions/244.html

Cisco のアドバイザリが記載する原因は HTTP リクエスト処理時のエラーチェック不足であり、CVSS ベクターも機密性への影響を None としています。CWE の分類名から情報漏えい型の脆弱性を想起すると、実際の影響を読み違える可能性があります。

リスク評価にあたっては、CWE の分類名ではなく、アドバイザリ本文の説明と CVSS ベクターを基準に判断することをおすすめします。本脆弱性で優先して考慮すべきは、情報漏えいではなく機器の再起動によるサービス停止です。社内へ影響を報告する際も、この点を明示しておくと認識のずれを防ぎやすくなります。

影響を受ける構成の判定

本脆弱性の影響を受けるのは、脆弱なリリースの ASA Software または FTD Software が動作しており、かつ SSL のリッスン ソケットを有効にする機能が設定されている機器です。バージョンだけでは判定できないため、設定内容とあわせて確認する必要があります。

Cisco がアドバイザリで挙げている脆弱な構成は次の 3 つです。

いずれか 1 つでも該当すれば対象となります。逆に、これらをいずれも設定していない機器であれば、脆弱なリリースが動作していても本脆弱性の影響は受けないと整理できます。

show running-config での確認ポイント

CLI から確認する場合、機能ごとに次のコマンドで判定できます。

SSL VPN が有効かどうかを確認します。

firewall# show running-config webvpn | include ^ enable
enable outside

出力があれば、表示されたインターフェイスで Remote Access SSL VPN が有効です。出力が空であれば、SSL VPN は有効になっていません。

IKEv2 が有効かどうかを確認します。

firewall# show running-config crypto ikev2 | include enable
crypto ikev2 enable outside client-services port 443

出力があれば、少なくとも 1 つのインターフェイスで IKEv2 が有効です。ここで client-services が付いている場合、アドバイザリが挙げる脆弱な構成に該当します。

FTD の Zero Trust Network Access については、FTD CLI で show running-config zero-trust により設定情報を確認できます。ただし ZTNA は FMC から設定する機能のため、後述の管理画面側での確認とあわせて判断することをおすすめします。

補足として、SSL のリッスン ソケットが実際に開いているかを直接確認する方法もあります。今回のアドバイザリには記載がありませんが、Cisco は同種の Remote Access SSL VPN DoS アドバイザリで次の確認方法を示しています。

参考: Cisco Security Advisory cisco-sa-asaftd-vpn-dos-mfPekA6e
“look for an SSL listen socket on any TCP port”
（任意の TCP ポートで SSL リッスン ソケットを探す）
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpn-dos-mfPekA6e

firewall# show asp table socket | include SSL
SSL       00185038  LISTEN     172.16.0.250:443    0.0.0.0:*
SSL       00188638  LISTEN      10.0.0.250:8443    0.0.0.0:*

設定ファイルの確認と実際のソケットの状態を突き合わせておくと、判定の確度が上がります。ただし今回のアドバイザリが判定基準として示しているのは前掲の 3 つの設定であるため、最終的な判断はそちらを基準に行ってください。

FMC / FDM 側での Remote Access VPN 設定の確認

FTD の場合、リモートアクセス VPN 機能は管理側から設定します。CLI に入らずに確認する場合は、次の画面を参照します。

• Cisco Secure Firewall Management Center: Devices > VPN > Remote Access
• Cisco Secure Firewall Device Manager: Remote Access VPN

Zero Trust Network Access は FMC から設定する機能で、Policies > Access Control 配下の Zero Trust Application ポリシーとして管理されます。ZTNA が利用できるのは FMC 7.4.0 以降で管理される FTD 7.4.0 以降（Firepower 4200 シリーズ）、その他のプラットフォームでは FTD 7.4.1 以降です。7.3 以前を運用している環境では ZTNA による該当は発生しません。

管理台数が多い環境では、FMC の Devices 一覧から各デバイスの VPN 設定有無を一覧化し、対象機器を先に絞り込んでおくと、後続の Hot Fix 適用計画を立てやすくなります。

影響を受けないと明示されている製品

Cisco は、本脆弱性が Cisco Secure Firewall Management Center（FMC）Software には影響しないことを確認済みとしています。FMC 自体は対象外ですが、FMC が管理する FTD デバイスは対象となり得るため、管理対象側の確認が必要です。

また、アドバイザリの Vulnerable Products に記載された製品以外については、影響が確認されていないという扱いになります。記載がないことは安全性の保証ではないため、Cisco Software Checker での確認とあわせて判断することをおすすめします。

ASA / FTD 別の Hot Fix 対応表

本脆弱性への対処として Cisco が提供しているのは、通常のメンテナンス リリースではなく Hot Fix です。Cisco.com の Software Center からダウンロードできます。

ASA Software の Hot Fix

9.16 および 9.18 向けの Hot Fix は、89. で始まる通常とは異なる番号体系になっています。この点については後述します。

FTD Software の Hot Fix

FTD はプラットフォームごとにファイルが分かれています。適用対象の機種に対応したファイルを選択します。

10.0 のみ、Secure Firewall 200 シリーズ向けファイルの識別子が R- で始まる点に注意が必要です。他のファイルは同一リリース内で S- に統一されているため、機種ごとの取り違えが起こりやすい箇所です。

FTD デバイスのアップグレード手順については、Cisco Secure FMC のアップグレード ガイドが参照先として案内されています。Cisco Secure Firewall 製品群における Hot Fix 適用の進め方は、関連記事『Cisco FMC のホットフィックス対応』もあわせて参考にしてください。

表に該当がない場合の Software Checker での確認

Hot Fix 表と CVE レコードの影響バージョン一覧を突き合わせると、いくつか差分があります。

• ASA 9.19 系は影響を受けるバージョンとして CVE レコードに記載されていますが、Hot Fix 表には 9.19 向けの記載がありません。
• FTD 7.3 系についても同様に、影響を受けるバージョンとして記載されている一方で Hot Fix の提供がありません。
• CVE レコードには FTD 7.2.12、7.4.8、7.7.13、10.0.2 といった、Hot Fix の基準リリースより新しいバージョンも含まれています。

Hot Fix 表に自環境のリリースが見当たらない場合は、Cisco Software Checker で個別に確認する方法が案内されています。

https://sec.cloudapps.cisco.com/security/center/softwarechecker.x

Software Checker では、対象ソフトウェア（ASA / FMC / FTD）とプラットフォームを選択し、リリース番号を入力して検索します。入力例は ASA Software であれば 9.20.3.4、FTD Software であれば 7.4.2 のような形式です。検索対象は全アドバイザリ、Critical および High のみ、当該アドバイザリのみの 3 通りから選べます。

Hot Fix が提供されていないリリースを運用している場合、Hot Fix が提供されているトレインへの移行を検討することになります。移行の可否とタイミングは、機種の対応状況やライセンス、既存設定の互換性に左右されるため、以下の公式ドキュメントで事前に確認しておくことをおすすめします。

• Cisco Secure Firewall ASA Compatibility
• Cisco Secure Firewall ASA Upgrade Guide
• Cisco Secure Firewall Threat Defense Compatibility Guide

ASDM 7.24.1.374 が必要になるケース

ASA 9.16 および 9.18 向けの Hot Fix は、89.16.4.50、89.18.4.50 という 89. で始まる番号体系になっています。Cisco はこの点について、89 で始まる Hot Fix を適用する場合は ASDM リリース 7.24.1.374 を導入するよう案内しています。これより前の ASDM リリースは、この ASA Software のリリース番号体系を認識できないためです。

ASDM を併用している環境では、Hot Fix の適用前に ASDM のバージョンを確認し、必要であれば ASDM 側の更新を作業計画に含めておくことをおすすめします。 ASA 本体の Hot Fix 適用だけを計画していると、適用後に ASDM から機器を管理できなくなり、切り戻し判断に時間を要する可能性があります。

CLI のみで運用している環境や、9.20 以降のトレインを運用している環境ではこの制約は該当しません。自環境がどちらに当たるかを先に切り分けておくと、作業手順が整理しやすくなります。

適用にあたっての事前準備と作業の進め方

Hot Fix は通常のメンテナンス リリースとは適用の性質が異なり、後戻りの選択肢も限られます。作業に入る前に、影響範囲と切り戻しの前提を整理しておくと、想定外の事態に対応しやすくなります。

通信断とメンテナンス時間の見積もり

Cisco は、デバイスへの Hot Fix 適用がトラフィックの流れと検査に影響し得ることを示しています。特にデバイスが再起動する場合や、設定の展開が必要になる場合に影響が大きくなります。影響の程度は、機種、構成（スタンドアロン、HA、クラスター）、インターフェイス構成によって変わります。

具体的な所要時間や通信断時間は公式には示されていません。同一機種・同一リリースでの検証環境があれば、事前に実測しておくと計画の精度が上がります。実測が難しい場合は、再起動を伴う前提でメンテナンス ウィンドウを確保しておくことをおすすめします。

作業前に確認しておきたい項目を整理します。

• 設定のバックアップを取得し、機器外部に保存しておく
• 現在のバージョンと、適用対象の Hot Fix ファイルの対応を再確認する
• コンソール接続の手段を確保する（管理インターフェイス経由で到達できなくなった場合の備え）
• ASDM を併用している場合、必要な ASDM バージョンを事前に用意する
• HA 構成の場合、同期状態が正常であることを確認する

FTD の Hot Fix は、多くの場合システムから直接ダウンロードできません。Cisco Support & Download サイトから取得し、FMC 7.2.6 以降または 7.4.1 以降、Cloud-Delivered FMC、FDM では手動でアップロードします。FMC 環境では、デバイスが Hot Fix を取得する内部 Web サーバーを構成する方法もあります。なお、Security Cloud Control から FTD へ Hot Fix を適用することはできません。

適用手順はパッチと同じ流れになります。FMC 管理下の環境では、FTD ではなく現在稼働している FMC のバージョンに対応したアップグレード ガイドを参照します。

ASA の Hot Fix は Software Center から取得したイメージを適用する形になります。HA 構成での作業順序や、イメージの指定方法については以下の公式ドキュメントを参照してください。

• Cisco Secure Firewall ASA Upgrade Guide
• Upgrade ASA Active/Standby Failover Pair for the Secure Firewall

アクティブ / スタンバイの Failover 構成では、スタンバイ側から順に適用し、切り替えを挟んで残る 1 台を処理する流れになります。台数が多い環境では、インターネットに面した機器から先に着手する順序が現実的です。

適用後の確認とロールバック観点

FTD では、Hot Fix を適用してもソフトウェアのバージョン番号やビルド番号は更新されません。管理画面のバージョン表示だけでは適用の成否を判断できないため、Linux シェル（expert モード）で次のコマンドを実行して確認します。

> expert
admin@firepower:~$ cat /etc/sf/patch_history

このコマンドは、初回インストール以降に適用されたアップグレード、パッチ、Hot Fix、pre-install パッケージの履歴を一覧表示します。

適用作業中に注意したい点として、Cisco は次の 3 つを明示しています。

• Hot Fix のインストール中に設定変更や展開を行わない
• システムが停止しているように見えても、手動での再起動やシャットダウンを行わない（使用不能な状態になり、再イメージ化が必要になる可能性があります）
• 同一のアプライアンスに同じ Hot Fix を複数回インストールしない

Hot Fix が失敗した場合やアプライアンスが応答しなくなった場合は、自力での復旧を試みる前に Cisco TAC へ連絡することが案内されています。

切り戻しについては、通常のパッチとは前提が異なります。

参考: Cisco Secure Firewall Threat Defense/Firepower Hotfix Release Notes
“Uninstall is not recommended for hotfixes and hotfixed patches.”
（Hot Fix および Hot Fix 適用済みパッチのアンインストールは推奨されない）
https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/release-notes/threat-defense/hotfix/threat-defense-release-notes-hotfix.html

やむを得ずアンインストールする場合は、インストールと逆の順序（後に入れたものから先に外す）で実施する必要があり、FTD では expert モードでの操作となるため順序の管理は作業者側の責任になります。実務上は、アンインストール前提の計画は立てず、適用前のバックアップと再イメージ化の手順を控えておく方が現実的です。

適用後は、脆弱性への対処が完了したことに加えて、リモートアクセス VPN が正常に機能しているかを確認します。VPN の新規接続、既存セッションの継続、認証連携（RADIUS、SAML 等）の動作は、Hot Fix 適用後に切り分けが必要になりやすい箇所です。

回避策がない中での暫定的なリスク低減

Cisco は本脆弱性について、回避策が存在しないことを明示しています。以下に挙げる内容は脆弱性そのものを解消するものではなく、Hot Fix の適用が完了するまでの間に攻撃を受ける可能性を下げるための考え方です。対処としては Hot Fix の適用を進めたうえで、補助的な措置として検討することをおすすめします。

管理・VPN インターフェースの露出見直し

本脆弱性の対象となるのは、SSL のリッスン ソケットを有効にする 3 つの機能です。このうち実際には使用していない機能があれば、無効化することで攻撃対象となる面を減らせます。

• IKEv2 リモートアクセス VPN のクライアント サービスを使っていない場合、client-services の設定を見直す
• Zero Trust Network Access を検証目的で有効にしたまま運用に入っていない場合、設定を確認する

一方、Remote Access SSL VPN を本番運用している環境では、機能を止めること自体が業務停止を意味します。この場合、機能の無効化は選択肢になりません。

接続元が特定の拠点や国に限定できる環境であれば、送信元による絞り込みも検討の余地があります。BOD 26-04 の考え方でも、資産をインターネットから切り離すという対応は「公開されているか」という変数を変えるものとして扱われており、対応の緊急度を下げる方向に働きます。在宅勤務者が任意の回線から接続する構成では適用しにくい方法ですが、拠点間接続専用の機器であれば有効な場合があります。

いずれの措置も、実施前に業務影響の確認をおすすめします。

上位・別レイヤーでの緩和という選択肢

Hot Fix の適用までに時間を要する場合、上位機器や別レイヤーでの緩和を検討することがあります。IPS による仮想パッチのように、脆弱性を持つ機器の手前で攻撃通信を遮断する考え方です。この手法の位置づけや限界については、関連記事『IPS による仮想パッチの考え方』も参考にしてください。

ただし本脆弱性の場合、いくつか制約があります。攻撃通信は正規の Remote Access SSL VPN サービス宛の HTTPS であり、暗号化された通信の中身を検査できる構成でなければシグネチャによる判定は難しくなります。また、公開直後の脆弱性に対応するシグネチャが提供されているかはベンダーごとに異なります。導入済みの製品でシグネチャが提供されているかを確認したうえで判断することをおすすめします。

あわせて、機器の予期しない再起動を検知できる体制を整えておくと、攻撃を受けた場合の把握が早くなります。ASA / FTD の再起動を示すログの転送先を確認し、監視システム側でアラートが上がる設定になっているかを点検しておくと、VPN が使えないという利用者からの申告よりも先に状況を把握できます。境界機器へ向かう通信の異常を検知する手段については、関連記事『NDR 製品の比較と選定』も判断材料になります。

なお、KEV エントリでは対応内容として、パッチ適用前に侵害を受けていないかを確認する工程（Forensics Triage）が示されています。

本脆弱性の影響は可用性に限定されますが、ASA / FTD は過去にも複数の脆弱性で標的とされてきた製品です。Hot Fix の適用にあわせて、対象機器のログ保全と直近の再起動履歴の確認を作業計画に含めておくと、後から状況を説明する際の材料になります。

まとめ

CVE-2026-20349 は、Cisco Secure Firewall ASA / FTD の Remote Access SSL VPN サービスに存在する DoS 脆弱性です。認証を必要とせずにネットワーク経由で機器を再起動させられ、すでに実際の攻撃で使われていることが確認されています。回避策は提供されておらず、対処は Hot Fix の適用に絞られます。

• CVSS 8.6、認証不要かつネットワーク経由で成立する攻撃
• 影響は可用性のみで、情報漏えいや設定改ざんは含まれない
• CISA が 2026 年 8 月 11 日に KEV へ追加、対応期限は 8 月 14 日
• 対象は SSL VPN、IKEv2 クライアント サービス、ZTNA のいずれかを有効にした機器
• ASA 9.19 系と FTD 7.3 系は Hot Fix の提供がなく、Software Checker での確認が必要
• ASA 9.16 / 9.18 向け Hot Fix は ASDM 7.24.1.374 を前提とする
• Hot Fix のアンインストールは推奨されておらず、事前バックアップが現実的な備え

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