CVE-2026-76461｜Cisco ESA の影響判定と侵害確認

はじめに

Cisco Secure Email Gateway（旧称 Cisco Email Security Appliance、略称 ESA）に、SQL インジェクションの脆弱性 CVE-2026-76461 が公表されました。Cisco のアドバイザリ初版は 2026 年 9 月 14 日 16:00 GMT、日本時間では 9 月 15 日 1:00 の公開です。CVSS 3.1 のベーススコアは 9.8（Critical）で、公表の時点ですでに実際の悪用が確認されています。

メール基盤の運用担当者にとって難しいのは、公式情報が「対象判定」「更新先」「侵害確認」「導入形態ごとの対応」に分散していることです。修正版の一覧を見つけても、自環境がどの経路で更新できるのか、ログに何も出なかったときにどこまで安心してよいのか、という判断までは埋まりません。

結論として、物理・仮想の Cisco Secure Email Gateway は構成にかかわらず対象であり、回避策は公表されていません。取るべき行動は、導入形態と AsyncOS のバージョンを確認したうえで修正版へ更新することと、更新とは別に悪用の痕跡を確認することの 2 つです。痕跡が見つかった場合は、通常の更新作業を続ける前に、証拠保全と対応調整へ切り替える判断が必要になります。

CVE-2026-76461 の概要と影響範囲

本脆弱性は、AsyncOS のメール解析処理における入力検証の不備に起因します。攻撃者は細工したメールを送信するだけで、認証なしに影響を受ける装置へ到達できます。

メール処理が攻撃経路になる

Cisco の説明では、悪意のある SQL 文を含むメールが影響を受ける装置を経由することで、任意の SQL 文が実行され、基盤 OS 上での root 権限のコマンド実行につながる可能性があります。CWE は CWE-89（SQL インジェクション）に分類されています。

ここで重要なのは、管理画面をインターネットへ公開していないことは、本脆弱性の影響有無の判断材料になりません。攻撃の入口は管理インターフェースではなくメールの処理経路であるため、メールを受信して処理している限り経路は存在します。管理アクセスの制限やハードニングは運用上の基本ですが、本脆弱性を解消する回避策ではありません。Cisco も回避策は存在しないと明記しています。

影響を受ける製品と受けない製品

Cisco は、物理・仮想の Cisco Secure Email Gateway が装置の構成にかかわらず影響を受けるとしています。一方で、次の 2 製品は本脆弱性の影響を受けないと明記されています。

• Cisco Secure Email and Web Manager（旧称 Content Security Management Appliance、SMA）
• Cisco Secure Web Appliance

この非対象の記載は、あくまで CVE-2026-76461 についての判断です。同じ装置が別のアドバイザリの対象になる可能性は否定されていないため、非対象製品を今後も更新不要と読み替えないよう注意してください（編集上の補足）。

悪用状況と CISA KEV への登録

Cisco PSIRT は 2026 年 9 月に本脆弱性の悪用を確認したとしています。脆弱性自体は Cisco TAC のサポートケース対応の過程で発見されたものです。公表と同日に CISA の Known Exploited Vulnerabilities カタログへも登録されています。

KEV の対応期限は米国の連邦民間行政機関を対象とした義務であり、日本国内の組織へ直接適用されるものではありません。登録日と期限は CISA の Known Exploited Vulnerabilities Catalog で確認できます。国内環境での緊急性は、Cisco PSIRT が実際の悪用を確認しているという事実を根拠に判断することになります。

国内では JPCERT/CC が 2026 年 9 月 15 日付で注意喚起（JPCERT-AT-2026-0027）を公開しています。あわせて、同製品では過去に別の脆弱性 CVE-2025-20393 を悪用した侵害事案が国内で発生していることを確認したとも記載されています。これは CVE-2026-76461 とは別の脆弱性に関する過去の事案であり、本脆弱性の国内での悪用が確認されたという意味ではありません。製品として国内で狙われた実績があるという文脈で参照してください。

AsyncOS の修正版と更新先の判断

Cisco は修正済みリリースを公開しています。ただし、表に記載された「最初の修正版」と「Cisco が推奨する移行先」は別の情報であり、さらに自環境からその版へ到達できる経路があるかは表だけでは判断できません。

修正版一覧と推奨移行先

Cisco はアドバイザリの脚注で、15.5 系と 16.0 系についても 16.5.0-780 への移行を強く推奨しています。つまり 15.5.5-014 や 16.0.4-302 は本脆弱性を解消する最小限の版であって、Cisco が案内する移行先は 16.5.0-780 です。運用上の理由で系統を維持する場合でも、この差は認識したうえで判断してください。修正版表と脚注の原文は Cisco Security Advisory で確認できます。

修正版表だけで更新経路を判断しない

古い AsyncOS を運用している環境では、修正版へ 1 回の操作で到達できるとは限りません。Cisco のアップグレード関連ドキュメントでは、バージョンによっては最新リリースへ到達するために複数回のアップグレードが必要になるとしたうえで、アップグレードパスの確認は Cisco TAC へ問い合わせるよう案内されています。

参考: ESA での AsyncOS アップグレードの検証およびトラブルシューティング（Cisco、Document ID 118547）
「最新リリースに到達するために複数のアップグレードが必要です」
https://www.cisco.com/c/ja_jp/support/docs/security/email-security-appliance/118547-technote-esa-00.html

同ドキュメントでは、更新前に確認する項目として次が挙げられています。修正版へ更新できるかどうかは、これらを踏まえて判断することになります。

ハードウェアの状態（物理装置）

RAID を搭載する物理装置での確認事項です。System Status の出力で RAID ステータスが READY または OPTIMAL であること。DEGRADED の場合はアップグレードを開始せず、RMA について Cisco TAC へ問い合わせるよう案内されています。仮想装置では、この項目の代わりに基盤側のストレージ状態を各自の運用手順で確認することになります。

既存アラートの有無

GUI の System Administration > Alerts、または CLI の displayalerts で、ネットワーク接続や DNS の重大なエラーが残っていないこと。

構成の種別

スタンドアロンかクラスターかを先に特定すること。クラスター構成の場合は手順が異なります。

更新サーバーへの到達性

装置から更新サーバーへ向かう通信についての条件です。DNS が機能しており、ポート 80 および 443 で更新サーバーへ到達できること、かつその更新用の通信にパケット検査が挟まれていないことが挙げられています。インターネット通信全体で検査を解除するという意味ではありません。アップグレードとアップデートの URL は Akamai の CDN 上でホストされるため、FQDN でファイアウォールを制御している環境では、装置とファイアウォールが同じ DNS サーバーを参照しているかもあわせて確認します。

ライセンス形態

AsyncOS 15.5.x 以降では Cisco Smart Software Licensing の使用が必須とされています。これより前の版から更新する場合は、ライセンス移行の準備が前提になります。

SMA との互換性

Secure Email and Web Manager で集中管理している環境では、更新前に互換性マトリクスを確認すること。

更新の実施方法

Cisco はアドバイザリ内で、Web 管理インターフェースと CLI の両方の手順を示しています。GUI では System Administration > System Upgrade を開き、Upgrade Options から Download and Install を選択します。続いて更新先のリリースを選び、Upgrade Preparation で該当するオプションを選択し、Proceed で開始します。

CLI から実行する場合は、次のコマンドを起点に進めます。

upgrade

表示された選択肢で DOWNLOADINSTALL を指定し、更新先のリリースを選択したうえで、以降のオプションを選択していきます。GUI・CLI のいずれの方法でも、更新の完了後に装置が再起動します。

更新は再起動を伴うため、メール処理の停止時間を見込んだ作業計画が必要です。停止時間中の配送をどこで受けるかは環境ごとに異なるため、既存の保守手順に合わせて事前に確認しておくことをおすすめします。

悪用の痕跡を確認する方法と限界

Cisco は Indicators of Compromise として、mail_logs を確認して不審な SQL 文を探す方法を案内しています。ただしこの確認は、見つかった場合と見つからなかった場合で意味の重みが大きく異なります。

mail_logs を確認する

Cisco がアドバイザリに掲載している検知例は次の形です。

cisco-esa> grep -i "COPY.*TO PROGRAM" [IronPort Text Mail Logs Log name - Default: mail_logs]

角括弧の部分は、そのまま入力する文字列ではなく、対象とするログ名を指定するためのプレースホルダーです。IronPort Text Mail Logs のログ名は既定で mail_logs であり、環境でログ名を変更している場合はその名称を指定します。出力に該当するエントリが存在する場合、悪意のある活動を示している可能性があるとされています。

クラスター構成では、各装置のログを個別に確認する必要があります。1 台で該当がなかったことは、クラスター全体で該当がなかったことを意味しません。

この確認は CLI へのアクセスが前提です。Cisco Secure Email Cloud では CLI アクセスを持たない管理者が独自に確認できない場合があるとされており、その場合は Cisco からの連絡の有無が判断の起点になります。

痕跡が見つからないことを未侵害の証明としない

Cisco は、掲載している検知例が網羅的ではないと明記しています。加えて、悪用に成功した攻撃者は root 権限でコマンドを実行できるため、痕跡そのものが削除または隠蔽されている可能性があるとしています。

参考: Cisco Secure Email Gateway SQL Injection Vulnerability（Cisco Security Advisory）
“indicators of compromise may be removed or hidden by the threat actors”
（侵害の痕跡が攻撃者によって削除または隠蔽されている可能性があります）
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-esa-inj-2bLVGmhX

この前提を踏まえると、確認結果は次のように整理できます。

該当するエントリが見つかった場合

悪用の試行や侵害が疑われる兆候として扱い、証拠保全と追加調査へ進みます。検知例への一致そのものは、攻撃が成功したかどうかまでを示すものではありません。導入形態によって次の行動が変わるため、後述の比較表を参照してください。

該当するエントリが見つからない場合

未侵害が確定したことにはなりません。検知例が網羅的でないこと、痕跡が消されている可能性があることの両方が残るため、装置外のログとの照合まで含めて判断します。

装置外のログと照合する

Cisco は、影響を受けた装置の外側にあるネットワークログとファイアウォールログを相互に確認するよう強く推奨しています。着目点として挙げられているのは、対象装置から外部 IP アドレスへ向けた想定外のアップロードと、悪意のある IP アドレスからのダウンロードです。装置内のログだけでは攻撃者の操作によって視界が欠ける可能性があるため、改変されにくい外部の記録を突き合わせる意図です。

JPCERT/CC の注意喚起も同じ方向を示しています。

参考: JPCERT-AT-2026-0027（JPCERT/CC）
「周辺機器などのネットワークログとも突合して調査することが推奨されています」
https://www.jpcert.or.jp/at/2026/at260027.html

装置内と装置外の両方で該当がなかった場合も、確認した範囲と期間を記録として残しておくと、後から範囲を広げて調べ直すときの起点になります（編集上の提案）。すでに修正版で運用している環境でも、更新前に影響を受けるバージョンを稼働させていた期間があれば、その期間を含めて確認の対象にします。

導入形態別の対応と作業完了の確認

Cisco の Recommendations は、オンプレミスの物理装置、オンプレミスの仮想装置、Cisco Secure Email Cloud の 3 つに分けて記載されています。侵害が疑われるかどうかで取るべき行動が変わるため、両方の軸で整理します。

導入形態で分かれる対応

仮想装置で注意したいのは順序です。Cisco は、新しいインスタンスを展開すると設定とログが失われるため、再構築に着手する前にフォレンジック情報を記録するよう明記しています。証拠を残さないまま作り直すと、影響範囲の特定が後から行えなくなります。

Cloud については、更新済みであることと追加対応が不要であることは別です。Cisco 側の更新・調査が完了していても、痕跡が確認されて連絡を受けた利用者には、認証情報と暗号関連情報の更新という利用者側の作業が残ります。また、Cisco から連絡がないことは、その環境が侵害されていないことの根拠にはなりません。連絡は痕跡が確認された利用者へ向けたものであり、確認できなかった範囲までを保証する通知ではないためです（編集上の判断）。

判断と作業の順序

判断と作業の順序は次のとおりです。侵害の疑いの有無によって、通常の更新とインシデント対応へ分岐します。

更新・復旧後に確認すること

Cisco のアップグレード関連ドキュメントでは、更新後の確認として次が案内されています。ここは公式が示す手順です。

• 各装置で status を実行し、Online であることを確認する
• displayalerts を実行し、更新後に発生したアラートを確認する
• クラスター構成では clustercheck で不整合が表示されないこと、connstatus で全装置が接続済みと表示されることを確認する
• tail mail_logs でメールのリアルタイム処理を監視する
• Secure Email and Web Manager で管理している環境では、Management Appliance > Centralized Services > Security Appliances で全サービスの稼働と、各装置の Message Tracking Data Availability が OK であることを確認する

上記はいずれも Cisco のテクニカルノート（Document ID 118547） に記載された確認項目です。これに加えて、業務側の影響確認を行っておくと、更新後の問い合わせに対する切り分けが早くなります。次は編集上の提案であり、Cisco が必須手順として示しているものではありません。

• 内部から外部、外部から内部の双方向でテストメールの送受信を確認する
• 運用しているコンテンツフィルター、メッセージフィルター、DLP などのポリシーが意図どおり適用されることを確認する
• 隔離の動作と、隔離メールの解放が従来どおり行えることを確認する

最後に区別しておきたいのが、修正版への更新は脆弱性を解消する作業であり、侵害が発生していた場合の復旧とは別であるという点です。更新後の装置が修正版で動作していても、更新前に侵入されていた場合の認証情報の扱いや、装置外へ持ち出された情報の評価は、更新では解決しません。

まとめ

CVE-2026-76461 は、メールの処理経路そのものが攻撃面になる脆弱性であり、回避策は公表されていません。対応の判断は、修正版への更新という一本の作業ではなく、更新と侵害確認という 2 つの線で進めることになります。痕跡が確認されたときに通常作業へ戻らない設計にしておくことが、この脆弱性への備えの中心です。

• 物理と仮想の Secure Email Gateway が構成を問わず対象
• 管理画面の公開有無では影響を判定できない攻撃経路
• 最初の修正版と Cisco の推奨移行先 16.5.0-780 は別の情報
• 古い版からの更新は経路を Cisco TAC へ確認することが前提
• mail_logs に該当がなくても未侵害の証明にはならない
• 仮想装置では再構築より先にフォレンジック情報を保全する
• Cloud でも連絡を受けた場合は認証情報と暗号関連情報を更新

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