メールゲートウェイ（Cisco Secure Email Gateway）の脆弱性 CVE-2026-76519 について、Cisco PSIRT は 2026年10月に実際の悪用を把握したと公表しました。Cisco がアドバイザリを公開したのは 2026年10月14日 16:00 GMT（日本時間では 10月15日の午前1時）です（出典は記事の末尾にまとめています）。深刻度は Critical、CVSS 基本値は 9.8 で、回避策はありません。そこでこの記事では、メールゲートウェイを運用する情シス担当者が何を確認し、何をすればよいかを、公式アドバイザリに書かれたことだけをもとに整理します。速報として書いており、僕の提案は、そう明記します。
メールゲートウェイの脆弱性: 結論は「修正済みリリースへ移行。Content Scanner Tools の更新でも修正が届く」
先に結論を整理します。
| 観点 | 公式アドバイザリの記述 |
|---|---|
| 識別子 | CVE-2026-76519、Critical、CVSS 基本値 9.8、CWE-23 |
| 内容 | Cisco Secure Email Gateway の Advanced Malware Protection（AMP）機能の脆弱性。認証不要のリモートの攻撃者が、基盤 OS 上に任意のファイルを書き込める可能性がある |
| 悪用 | 2026年10月に Cisco PSIRT が、実際に悪用されていることを把握した |
| 影響を受ける条件 | 物理・仮想の Cisco Secure Email Gateway で、脆弱なリリースの Cisco AsyncOS を実行し、かつ次の両方に当てはまる場合 |
| 回避策 | ない（There are no workarounds） |
| 修正 | Cisco は修正済みリリースへのアップグレードを強く推奨している。16.5 より前のリリースは 16.5.0-780 への移行を強く推奨。修正は Content Scanner Tools 25.3.0.5525 以降にも含まれ、その更新にはソフトウェアのアップグレードも再起動も不要 |
メールゲートウェイが影響を受ける 2 つの条件
影響を受ける条件の「両方」とは、次の 2 つです。
- ファイルレピュテーションサービス（Cisco AMP の一部）が有効で、メールポリシーに割り当てられている
- Content Scanner Tools のバージョンが 25.3.0.5525 より前
つまり、メールゲートウェイの管理者がまず見るのは、自分の装置がこの 2 つの条件に当てはまるかどうかです。
何が起きたか: メールゲートウェイは細工した添付ファイル付きのメールが入口になる
原因は、ファイルレピュテーションサービスが有効なときの、メールの添付ファイルの不適切な処理です。攻撃者が細工した添付ファイル付きのメールを、影響を受ける装置経由で送ると、悪用される可能性があります。成功すると、任意のファイルの書き込みと、基盤 OS 上での root 権限のコマンド実行につながる可能性がある、と公式は書いています。なお、この脆弱性は、Cisco の内部のセキュリティスキャン中に見つかったものです。
背景として、同じ Secure Email Gateway では 2026年9月14日にも、SQL インジェクションの脆弱性（CVE-2026-76461、CVSS 9.8）のアドバイザリが公開されています。こちらも、Cisco PSIRT は 2026年9月に悪用を把握したと書いています。ただし、今回は別の脆弱性です。今回の悪用と 9月の悪用が、同一の攻撃者や同一の攻撃かどうかは、公式には書かれていません（記載なし）。
影響を受けるのは誰か: メールゲートウェイの物理・仮想と、2 つの条件
製品ごとの扱い
まず、公式の記述をそのまま整理します。
| 製品・構成 | 公式の扱い |
|---|---|
| Cisco Secure Email Gateway（物理・仮想）で、脆弱なリリースの AsyncOS を実行し、上の 2 つの条件を両方満たす | 影響を受ける |
| Secure Email and Web Manager | 影響を受けないと Cisco が確認 |
| Secure Web Appliance | 影響を受けないと Cisco が確認 |
| Cisco Secure Email Cloud Gateway の利用者 | 対応不要。Cisco が環境を保護し、修正版の Content Scanner Tools は標準のアップグレード手順で展開済み |
AsyncOS のリリースと修正リリース
次に、AsyncOS のリリースごとの、最初の修正リリースを見ます。
| AsyncOS のリリース | 最初の修正リリース |
|---|---|
| 15.5 | 15.5.5-014 |
| 16.0 | Migrate to a fixed release（公式の表記。修正リリースの番号はこの表にありません） |
| 16.5 | 16.5.0-780 |
公式は、16.5 より前のリリースを使っている顧客には、16.5.0-780 への移行を強く推奨しています。また、この脆弱性の修正は、Content Scanner Tools のパッケージを更新する形でも、ライセンスのあるサポート対象のすべての AsyncOS リリースに配布される、とも書いています。
Cisco Secure Email Cloud の場合
一方、Cisco Secure Email Cloud では、CLI を使えない管理者は、後述の侵害の痕跡を自分で確認できない場合があります。公式は、悪意のある活動を検知した Cisco Secure Email Cloud の装置の持ち主には、Cisco が直接連絡した、と書いています。
連絡を受けた顧客について、Cisco は、可能なら認証情報と、装置に入っている暗号関連の資材を更新して、装置を安全な構成に戻すことを強く推奨しています。さらに、装置へのアクセスを制限し、堅牢なアクセス制御の仕組みを実装することも強く推奨しています。
自分の環境が対象か: メールゲートウェイで確認する 2 点
公式が示す確認方法は、次の 2 つです。
1. ファイルレピュテーションが有効か
- 管理用の Web インターフェイスに接続する
- Mail Policies > Incoming Mail Policies > Advanced Malware Protection、または Mail Policies > Outgoing Mail Policies > Advanced Malware Protection を選ぶ
- メールポリシーを選び、Enable File Reputation のチェックボックスを見る。チェックが入っていれば有効
2. Content Scanner Tools のバージョン
CLI で contentscannerstatus を実行します。たとえば公式は、脆弱なバージョンの例として、次のような出力を示しています。
cisco-esa> contentscannerstatus
Component Version Last Updated
Content Scanner Tools 25.2.0.5427.15.5.001 Never updated
メールゲートウェイの情シス担当者は何をすればよいか
1. 修正済みリリースへの移行と、Content Scanner Tools の更新
まず、Cisco は修正済みのソフトウェアへのアップグレードを強く推奨しています。16.5 より前のリリースを実行しているメールゲートウェイは、16.5.0-780 への移行が強く推奨されています。
また、修正は Content Scanner Tools のパッケージでも配布され、25.3.0.5525 以降に含まれます。この更新に、ソフトウェアのアップグレードも製品の再起動も必要ありません。公式の整理は次のとおりです。
| 状況 | 公式の案内 |
|---|---|
| 自動更新を有効にしている | 更新が適用されれば、何もする必要はない |
| 自動更新を無効にしている | 手動で更新する。CLI で contentscannerupdate を実行する |
手動更新の例として、公式は contentscannerupdate を実行すると「Requesting check for new Content Scanner updates.」と表示される例を示しています。そして、現在のバージョンの確認方法は、上の contentscannerstatus です。
補足: メールゲートウェイの自動更新を有効にする手順
自動更新を有効にする手順も、公式に載っています。
- Security Services > Service Updates を選ぶ
- Edit Update Settings をクリックする
- Automatic Updates のチェックボックスをオンにする
- Submit をクリックする
- 画面右上の Commit Changes を選び、確認の画面でも Commit Changes をクリックする
2. メールゲートウェイのログで侵害の痕跡を確認する
Cisco が悪用を把握している以上、更新だけで終わらせず、侵害されていないかも見ます。公式の手順は、CLI で次のコマンドを実行してログを見ることです。なお、クラスターの場合は、クラスターの各装置のログを確認します。
grep "System Security" system_logs
ログのメッセージごとの推奨対応
出力に含まれる可能性のある 3 つのメッセージと、公式の推奨対応は次のとおりです。
| ログのメッセージ | 公式の推奨対応 |
|---|---|
| System Security: Suspected compromise indicator was found. Contact TAC for further recommendations. | 侵害を検知。アドバイザリの Recommendations の手順に従う |
| System Security: Security scan did not complete. Contact TAC for further recommendations. | Cisco TAC（Technical Assistance Center）に連絡する |
| System Security: No compromise indicator was found. | 侵害は検知されなかった。該当するなら、修正版にアップグレードする |
3. 装置の外のログも突き合わせる
ここで注意したいのは、公式の注記です。悪用に成功すると、攻撃者は root 権限でコマンドを実行できる可能性があり、そのため悪用の証拠や侵害の痕跡を消したり隠したりすることがある、と書かれています。そのため Cisco は、影響を受けた装置の外にあるネットワークログやファイアウォールログも突き合わせるよう、強く推奨しています。たとえば、装置から外部 IP アドレスへの不審なアップロードや、悪意のある IP アドレスからのダウンロードです。
お米の袋に穴が開いていたと分かったら、穴を塞ぐだけでなく、中身が無事かも見ますよね。今回の更新と侵害確認は、その両方をやる話だと僕は読みました。
4. 侵害が疑われるメールゲートウェイの対応
公式は、構成ごとに推奨を分けています。
| 構成 | 公式の推奨 |
|---|---|
| オンプレミスの物理アプライアンス | Cisco TAC に連絡する。調査を早めるため、対象の装置でリモートアクセスを有効にしておく |
| オンプレミスの仮想アプライアンス | 可能なら、次の手順で安全な構成に戻すことを強く推奨 |
| 侵害が疑われないが、影響を受けるリリースを実行している装置 | 修正版へのアップグレードを強く推奨 |
仮想アプライアンスの手順
仮想アプライアンスの手順のうち、公式が順序を明記しているのは、フォレンジック情報の記録を、どの手順より前に行う点です。
- インシデント対応の方針に沿って、フォレンジック情報を記録する。公式は、以降のどの手順に進む前にもフォレンジック情報を記録するよう、Important として強調しています。侵害された装置のアップグレードは、フォレンジックデータとログを破壊する、とも書いています
- 修正版のリリースを実行する、新しい仮想マシン（VM）を展開する
- 以前の設定ファイルをインポートせずに、製品の構成を作り直す
- 認証情報と、装置に入っている暗号関連の資材を更新する
- システムの異常な挙動の監視を続ける
ただし、仮想アプライアンスを元に戻せない場合は、Cisco TAC に連絡するよう、公式は書いています。
5. クラスターは、侵害された装置が 1 台でもあれば全メンバー
メールゲートウェイはクラスターを組めます。クラスターのメンバー間の認証には SSH 鍵ペアを使っています。そして公式は、悪用に成功すると、侵害された装置の上にある、その通信に使う SSH 秘密鍵にアクセスされうると書いています。その鍵へのアクセスが、攻撃者による他のメンバーの侵害につながる可能性もあります。
このため Cisco は、侵害された装置を少なくとも 1 台含むクラスターは、全メンバーを安全な構成に戻すよう、強く推奨しています。
6. 一般の推奨事項も確認する
また公式は、この脆弱性への対応とは別に、メールゲートウェイの一般的なハードニングも挙げています。主なものは次のとおりです。
- 装置を最新の Cisco AsyncOS にする
- 装置へのインターネットからのアクセスを防ぐ。インターネットからのアクセスが必要なら、既知の信頼できるホストだけに制限する
- メール機能と管理機能を、別のネットワークインターフェイスに分ける
公式には書かれていないこと
ここまでは公式の記述です。一方、以下は、公式には書かれていません。
| 項目 | 状況 |
|---|---|
| 攻撃者の特定、被害の規模や件数 | 記載なし |
| 日本国内の利用者への個別の影響 | アドバイザリに日本向けの記載なし |
ここから先は、公式の内容ではなく、僕の提案です。公式には書かれていません。
- 更新の前後に
contentscannerstatusの出力を取り、時刻とともに残しておく。「いつ修正版になったか」を後から説明しやすくなるため - 「自動更新を無効にしている」メールゲートウェイが、自社にあるかを棚卸しする。公式は、自動更新を無効にしている顧客は手動で更新するよう書いているため
まとめ: メールゲートウェイは、まず対象かどうかを確認する
- Cisco は 2026年10月14日 16:00 GMT に、Cisco Secure Email Gateway の脆弱性 CVE-2026-76519（Critical、CVSS 基本値 9.8）を公開し、2026年10月に実際の悪用を把握したと書いている
- 影響を受けるのは、物理・仮想の Cisco Secure Email Gateway で、ファイルレピュテーションが有効かつ Content Scanner Tools が 25.3.0.5525 より前の場合。回避策はない
- Cisco は修正済みリリースへのアップグレードを強く推奨しており、16.5 より前なら 16.5.0-780 への移行を強く推奨している。修正は Content Scanner Tools 25.3.0.5525 以降にも含まれ、その更新にはソフトウェアのアップグレードも再起動も不要。自動更新を無効にしているなら、
contentscannerupdateで手動更新する grep "System Security" system_logsで侵害の痕跡を確認する（クラスターは各装置）。さらに、装置の外のネットワークログとファイアウォールログも突き合わせる- 仮想アプライアンスの侵害が疑われるときは、フォレンジック情報の記録が先。クラスターは、侵害された装置が 1 台でもあれば全メンバーを安全な構成に戻すよう、Cisco が強く推奨している
まず自分のメールゲートウェイのバージョンと設定を見て、対象かどうかをはっきりさせる。それが最初の一手です。
参考
- Cisco Secure Email Gateway Arbitrary File Write Vulnerability（Cisco Security Advisory、2026年10月14日 16:00 GMT）
- Cisco Secure Email Gateway SQL Injection Vulnerability（Cisco Security Advisory、2026年9月14日 16:00 GMT）
- 当ブログの Tech カテゴリー
ITもごはんも、腹八分目が長続きのコツ！
コメント