Sophos UTMに認証不要root実行の脆弱性｜9.724更新後も手動パッチが必要

Sophosは2026年10月28日、Sophos UTMのメール保護機能に認証不要の遠隔コード実行脆弱性CVE-2026-118633を公表しました。スキャンを有効にしたメールプロキシが対象で、攻撃が成功するとroot権限で任意のコマンドを実行されます。UTMをSMTPゲートウェイとして残している運用担当者は、管理画面だけでなく、メール配送を受け付ける経路を確認してください。

対応は9.724への更新だけでは終わりません。Sophos公式のパッチ手順は、9.724を前提に別途RPMを手動導入し、導入後のファイルを照合して対象コンポーネントを再起動するよう求めています。EOL後の製品であり、通常の自動更新待ちを完了条件にしないことが今回の要点です。以下は10月30日未明に確認した公式資料に基づく解説で、実機への適用・攻撃再現を実施した結果ではありません。

メール配送へ接続できる相手が攻撃者になり得る

公式勧告は問題をパストラバーサルと説明しています。メールプロキシをスキャンありで使用している場合、認証していない遠隔の相手が数分間にわたり攻撃を繰り返し、競合状態に勝つことでroot権限のコマンド実行へ至るとしています。単にメールが滞るDoSではなく、装置上での高権限実行が影響です。

ここで必要な接続は管理者のログインではありません。公式KBAは、SMTPゲートウェイとして使う機器へメールを届けるために接続できる相手が悪用できると説明しています。Web管理画面をインターネットへ公開していないことだけで、影響なしとは判定できません。受信メールがUTMを通るか、スキャンを使うか、どこからSMTP接続が届くかを組み合わせます。

Webサイトや業務アプリからの通知メールも、同じゲートウェイを通していれば配送確認の対象です。SMTPが外部メールサービスへ完全に移行済みなら、その事実を構成図と実際の配送経路で確かめます。機器の設置場所や製品名だけでなく、現在動かしているEmail Protection機能が採否の判断材料です。

全バージョン対象と9.724の意味を区別する

Sophos CNAが公表した公式CVEレコードはPUBLISHEDで、SG UTMの9.724までを影響範囲に挙げています。勧告もUTMの全バージョンを対象としています。CVSS v4.0の基本値は9.2、Criticalです。同じレコードのCVSS v3.1は8.1であり、評価方式が異なる二つの数字を混ぜないようにします。

KBAの最初の作業は、未更新ならUTMを9.724へ上げることです。これは手動パッチの適用前提で、9.724そのものを今回の修正版と読むことはできません。「9.724稼働中」と「CVE-2026-118633の修正RPMを導入済み」を台帳で別欄にすると、保守会社へ依頼するときも取り違えを防げます。

Sophos Firewallへの移行も公式の是正策ですが、名前の似た製品への通常更新と、UTMでの今回の手動RPM導入は別の作業です。対象装置、現在版、SMTPの役割、手動パッチの導入結果をまず特定し、移行予定だけを理由に現行の露出を放置しないようにします。

勧告のWorkaround欄はNoです。メール検査を止めれば公式に安全な状態になる、という案内はありません。業務継続のための経路変更が必要なら、別の保護されたメール基盤へ移す判断と、脆弱性を修正する作業を分けて管理してください。

手動適用は取得物と導入後の二段階で照合する

以下のコマンドと期待値はKBA-000049692の確認内容です。作業前に公式ページを開き、手順が更新されていないか確認してください。対象装置の設定バックアップ、コンソール等の復旧経路、メール配送への影響を保守担当と確認する部分は本サイトの運用提案です。

遠隔接続の場合はloginuserでUTMシェルへ入り、機器へ直接キーボードを接続するコンソールの場合はrootでログインするようKBAは案内しています。認証情報を記事の例へ埋め込む必要はありません。シェル操作を許可された担当者が、対象装置を確認してから進めます。

RPMはUTM上で取得するか、別のコンピューターへダウンロードしてscpで転送できます。公式が案内するファイル名は次のとおりです。別名のファイルや第三者サイトの再配布物へ置き換えず、KBAの配布リンクから取得します。

wget https://download.astaro.com/UTM/v9/patch/ep-cssd-64-9.70-29.g7f03cc7.x86_64.rpm
sha256sum ep-cssd-64-9.70-29.g7f03cc7.x86_64.rpm

RPMの期待SHA-256は以下です。転送した場合も、インストールする装置上のファイルで照合してください。不一致ならインストールを止め、取得元、転送結果、ファイル名を確認します。

2f1b5a9cc62b887ddc56d74c42be96b8a98d07ebc7fdac1705347ec52778d3dc

一致を確認してから、公式が指定するRPMコマンドを実行します。--forceは今回のKBAに記載された操作であり、別のパッケージでエラーを押し切る一般手順として流用しないでください。KBAは準備とep-cssd-64の導入が100％になる出力例を示しています。

sudo rpm -Uvh --force ep-cssd-64-9.70-29.g7f03cc7.x86_64.rpm

導入後は、ダウンロードしたRPMではなく、インストール先の/usr/bin/cssdを照合します。RPMのチェックは取得物の一致、こちらは装置へ反映されたコンポーネントの一致を確認する工程です。同じハッシュを使い回すものではありません。

sha256sum /usr/bin/cssd

導入後の/usr/bin/cssdに対する期待SHA-256は次の値です。

eb0e7c60f6607df2f1a0448167b13022eec2b80c47c7bef124230a585d64a409

最後に影響するコンポーネントを再起動します。ファイルを置き換えたことだけで、稼働中の処理へ修正が反映されたとは判断しません。KBAで指定されているのはcssdの再起動で、装置全体の再起動を必須とする案内ではありません。

sudo /var/mdw/scripts/cssd restart

再起動後は配送とスキャンを別々に確認する

ここからは本サイトの確認案です。作業前に決めたテスト用アドレスを使い、外部からの受信、内部アプリからの送信、バックエンドのメールサーバーまでの配送を確かめます。通常のメッセージが届いたことと、スキャンを有効な状態で運用できていることを別に確認します。脆弱性を狙うメールを本番へ送って試す必要はありません。

受信だけでなく送信も調べる理由は、UTMが中継メールのコンテンツ検査も行えるためです。管理ガイドのRelayingには、認証済みまたはホスト単位のリレーで送るメッセージも、設定により悪意ある内容の検査対象になるとあります。問い合わせフォーム、注文通知、パスワード再設定など、UTMを通る自社アプリの代表経路を選んで確認します。

配送できないときは、RPM導入の成否、cssd再起動の結果、SMTP接続、後段サーバーへの中継を分けて調べます。ファイルのハッシュが一致しない状態で正常配送だけを根拠に完了しない一方、配送失敗だけで修正RPMの不具合とも断定しません。作業前後の時刻と結果を揃えると、既存の障害との切り分けができます。

Sophosの中継設定ガイドは、Allowed hosts/networksにAnyを指定するとオープンリレーになる危険を警告しています。更新後にメールを通すため、許可元を無制限へ広げる対処は避けてください。今回のKBAも、リレー権限を緩めることを適用手順として求めていません。

証明書のUp2DateとSMTP修正は別の更新

10月28日のSophos公式説明は、UTMが6月30日のEOLを過ぎていること、今回のEmail Protection脆弱性には緊急対応が必要なことを示しています。同じ説明にはeMudhra関連の証明書更新もありますが、こちらは先週Up2Dateで配布した別の対処です。自動Up2Dateが有効だからSMTPの修正も済んだ、とは判断できません。

証明書更新では、emSign Root TLS CA - G3とAAA Certificate Servicesの二つのルートCAを削除したとしています。これらだけへ連鎖する証明書は、Web ProtectionでのTLS復号、セキュアなメールプロトコル、Up2Date等の証明書検証機能で信頼されなくなります。メールのTLSエラーがあった場合は、SMTP修正の適用結果と証明書の信頼経路を別に調査します。

同社は、UTMファームウェア自体はPHPを使わず、PHP2Shellの直接の影響を受けないとも説明しています。一方、PHPを使うライセンス管理サイトMyUTMは恒久的にオフラインとする方針です。MyUTMからライセンスをダウンロード・管理できないため、ライセンスファイルのコピーが必要な場合はCustomer Care and Supportへ問い合わせるよう案内しています。

つまり今回の対応票には、SMTPの手動RPM、証明書更新、ライセンス入手、サポート対象のSophos Firewallへの移行を別々に残すのが適切です。一つの更新成功や別サイトの停止を、ほかの対策の完了証拠に置き換えないようにします。

悪用状況と過去の侵害は確認できた範囲で扱う

Sophosは外部研究者Sam Pizzeyからバグバウンティ経由で責任ある報告を受けたと説明しています。確認した勧告には実環境での悪用確認や被害組織、侵害を特定できるIOCは記載されていません。悪用なしと断定する根拠にはせず、認証不要でroot権限へ至る条件と公式の緊急適用要請に基づいて対応します。

パッチ後のファイルハッシュが一致しても、それは過去に侵害されていなかった証明ではありません。未適用期間に不審な挙動や設定変更があれば、保存されている装置・メール側の記録を保全し、保守担当やインシデント対応担当へつなぎます。公式資料にないログ文字列や攻撃検知コマンドを作って安全判定することは避けます。

今回の完了記録には、対象装置、9.724の確認、RPMの取得元とハッシュ、導入結果、/usr/bin/cssdのハッシュ、再起動時刻、配送とスキャンの確認、残る移行作業を含めます。機器を複数持つ場合も、ダウンロードが一度成功したことではなく、各装置で導入後の値と稼働状態を確認してください。

関連記事

緊急パッチを安全に適用する実務ランブックでは、対象資産、適用後の検証、障害時の判断を整理しています。Sophos固有のファイルと操作は今回のKBAを優先してください。