情報処理推進機構（IPA）が運営する脆弱性対策情報データベース「JVN iPedia」は2026年8月21日、シスコシステムズのファイアウォール製品「Cisco Secure Firewall Threat Defense（FTD）」の脆弱性をJVNDB-2026-029459として登録した。特定の設定をしている環境では、細工されたTLSパケットを送りつけるだけで、通信を検査するエンジンが予期せず再起動し、ファイアウォール自体が通信を遮断してしまう。情報が盗まれるわけではない。それでも、ネットワークの出入口に置かれた装置が止まれば、その先の業務も止まりかねない。
検査エンジンが落ちると、通信も落ちる
対象となるのはFTDに搭載された検出エンジン「Snort 3」のTLS暗号処理部分だ。シスコによれば、TLSプロトコルの実装が適切でないことに起因し、認証を経ていないリモートの攻撃者がSnort 3の検出エンジンを予期せず再起動させることが可能だという。エンジンが再起動している間、FTDを稼働させているデバイスはネットワークトラフィックをドロップし、サービス運用妨害（DoS）状態に陥る。
共通脆弱性識別子はCVE-2026-20006、脆弱性タイプはCWE-388（エラー処理）。深刻度の指標である共通脆弱性評価システム（CVSS）の基本値は5.8で、JVN iPediaの区分では深刻度「警告」にあたる。攻撃元区分はネットワーク、攻撃条件の複雑さは低、攻撃に必要な特権レベルと利用者の関与はいずれも不要——つまり、通信が届く位置にいれば誰でも仕掛けられる。一方で機密性と完全性への影響はなく、可用性への影響も「低」にとどまる。データが漏れるタイプの脆弱性ではない、という評価だ。
なお、シスコはTLS 1.3がこの脆弱性の影響を受けないと明記している。
影響するのは「ある設定をしている環境」だけ
見落とされやすいのは、FTDを使っていれば必ず影響を受けるわけではない、という点だ。シスコのアドバイザリは、脆弱なバージョンのFTDソフトウェアまたはFirePOWER Servicesを稼働させたうえで、次の三つの条件がすべて揃った場合に影響を受けるとしている。
- Snort 3が有効になっている
- SSLポリシーまたは復号ポリシーに、特定のTLSバージョンからの通信をブロックするルールが適用されている
- SSLポリシーまたは復号ポリシーが、未サポートの暗号スイートの通信を復号しない設定になっている
つまり「古いTLSは通さない」という、セキュリティ上むしろ望ましいはずの設定が引き金になる。管理画面のSSL／復号ポリシーのバージョンタブにおいて、TLS 1.0・1.1・1.2のいずれかのチェックが外れており、アクションが「ブロック」に設定されていれば該当しうる。加えて「Undecryptable Actions」タブの未サポート暗号スイートの扱いが「Do not decrypt」であれば、条件が揃う。
影響を受けるバージョンは7.2系から7.6系まで広範囲に及ぶ。一方でCisco Secure Firewall ASA、Secure FMC、Meraki製品、Cisco Umbrella Cloud-delivered Firewall、オープンソース版のSnort 2およびSnort 3などは影響を受けないことが確認されている。
回避策はある。ただし暫定的なもの
シスコは回避策として、特定のTLSバージョンをブロックしない設定に変更する手順を示している。SSL／復号ポリシーの該当ルールでバージョンのチェックボックスをすべてオンにし、保存して展開する、という内容だ。
ただしこれは、脆弱性の引き金となる設定そのものをやめる措置でもある。シスコ自身も、回避策や緩和策は修正済みバージョンへの更新が可能になるまでの一時的な解決策と位置づけ、恒久対処としては修正版へのアップグレードを強く推奨している。自社環境が該当するかどうかは、シスコが提供する「Cisco Software Checker」で確認できる。
3月の公表が、8月に日本語で届く
もう一つ注目したいのは時間差だ。シスコがこのアドバイザリを公開したのは2026年3月4日、同社のファイアウォール関連アドバイザリをまとめた定期公開の一環としてだった。JVN iPediaへの登録はそこから約5カ月半後の8月21日である。JVNの公表日も2026年3月4日と記録されており、情報自体は春先から存在していたことになる。
国内でJVNやJPCERT/CCの発信を情報源にしている組織にとって、この5カ月半は「知らないまま運用していた期間」になりうる。日本語の脆弱性情報データベースは対策の起点として有用だが、それだけを見ていると発見が遅れる。自社が使っている製品については、ベンダーのアドバイザリを直接購読しておくほうが早い。
シスコの製品セキュリティインシデント対応チーム（PSIRT）は、この脆弱性についての公開情報や悪用の事例は把握していないとしている。発見の経緯も社内のセキュリティテストによるものだ。今のところ、慌てて夜間作業をするような性質の脆弱性ではない。
情報漏えいが起きなくても、業務は止まる
セキュリティの議論は「何が漏れたか」に集まりがちだ。だがCVSSで可用性にしか影響しない脆弱性が、実務では最も痛いこともある。ファイアウォールやIPS（侵入防止システム）、プロキシといった通信経路上の機器は、止まれば通過するはずの通信がすべて止まる。工場のラインも、店舗の決済も、リモートワークの接続も、その一台の向こう側にある。
しかも今回のように、単一のパケットで検査エンジンを再起動させられる場合、攻撃者は繰り返し送り続けることで断続的な通信不安定を引き起こせる可能性がある。原因が特定できないまま「ネットワークが時々おかしい」という状態が続けば、調査には相応の時間がかかる。
対応の優先順位を決めるには、まず自社が三つの条件に該当するかを確認することだ。該当しないと分かれば、それも立派な調査結果になる。該当するなら、回避策で時間を稼ぎつつ、次の計画的なメンテナンス枠で修正版へ上げる。可用性への影響が中心である以上、緊急でサービスを止めてまで対応する必要は薄いが、放置していい理由にもならない。
同じ手口に、自社は備えられていますか？