Ciscoは2026年10月14日、Cisco Secure Email Gateway（旧Email Security Appliance、ESA）の任意ファイル書き込みの脆弱性 CVE-2026-76519 を公表し、すでに悪用されていることを明らかにしました。細工した添付ファイル付きのメールが1通届くだけで、認証なしにroot権限でコマンドを実行されるおそれがあります。この記事では、File ReputationとContent Scanner Toolsの2条件による影響判定、contentscannerstatusでの版確認と再起動不要の更新、system_logsを使った侵害調査、侵害が疑われる場合の再構築までを、運用と実装の目線で整理した解説です。内容は2026年10月23日時点の公開情報にもとづきます。
まとめ：File Reputation有効でCSTが25.3.0.5525未満なら即日更新
CVE-2026-76519 が成立するのは、物理版・仮想版のSecure Email Gatewayで、AMPのFile Reputationがメールポリシーに割り当てられ、かつContent Scanner Tools（CST）が25.3.0.5525より前の版のときです。File Reputationを使っていない機器、Secure Email and Web Manager、Secure Web Applianceは対象外です。
対象なら、CLIのcontentscannerupdateでCSTを25.3.0.5525以降へ上げれば塞がります。AsyncOS本体のアップグレードも再起動も要りません。回避策は公表されていないので、当日中に済ませる作業です。
更新と同じくらい大切なのが、更新前に侵入されていないかの確認です。grep "System Security" system_logsの結果で判定し、痕跡があれば仮想版は作り直し、物理版はCisco TACへ連絡します。メールゲートウェイを含む入口機器をまとめて点検したい場合は、脆弱性診断・セキュリティ診断で露出と版を棚卸しすると抜けが出にくくなります。
CVE-2026-76519の中身：添付ファイル処理のパストラバーサルとroot実行
Secure Email Gatewayは、社外から届くメールを受けて迷惑メール判定やマルウェア検査をかけ、社内のメールサーバーへ渡す中継機器です。今回の欠陥は、その検査の中でもAMP（Advanced Malware Protection）が添付ファイルを扱う部分にありました。
CWE-23の相対パストラバーサルとCVSS 9.8を構成する評価の内訳
Ciscoのアドバイザリ cisco-sa-esa-afw-zqYJkjxpによれば、原因はFile Reputationが有効なときの添付ファイルの不適切な処理です。攻撃者が細工した添付ファイルを含むメールを対象機器経由で送ると、基盤OS上の任意のファイルを書き込め、root権限でのコマンド実行に至る可能性があります。弱点の分類はCWE-23（相対パストラバーサル）で、ファイル名に含まれる ../ のような相対表記を処理側が無害化せず、想定外のディレクトリへ書き込んでしまう型です。同じ型の別製品の事例はColdFusionのパストラバーサル脆弱性CVE-2024-53961で扱っています。
CVSS v3.1の基本値は9.8で、ベクトルは AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H です。ネットワーク越しに、認証なし、利用者の操作なしで成立します。メールゲートウェイは添付ファイルを開く人がいなくても自分で解析するため、UI:N（利用者の操作不要）は、まさにこの解析動作に当てはまる評価です。各指標の読み方はCVSSv3の計算式とスコアの目安で確認できます。
9月の強化リリースから10月の悪用公表とKEV登録までの時系列
修正そのものは、公表の1か月前に強化リリースとして出ていました。ここが今回の分かりにくいところです。
| 日付（2026年） | 出来事 | 出典 |
|---|---|---|
| 9月14日 | 15.5.5-014・16.5.0-780公開 | Cisco |
| 9月14日 | 別件CVE-2026-76461（SQLi）を公表 | Cisco |
| 10月14日 | CVE-2026-76519を公表・悪用を確認 | Cisco |
| 10月14日 | KEVに登録（対応期限10月17日） | CISA |
9月の強化リリースのアドバイザリは10月14日に1.1版へ更新され、悪用が確認された2件の個別アドバイザリを参照する形になりました。発見は社内のセキュリティ検査によるもので、Cisco PSIRTが悪用を把握したのは10月です。CISAのKEVカタログでは名称が「Relative Path Traversal Vulnerability」となっており、対応期限は登録から3日でした。KEVの要求事項はBOD 26-04のフォレンジック初期調査にも触れており、その位置づけはBOD 26-04の是正期限の決まり方で解説しています。
9月のSQLインジェクションCVE-2026-76461と修正経路が違う理由
同じ製品で、9月にも悪用済みの脆弱性が公表されています。2件は手口も直し方も違うため、9月に対応を済ませた環境ほど確認が必要です。
| 項目 | CVE-2026-76461 | CVE-2026-76519 |
|---|---|---|
| 種別 | SQLインジェクション（CWE-89） | 相対パストラバーサル（CWE-23） |
| 成立条件 | 設定に関係なく対象 | File Reputation有効が条件 |
| 16.0系の修正 | 16.0.4-302 | 修正版へ移行（CSTでも修正） |
| 痕跡の確認先 | mail_logs | system_logs |
CVE-2026-76461のアドバイザリは、16.0系に16.0.4-302という修正版を示していました。一方でCVE-2026-76519の表では、16.0系は「修正版へ移行」とだけ書かれています。9月に16.0.4-302へ上げて終わりにした環境は、CSTの版を別に確かめないと今回の対象に残っている可能性があります。CVE-2026-76519の修正はCSTのパッケージとしても配布されており、サポート中のすべてのAsyncOSに届く経路があるのはこのためです。
影響範囲の切り分け：File Reputation・CST・AsyncOS版の3条件
影響の有無は、製品の種類、File Reputationの設定、CSTの版の3つで決まります。AsyncOSの版だけを見て判断すると、見落としと過剰対応の両方が起きます。
物理・仮想SEGが対象でCloud GatewayとSEWM・SWAが外れる理由
対象は、オンプレミスで動かす物理アプライアンスと仮想アプライアンスのSecure Email Gatewayです。Secure Email and Web Manager（旧SMA）とSecure Web Appliance（旧WSA）は、Ciscoが影響なしと確認しています。
クラウドで提供されるCisco Secure Email Cloud Gatewayは、利用者側の対応は不要とされています。修正済みのCSTが通常の更新手順の中ですでに展開されているためです。ただしCiscoは、侵害の兆候が見つかったCloudの利用者には個別に連絡済みとしています。連絡を受けた場合は、認証情報と暗号資材の更新が必要です。「Cloudだから何もしなくてよい」と言えるのは、連絡が来ていない場合に限ります。
GUIでFile Reputationの有効化とメールポリシー割り当てを確かめる手順
File Reputationが有効かどうかは、Web管理画面で確認します。受信側だけでは送信側の設定を確認できないため、両方のメールポリシーを確認する必要があります。
- Web管理画面で「Mail Policies > Incoming Mail Policies」を開き、各ポリシーの「Advanced Malware Protection」列を選ぶ。
- ポリシーごとに「Enable File Reputation」にチェックが入っているかを見る。
- 「Mail Policies > Outgoing Mail Policies」でも同じ確認をする。
- 1つでもチェックが入っていれば、その機器はCSTの版確認へ進む。
既定ポリシーでは無効でも、特定部署向けに作った個別ポリシーだけで有効にしている例があります。ポリシーを1つずつ開いて確かめ、結果を機器名と一緒に記録しておくと、後の侵害調査の範囲決めにも使えます。
contentscannerstatusで版を確認し25.3.0.5525へ上げる手順
File Reputationが有効な機器では、次にCSTの版を確認し、古ければ更新します。いずれもCLIで数分の作業です。
contentscannerstatusの出力から脆弱なCSTの版番号を読み取る見方
アドバイザリが示す確認コマンドはcontentscannerstatusです。次は脆弱な版での出力例として、アドバイザリに掲載されているものです。
cisco-esa> contentscannerstatus
Component Version Last Updated
Content Scanner Tools 25.2.0.5427.15.5.001 Never updated
見るのはVersion列の先頭4つの数字です。この例では25.2.0.5427で、修正の入った25.3.0.5525より前なので対象になります。修正版との比較に使うのは、この先頭4つの数字です。Last Updatedが「Never updated」と出る機器は一度も更新が入っていない表示なので、後述の自動更新の設定もあわせて見直します。
contentscannerupdateの手動更新と自動更新設定で再起動なしに塞ぐ方法
手動で更新するには、CLIでcontentscannerupdateを実行します。
cisco-esa> contentscannerupdate
Requesting check for new Content Scanner updates.
cisco-esa> contentscannerstatus
更新要求のあと、もう一度contentscannerstatusでVersion列が25.3.0.5525以降になったことを確かめます。アドバイザリによれば、この更新にソフトウェアのアップグレードや再起動は要りません。メール配送を止めずに作業できるので、保守時間を待つ理由はありません。
今後の更新を自動化するには、Web管理画面の「Security Services > Service Updates」で「Edit Update Settings」を開き、「Automatic Updates」にチェックを入れて送信し、画面右上の「Commit Changes」で確定します。Commitを忘れると設定は反映されません。
CSAFのJSONで影響版の一覧を取り込み自社の版と照合するスクリプト
機器が多い場合は、Ciscoが公開している機械可読のアドバイザリ（CSAF形式のJSON）を読み、資産台帳のAsyncOS版と突き合わせると漏れを防げます。次のPythonは標準ライブラリだけで動きます。
import json
import sys
import urllib.request
CSAF_URL = ("https://sec.cloudapps.cisco.com/security/center/content/"
"CiscoSecurityAdvisory/cisco-sa-esa-afw-zqYJkjxp/csaf/"
"cisco-sa-esa-afw-zqYJkjxp.json")
def product_names(node, names):
# product_tree を再帰的にたどり、product_id と版名の対応表を作る
for branch in node.get("branches", []):
product = branch.get("product")
if product:
names[product["product_id"]] = branch["name"]
product_names(branch, names)
return names
req = urllib.request.Request(CSAF_URL, headers={"User-Agent": "Mozilla/5.0"})
csaf = json.load(urllib.request.urlopen(req, timeout=30))
names = product_names(csaf["product_tree"], {})
status = csaf["vulnerabilities"][0]["product_status"]
affected = {names[pid] for pid in status["known_affected"] if pid in names}
print("影響版の数:", len(affected))
for version in sys.argv[1:]:
hit = "影響版一覧に該当" if version in affected else "一覧に無し（CSTの版も確認）"
print(version, hit)
python csaf_check.py 15.5.4-012 16.0.4-302 16.5.0-780 のように版を並べて実行します。2026年10月23日時点の取得では、影響版として13.0.0-392から16.0.4-016までの23版が並び、15.5.4-012は該当、16.0.4-302と16.5.0-780は一覧にありませんでした。ただし一覧に無いことは安全の証明ではありません。脆弱性の条件はCSTの版で決まるため、照合の結果にかかわらずcontentscannerstatusの確認は全台で行います。
system_logsのSystem Security行で侵害の痕跡を判定する調査手順
CSTを上げても、更新前に書き込まれたファイルや仕込まれた仕組みは消えません。悪用が確認済みである以上、対象だった機器は痕跡の確認までを1セットにします。
grep “System Security”で出る3種類のメッセージと次の対応
アドバイザリが示す確認は、各機器のCLIで grep "System Security" system_logs を実行することです。クラスタ構成なら全メンバーで実行します。出力に現れるメッセージで次の対応が決まります。
| メッセージに含まれる語句 | 意味 | 次の対応 |
|---|---|---|
| Suspected compromise | 侵害の疑い | 復旧手順へ |
| did not complete | 検査が未完了 | Cisco TACへ連絡 |
| No compromise | 痕跡なし | 修正版へ更新 |
実際の行は「System Security: Suspected compromise indicator was found. Contact TAC for further recommendations.」のように、語句の前後に定型文が付いた形で出力されます。
3つ目の「痕跡なし」でも、CSTやAsyncOSが古ければ更新は必要です。2つ目の「未完了」を痕跡なしと読み替えないでください。判定できていない状態なので、TACの指示を待つ扱いになります。
ログ消去を前提にファイアウォールと外部ログで突き合わせる範囲
root権限を取られた機器では、攻撃者がログを消したり書き換えたりできます。アドバイザリでも、ネットワークやファイアウォールのログとの突き合わせが推奨事項です。機器の外に転送・保管しておいたログが、ここで初めて役に立ちます。
ログの転送先サーバーにsystem_logsやmail_logsを集めている場合は、9月のCVE-2026-76461の確認と合わせて一度に検索できます。次はローテーション済みの圧縮ファイルも含めて数える例です（パスは転送先の保存場所に合わせて変えます）。
# CVE-2026-76519：System Security の判定行を機器ごとのファイルから抜き出す
zgrep -H "System Security" /var/log/esa/*/system_logs*
# CVE-2026-76461：mail_logs に不審なSQL文が無いかを調べる（1件でもあれば要調査）
zgrep -i -c "COPY.*TO PROGRAM" /var/log/esa/*/mail_logs*
2つ目のパターンはCVE-2026-76461のアドバイザリが示しているものです。あわせて、ファイアウォールのログで、ゲートウェイから社外への見慣れない通信や、管理インターフェースへの想定外の接続元が無いかを確認します。syslogを外部へ転送し改ざんされにくい形で残す設計はLogstorageのsyslog TLS転送の設定例が参考になります。
侵害が疑われるSEGの復旧：仮想版の再構築と物理版のTAC連絡の判断
痕跡が出た場合の動き方は、物理版と仮想版で分かれます。どちらも、その場でアップグレードして終わりにしないことが共通の原則です。
仮想アプライアンスを保全してから新VMで作り直す5段階の手順
仮想版でアップグレードを先に行うと、侵害されたインスタンスのフォレンジック情報とログが失われるとアドバイザリは警告しています。順序は次のとおりで、1は他のすべての作業より前に行います。
- 社内のインシデント対応手順に沿って、ディスクとログを保全する。
- 修正済みの版で新しい仮想マシンを展開する。
- 以前の設定ファイルを読み込まず、設定を作り直す。
- 機器に入っていた認証情報と証明書などの暗号資材を更新する。
- 入れ替え後も、異常な動作がないかを監視し続ける。
3の「設定ファイルを読み込まない」が手間のかかる部分です。旧設定に攻撃者の仕込みが残っている可能性を排除するためで、ポリシーや辞書を画面から入れ直す作業が必要です。保全の進め方や外部へ依頼する判断はフォレンジック調査の流れと依頼先の選び方で整理しています。物理版はCisco TACへ連絡し、調査を早めるためにリモートアクセスを有効にしておくよう求められています。
クラスタのSSH鍵と証明書・認証情報を入れ替える範囲の決め方
クラスタ構成では、メンバー間の認証にSSHの鍵ペアが使われています。1台から秘密鍵を抜かれると、他のメンバーへ侵害が広がりかねません。Ciscoが、侵害された機器を1台でも含むクラスタは全メンバーを安全な構成に戻すよう強く勧めています。
入れ替えの範囲は、痕跡の有無で線を引きます。痕跡があった機器と同じクラスタのメンバー全台、そこに入っていた管理者アカウント、LDAPやSAML連携の資格情報、TLS証明書は入れ替え対象です。一方、File Reputationを使っておらず構成条件に当たらなかった機器や、ログを外部で確認して痕跡が無かった単独機まで全資材を入れ替えるのは過剰です。作業の重さに見合う根拠がありません。
CST更新だけで済ませてよい構成とAsyncOS 16.5.0-780へ移すべき構成
CVE-2026-76519だけを見れば、CSTを25.3.0.5525以降へ上げれば閉じられます。痕跡が無く、AsyncOSがすでに15.5.5-014か16.5.0-780に上がっている機器は、CSTの更新で作業を終えてかまいません。
16.5.0-780への移行を勧めるのは、AsyncOSが15.5.5-014より前、または16.0系のまま残っている機器です。9月の強化リリースには、今回の2件以外にもCVSS 9.8の脆弱性が複数まとめて直されており、CSTだけでは塞がりません。Ciscoも16.5より前の版から16.5.0-780への移行を強く推奨しています。メール中継の停止を伴う作業になるため、冗長構成ならクラスタの片側ずつ進める手順です。こうした入口機器の版と露出を案件をまたいで点検する進め方や費用の目安は脆弱性診断の進め方と外注時の判断基準で解説しています。入口機器の別製品での同種の対応はBIG-IPの脆弱性CVE-2026-94127の確認コマンドと侵害調査も参考になります。
Cisco SEGのCVE-2026-76519対応でよく受ける質問と実務的な回答
CVE-2026-76519の対応を進める際に出てきやすい疑問に、公開されている一次情報の範囲で答えます。
AsyncOSを16.5.0-780に上げればCSTの確認は不要ですか？
確認は残しておくべきです。16.5.0-780はCVE-2026-76519の修正版として示されていますが、判定条件はCSTの版で書かれています。アップグレード後にcontentscannerstatusを1回実行し、Version列が25.3.0.5525以降であることを記録しておけば、監査や後日の問い合わせにもそのまま使えます。手間は数十秒です。
File Reputationを無効にすれば暫定の回避策になりますか？
Ciscoは回避策なしとしており、File Reputationの無効化を緩和策としては案内していません。影響条件から外れるのは事実ですが、添付ファイルのマルウェア検査が弱まる副作用があります。CSTの更新は再起動不要で数分で終わるため、検査を止めるより更新を先に済ませるほうが筋のよい判断です。
Cisco Secure Email Cloud Gatewayを使っている場合は何をすべきですか？
アドバイザリでは、修正済みのCSTがすでに展開されており、利用者の対応は不要という案内です。ただし、Ciscoは侵害の兆候が見つかった利用者に直接連絡しています。連絡を受けた場合に必要なのは、認証情報と暗号資材の更新、管理画面へのアクセス制限です。CLIを使えない利用者はsystem_logsの確認ができない場合がある点も明記されています。
9月にCVE-2026-76461の対応を済ませていれば今回は対象外ですか？
対象外とは限りません。9月の修正版15.5.5-014や16.5.0-780まで上げていれば今回も修正済みですが、16.0系で16.0.4-302にとどめた環境は、CVE-2026-76519の表では「修正版へ移行」の扱いです。CSTの版を確認し、25.3.0.5525より前ならcontentscannerupdateを実行してください。痕跡の確認先も、9月はmail_logs、今回はsystem_logsと異なります。
JPCERT/CCの注意喚起は出ていますか？
2026年10月23日時点で、本件を対象とするJPCERT/CCの注意喚起は出ていません。9月のCVE-2026-76461にはJPCERT/CCの注意喚起が出ていたため、同じ扱いを待っている担当者もいるかもしれません。国内の注意喚起の有無で対応の優先度を決めるのは不適切です。CISAがKEVに登録し対応期限を3日と定めたこと、Ciscoが悪用を確認していることのほうが判断の根拠になります。続報で状況が変わる可能性があるため、Ciscoのアドバイザリの改訂履歴も定期的に確認してください。
関連記事
- 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：脆弱性が公表から修正に至る流れの基礎を確認できます。
- CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化：CVE-2026-76519のような識別子とCWE・NVDの関係を整理しています。
- VPN 脆弱性：機器の版確認コマンドとKEV照合スクリプト・パッチと移行の判断【2026年10月】：入口機器の版をKEVと照合する考え方をVPN機器で解説しています。
- Fortinetの脆弱性まとめ｜FortiGateの悪用済みCVE一覧と影響確認・修正版・回避策【2026年10月】：悪用済みの脆弱性が続く入口機器での確認手順の比較に使えます。
- CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説：単発の緊急対応から、露出を継続的に管理する運用へ移す考え方です。
