Cisco Systemsは現地時間2026年9月14日、企業向けメールセキュリティ製品「Cisco Secure Email Gateway」に、極めて深刻なSQLインジェクションの脆弱性があるとしてセキュリティアドバイザリを公開した。細工されたメールを1通送りつけるだけで、認証を経ずに機器のOS上で最上位の権限にあたる「root」権限のコマンドを実行されるおそれがある。同社は公開時点ですでに実際の悪用を把握しており、米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）も同じ日にこの脆弱性を「悪用が確認された脆弱性カタログ（KEV）」へ追加した。回避策は提供されていない。
攻撃に必要なのは、メールを送ることだけ
脆弱性は「CVE-2026-76461」。Cisco Secure Email Gatewayで稼働する「Cisco AsyncOS」のメール解析処理に入力値の検証不備があり、悪意あるSQL文を含むメールを処理した際に任意のSQLが実行される。攻撃が成功した場合、影響は任意のSQLの実行にとどまらず、基盤となるOS上でroot権限の任意のコマンドを実行されるところにまで及ぶ。共通脆弱性評価システム「CVSSv3.1」のベーススコアは10点満点中9.8で、重要度は4段階で最も高い「クリティカル」とされている。
この脆弱性が厄介なのは、攻撃の前提条件がほとんど存在しない点にある。管理画面へのアクセスも、認証情報も、内部ネットワークへの足がかりも要らない。攻撃者は脆弱な機器を経由するメールを送るだけでよい。Cisco Secure Email Gateway（旧称：IronPort Email Security Appliance）は、フィッシングやマルウェア、スパム、ビジネスメール詐欺などを検査するために外部から届くメールを処理することがそもそもの役割である。つまり、製品が本来の仕事をしているだけで攻撃が成立してしまう。
影響を受けるのは物理アプライアンスと仮想アプライアンスの双方で、Ciscoは機器の設定内容にかかわらず影響すると明記している。一方、同社は「Cisco Secure Email and Web Manager」と「Cisco Secure Web Appliance」については影響を受けないことを確認したとしている。
発見の経緯は「サポート案件の調査中」だった
Ciscoによれば、この脆弱性は同社テクニカルアシスタンスセンター（TAC）に寄せられたサポートケースの解決過程で見つかった。研究者による事前の届け出でも、社内の定期的な監査でもない。実際に問題が起きた顧客環境を調べる中で、原因として浮かび上がってきたという経緯である。
CISAがKEVカタログへ追加したのもベンダーの公表と同じ9月14日だった。セキュリティ企業のRapid7は、この同日追加を、修正版が提供される前から攻撃に使われる「ゼロデイ」の状態で悪用されていたことを示すものだと指摘している。同社は9月15日時点で、実証コード（PoC）は公開されておらず、攻撃を行っている主体の特定もなされていないとしている。
CISAは米国の連邦行政機関に対し、9月17日までの対応を求めた。求められているのはアップデートの適用だけではなく、侵害を受けていないかの調査も含まれる。
回避策はない。しかも「調べれば分かる」とも限らない
Ciscoは、この脆弱性に対する回避策や緩和策は存在しないと明言している。用意されているのは修正版への移行だけである。修正版は、15.5系以前が「15.5.5-0141」、16.0系が「16.0.4-3021」、16.5系が「16.5.0-780」で、同社は「16.5.0-780」への移行を強く推奨している。Rapid7も、通常のパッチ適用サイクルを待たず緊急対応として更新すべきであり、ネットワーク側の制御や監視だけに頼るべきではないとしている。
侵害を受けたかどうかの確認方法として、Ciscoはメールログ（mail_logs）に不審なSQL文が記録されていないかを確認するよう案内している。検出例として挙げられているのは `COPY.*TO PROGRAM` という文字列を含む行の有無で、これに該当する記録があれば悪意ある活動の可能性があるとする。機器をクラスタ構成で運用している場合は、構成する全機器のログを見る必要がある。
ただしCiscoは、この確認だけで安心してはならないとも付け加えている。攻撃が成功した場合、攻撃者はroot権限を得ているため、悪用の痕跡や侵害指標そのものを消したり隠したりできる立場にある。そのため同社は、影響を受けた機器の外側にあるネットワークログやファイアウォールのログと突き合わせ、当該機器から外部IPアドレスへの想定外のアップロードや、不審なIPアドレスからのダウンロードがなかったかを確認するよう強く推奨している。機器の中を見て何も出てこないことは、侵害がなかったことの証明にはならないという趣旨である。
悪用が疑われる場合の復旧手順も示されている。仮想アプライアンスについては、まず原因究明に必要な証拠データ（フォレンジック情報）を保全したうえで、修正版で新しい仮想マシンを構築し、設定を作り直し、機器に導入されている認証情報と暗号関連の資材をすべて更新し、その後も異常な挙動を監視し続けることを推奨している。物理アプライアンスで悪用が疑われる場合は、Cisco TACへ連絡するよう求めている。
なお、クラウド型の「Cisco Secure Email Cloud」については、Ciscoが全機器を「16.5.0-780」へアップグレード済みだとしている。同社は脅威インテリジェンスの調査を行い、侵害の可能性を示す指標が見つかった顧客には直接連絡したとしている。ただしCLIへのアクセス権を持たない管理者は、前述の侵害指標を自力で確認できない場合があるとも記されている。
守るための機器が、最短の侵入経路になる
境界に置かれたセキュリティ製品が攻撃の入口になる構図は、この1〜2年で繰り返し見てきたものである。VPN装置、ファイアウォール、ファイル転送アプライアンス——いずれも、外部に面していること、組織の通信が集まること、そして高い権限で動いていることが共通していた。メールゲートウェイもその条件をすべて満たしている。
そのうえで今回の事案には、対応の優先順位を考えるうえで見逃せない性質がある。攻撃に管理インターフェースへの到達が要らないため、「管理画面はインターネットに公開していないから大丈夫」という一般的な緩和の考え方が通用しない。メールを受け取れる状態にあること自体が攻撃面になっている以上、製品を止めない限り露出は消えない。だからこそCiscoもRapid7も、緩和ではなく更新を求めている。
もう一点、侵害調査の話も重要である。root権限を取られた機器のログは、その機器自身の証言としては信用できない。これは今回に限った話ではなく、機器の外側に独立したログを持っているかどうかが、有事に「何が起きたか分からない」で終わるかどうかを分ける。攻撃を受けたときに手元に残るものを、平時のうちに設計しておく必要がある。
自社がCisco Secure Email Gatewayを使っているかどうかを確かめることが、最初の一歩になる。使っている場合に見るべきは、稼働中のバージョンと、メールログに残された記録と、機器の外にあるログの3点である。
同じ手口に、自社は備えられていますか？