Cisco Secure Email Gateway、更新済みでも再確認

15.5.5-014へ上げたCisco Secure Email Gatewayは、版番号を見ただけでは修正済みと言えなくなりました。

Ciscoが9月に悪用を把握したCVE-2026-76461について、同社は10月31日に15.5.5-014の修正を改め、11月3日（日本時間では4日未明）に勧告を版1.2へ改訂しました。版番号はそのままで、確認先はCLIのretroscannerstatusです。Retro Remediation Engineが4.0.2以降なら、改めた修正が入っています。

台帳の「15.5.5-014」は、10月31日の前も後も同じ文字です。

版番号が同じまま、修正だけが変わった

CVE-2026-76461はSQLインジェクションの脆弱性で、細工したメールが機器を通るだけで、認証なしにrootでコマンドを実行されるおそれがあります。CVSSは9.8で、回避策はありません。Ciscoは2026年9月に悪用を把握し、米CISAも9月14日にKEVへ加えました。番号の概要はSecPulseのページでも引けますが、修正版と今回の改訂は勧告でご確認ください。

改訂の中身は、修正版の表に付いた1つの注です。

注によると、きっかけは「exploit code that is available online」、つまりオンラインで手に入る攻撃コードについての新しい情報でした。前の修正が破られたとまでは、Ciscoは言っていません。ただ、その情報を受けて修正を差し替えた以上、10月31日より前の15.5.5-014を修正済みのまま扱うのは避けたいところです。

10月のCVE-2026-76519でも、AsyncOSの版とは別に、Content Scanner Toolsの版が分かれ目でした。この製品の台帳には、AsyncOSの版に加えてContent Scanner ToolsとEngineの版、確認日も持たせておくと、次の改訂でも見比べられるでしょう。

編集部は、この改訂は気づきにくいとみています。KEVは改訂の翌日にあたる11月4日の版でも、掲載日が9月14日、連邦機関の期限が9月17日のままで、改訂の手がかりになりません。Ciscoの定例の予告はこれから出す勧告の知らせなので、11月4日の分に今回の改訂はありません。RSSでは日付が11月3日に上がりましたが、題とguidには改訂を示す文字がなく、guidで既読を判断するリーダーなら新着に出ないかもしれません。

影響する会社は、版で分かれる

物理と仮想のSecure Email Gatewayが、設定を問わず対象です。

• 15.5.5-014の機器には、Engineの確認が残ります。これから15.5.5-014へ上げる機器も、上げたあとに同じ確認をします。
• 16.5.0-780の機器は、Engineの版を問わず修正済みです。残るのは侵害の跡の確認だけ。
• 16.0系の修正版は16.0.4-302で、注は付いていません。
• 15.5.5-014より前、16.0.4-302より前、16.5.0-780より前の版は対象で、修正版への更新が要ります。
• Secure Email Cloudは、Ciscoが全台を16.5.0-780へ更新済みで、更新の作業はありません。ただ、侵害の痕跡が見つかってCiscoから連絡を受けた顧客には、認証情報と暗号鍵の更新が強く推奨されています。
• Secure Email and Web ManagerとSecure Web Applianceは、この番号の影響を受けません。ただしManagerは、Ciscoが社内の調査で見つけた脆弱性をまとめたHardening Releaseの対象で、修正版は15.5.5-006と16.5.0-429です。

見るのはEngineの行

retroscannerstatusは表示するだけのコマンドで、部品ごとに版と更新日時が出ます。AsyncOS 15.5.3のCLIリファレンスにある出力例は3行です。

Component Version Last Updated Cloud Retro Remediation Engine 1.0 Never updated Cloud Retro Remediation Config 0.2 06 Apr 2022 18:00 (GMT +00:00) Cloud Retro Client Certificate 1.0.1 06 Apr 2022 18:00 (GMT +00:00)

読むのはEngineの行です。ConfigやCertificateの番号と取り違えないようにします。勧告の呼び名は「Cisco Retro Remediation Engine」で例の表記と少し違うので、15.5.5の画面では行の名前が変わっているかもしれません。

更新の日時も一緒に控えておくと、いつ4.0.2以降になったかを後から追えます。リファレンスによるとこのコマンドはマシンモード専用なので、クラスターは1台ずつ見ることになります。

やっかいなのは、4.0.2に届いていなかった機器です。勧告には、上げる手順も、改めた修正が届く経路も、16.0.4-302にEngineの確認が要るのかも書かれていません。勧告に沿う出口は、Engineの版を問わない16.5.0-780へ移ることです。はっきりしない点は、CiscoのTACや保守の委託先へ聞きます。

AsyncOS 15.5.3のリファレンスにはretroscannerupdateも載っています。ただしこれは勧告が案内する手順ではなく、retroscannerstatusと違って、機器に部品の更新を要求する操作です。編集部の案として試すなら、ログを機器の外へ残したあとに実行し、retroscannerstatusで見直します。4.0.2に上がる保証はありません。

なお、同じリファレンスはこの部品を、URL Retrospectiveサービスとの通信に使うものと説明しています。ただ、この脆弱性は設定を問わず対象なので、URL Retrospectiveを使っていないから関係ないとは決めず、表示された版で判断するのが確実でしょう。

16.5.0-780へは、経路を見てから

Ciscoは16.5より前の機器に16.5.0-780への移行を強く推奨しています。Engineの確認が要らなくなるので、出口としては明快です。

ところが、10月7日付のリリースノートにある移行元の一覧に、15.5.5-014がありません。

並ぶのは20の版で、15.5系は15.5.4-012まで。16.0.4-302は入っています。一覧にないから移れないとまでは言い切れず、逆に同じ節には、載っている経路が取り下げられている場合があるとの断りもあります。

実際に移れるかは、機器の画面で確かめられます。System Administration > System Upgradeの［Upgrade Options］から［Download and Install］へ進み、選べる版に16.5.0-780があるかを見ます。［Proceed］は押さず、なければ保守の日を決める前にTACへ経路を聞きます。

期限の面でも、15.5系に長くはいられません。Ciscoのサポート期間の文書によると、保守リリースの期限は10月30日に過ぎ、脆弱性対応も残り半年を切りました。

16.0系も、16.0.4-302で止めないほうがよさそうです。同じ製品の3つの勧告とサポート期間を並べると、16.0系の欄だけがそろいません。

16.0.4-302で閉じるのは、表の1行目だけ。2行目はContent Scanner Toolsの更新でふさげますが、3行目は移行のほかに道がありません。Hardening Releaseは5つのCVEをまとめた勧告で、最大のCVSSは9.8です。悪用を把握しているのは今回と10月の番号の2件だけだとCiscoは説明しているので、急ぎ方は違っても、編集部は16.0系の行き先を16.5系に置くのが自然とみています。

16.0の古い版なら、一覧のうえでは遠回りも要りません。16.0.4-302へ移れる版は3つに限られますが¹、16.0.1や16.0.2の版は16.5.0-780の一覧に入っています。

侵害の跡は、更新した日で区切らない

上げる前に見るのはログです。KEVのこの項目にも、CISAがフォレンジックのトリアージを求める印があります。Ciscoが例に挙げる確認は次のコマンドで、1行でも出たら悪用やその試みのおそれがあります。ログを検索するだけのコマンドです。

grep -i "COPY.*TO PROGRAM" mail_logs

10月のCVE-2026-76519でsystem_logsを確認した会社も、これは別に見ます。番号ごとに、見るログも探す語も違うからです。

0件でも、安心はできません。Ciscoはこの例を網羅的ではないとしていますし、rootを取られれば跡を消されるおそれもあります。そこでCiscoが強く勧めるのが、機器の外にあるネットワークとファイアウォールのログとの突き合わせです。機器から外部への想定外のアップロードや、不審なIPアドレスからのダウンロードを探します。勧告の関連リンクにはSnortのルール3:67109と3:67110も挙がっているので、Snortを動かしている環境なら検知の履歴も見ておけます。

検索の前に、mail_logsの持ち方を見ておきます。AsyncOS 15.5.3のユーザーガイドによると、取得方法の既定は手動ダウンロードで、ファイルは既定で10個まで、または領域が足りなくなるまでしか残りません。9月の分は、もう機器にないかもしれないのです。

一方、FTPやSCP、syslogへ送る設定のログは、CLIで検索できません。この場合は機器の結果を当てにせず、転送先のサーバーで検索します。mail_logsは既定の名前なので、変えている機器では実際の名前に置き換えます。ログの名前と取得方法はSystem Administration > Log Subscriptionsで見られます。grepはログインしている機器だけが対象なので、クラスターは全台に入って実行します。

期間は、更新した日で切らないでください。Ciscoが悪用を把握した9月より前のログが残っていればそこから、今日までを見ます。15.5.5-014へ上げた日で切ると、改める前の修正で動いていた期間が抜けてしまいます。

疑いが出たら、更新だけでは終わりません。物理の機器はTACへ相談します。リモートアクセスを有効にしておくと調査が早まるとCiscoは案内していて、画面ならHelp and Support > Remote Access、CLIならtechsupportのTUNNELです。

仮想の機器は、先に記録を残してから、修正版の新しいVMを立てて設定を作り直し、認証情報と暗号鍵を替えます。新しいインスタンスを立てると、元の設定とログは消えるからです。その後も監視を続け、作り直せないときはTACへ相談します。

1台でも侵害されていれば、クラスターは全台が対象。機器どうしの認証に使うSSHの秘密鍵を読まれ、ほかの機器へ広がるおそれがあるためです。

CVE-2026-76519の勧告には以前の設定ファイルを読み込まずに作り直すとあり、今回の勧告にはこの断りがありません。どちらの攻撃か切り分けられないなら、読み込まないほうが安全でしょう。

保守の時間を取る前の確認手順

1から3は今日のうちに、4は今週のうちに進めておくと、次に勧告が改まったときも台帳で見分けられます。

1. メール基盤の担当者か委託先に、物理、仮想、Secure Email Cloudのどれを何台使っているかを聞きます。Cloudだけなら、Ciscoから連絡が来ていないかを確認して終わりです。
2. mail_logsの取得方法と、残っている最も古い日付を見ます。ログを機器の外へ保存してから全台でgrepを実行し、同じ期間のファイアウォールのログも機器のIPアドレスで絞って保存します。
3. 全台でversion、retroscannerstatus、contentscannerstatusを実行し、版と更新日時を台帳に写します。どれも表示するだけのコマンドです。15.5.5-014でEngineが4.0.2未満なら、4の移行を急ぎ、TACにも聞きます。
4. System Upgradeの画面で16.5.0-780が選べるかを見て、移行の日を決めます。更新が終わると機器は再起動するので、メールの経路を止める時間を関係部署へ先に伝えます。
5. 跡が見つかった機器は、ここで順番を止めて復旧に切り替えます。

9月や10月に閉じた作業票を開き直すのは、正直なところ気が重いものです。ただ、最初の確認はコマンド1つで終わります。悪用が確認された製品の勧告は、閉じたあとも版番号と最終更新日を見に行くようにすると、今回のような改訂の取りこぼしを減らせます。

今週のほかの製品の更新は、週の図解でご覧いただけます。勧告は11月6日時点の版1.2、KEVは11月4日の版によります。