CVE-2026-73570：Zimbraの脆弱性が実際に悪用中 ― 攻撃の仕組みと対処法を徹底解説
CVE-2026-73570はZimbraの脆弱性で、実際に悪用が確認されています。CISAが定めた対応期限と攻撃の仕組みを詳しく解説します。
CVE-2026-73570：Zimbraの脆弱性が実際に悪用中 ― 攻撃の仕組みと対処法を徹底解説
もし貴社がExchangeの代わりに Zimbra Collaboration Suite をメールプラットフォームとして使っているなら、今日中に確認すべきことがあります。CISAは8月21日、CVE-2026-73570 をKnown Exploited Vulnerabilities（KEV）カタログに追加し、米連邦文民行政機関（FCEB）向けの対応期限を 8月24日 に設定しました ― わずか3日間で、通常より明らかに短い猶予です。
この記事は「脆弱性があるので今すぐパッチを」という単純な速報ではありません。攻撃の仕組みを実際に理解することが、自社の環境がどの程度・どのように危険にさらされているかを判断する唯一の方法だからです。
何が起きたのか
| |
|---|
| CVE | CVE-2026-73570 |
| 製品 | Zimbra Collaboration Suite（ZCS） |
| 脆弱性の種類 | OSコマンドインジェクション（CWE-78） |
| CVSS 3.1 | 8.9（HIGH） |
| CISA KEV登録日 | 2026年8月21日 |
| 修正バージョン | 10.1.20 |
| 影響を受けるバージョン | 10.1.20未満すべて（このCVEについて、Zimbraのアドバイザリーは具体的な下限バージョンを明記していません） |
誤解されやすい点があります。CISAの短い説明では、攻撃者が「巧妙に細工されたSMTPリクエストを送信する」とされており、これだとインターネットに公開されているZimbraメールサーバーすべてが危険にさらされているように読めます。しかし、Zimbra公式のSecurity AdvisoriesとNVDを照らし合わせると、実際の影響範囲はもっと限定的です。
攻撃の仕組み
実際の脆弱性は、オプションパッケージである zimbra-snmp 内の SNMP notification処理 にあります ― すべてのZimbra環境が動かしているコアのメール配送経路ではありません。
サーバーが危険にさらされるのは、次の 3条件すべて が揃っている場合のみです：
zimbra-snmp パッケージがインストールされている（デフォルトではなくオプションコンポーネント）snmp_notify パラメータ経由でSNMP trapが有効化されており、実際に動作しているのは swatchdog サービス ― CERT Polska（ポーランドの国家CERT）のアドバイザリーによれば、zimbra-snmp をインストールすると swatchdog はデフォルトで稼働します。つまり実際に確認すべき変数は snmp_notify の設定であり、別途トグルする項目ではありません- バージョンが10.1.20未満である
条件が揃った場合の攻撃の流れは次の通りです：
- 認証は不要 ― この脆弱性は認証情報を必要とせず（
PR:N）、ユーザーの操作も必要としません（UI:N）。CVEの公式な説明によれば、トリガーとなるのは巧妙に細工された SMTPリクエスト であり、実際に脆弱性が発現するのは受信側でSNMP notificationを処理する段階です。つまりリクエスト自体はSMTP経由で届き、埋め込まれたOSコマンドが、システムが単なる通知値として扱うはずのSNMP notificationのフィールドに流れ込みます。
- Zimbraはその値をサニタイズせずに処理します ― これはCWE-78の典型的なパターンです。外部からの入力をエスケープしたり、パラメータ化されたクエリとして安全に渡したりせず、そのままシェルが解釈するコマンドの一部として連結してしまいます。
- 埋め込まれたコマンドが実際に実行されます。実行権限は
zimbra ユーザーであり、root ではありませんが、それでも全メールボックスの読み取り・改ざん、同ユーザー権限下に保存された設定情報や資格情報の窃取、あるいはネットワーク内での横展開（ラテラルムーブメント）の足がかりとして十分な権限です。
CVSSベクトルの読み方
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L = 8.9 HIGH
| 指標 | 値 | 意味 |
|---|
| Attack Vector | AV:N | ネットワーク経由で攻撃可能 ― ローカルアクセス不要 |
| Attack Complexity | AC:H | 高い ― 特定の設定（zimbra-snmp がインストール済みで snmp_notify が有効）が前提条件であり、無差別スキャンで即座に成立する脆弱性ではない |
| Privileges Required | PR:N | 認証情報不要 |
| User Interaction | UI:N | ユーザー操作不要 |
| Scope | S:C | 影響範囲が脆弱性のあるコンポーネント自体にとどまらない |
| Confidentiality / Integrity | C:H / I:H | 読み取り・改ざんともに全面的に可能 |
| Availability | A:L | 可用性への影響は部分的で、システム全体の停止には至らない |
AC:H は、攻撃の成立に特定の設定（zimbra-snmp がインストール済みで snmp_notify が有効）という前提条件が必要であることを反映しています ― 条件を問わずヒットするたびに刺さるタイプの脆弱性ではなく、SNMP notificationが実際に有効な一部のサーバーだけが対象になります。とはいえ「危険性が低い」わけではありません。CISAのKEV登録は、条件に合致するサーバーが実際に野生（in the wild）で攻撃されていることを確認した上でのものです。
透明性についての補足： Zimbra自身のアドバイザリーは、いまだコードレベルの詳細を公開していません（ZimbraのCVSS Native項目は現時点で「TBD」）。ここで挙げた具体的な仕組み（snmp_notify パラメータ、swatchdog サービス、確認すべきファイルパス）は、ZimbraやNVDではなくCERT Polskaのアドバイザリーによるものです。現在、公開リポジトリにPoCコードが出回り始めています ― これらのコードは信頼できないものとして扱い、自社が所有しないシステムに対して実行しないでください。上記の解説は、CISA・NVD・Zimbra・CERT Polskaが確認済みの内容のみに基づいており、独自のリバースエンジニアリングによるものではありません。
なぜ通常のログ監視では見逃してしまうのか
この種の脆弱性の本当の問題は「脆弱性が存在すること」自体ではなく、気づいたときには手遅れになっている ことです。zimbra ユーザーから生成される不審なプロセス（シェル、外部から何かを取得するcurl/wget、リバースシェルなど）は、メールプラットフォームが生成する膨大なログの中に埋もれがちです。MITRE ATT&CK のテクニックT1059（Command and Scripting Interpreter）へのマッピングや、異常なアウトバウンド通信との相関分析なしにこの兆候を通常のログと見分けるには、それなりの手間がかかります。
zcrLogのThreat Analysis はbehavioral detectionをMITREテクニックT1059（Command and Scripting Interpreter、今回のような不正なコマンド実行が分類されるのと同じテクニックカテゴリ）にマッピングします ― こうした兆候を見つけやすくする一つの方法ですが、パッチ適用や以下のハンティング手順の代わりになるものではありません。
Remediation ― 今すぐできる対処
根本原因への対処（最優先）
- Zimbra Collaboration Suiteを 10.1.20以降 にアップデートする
- アップデートの前後で
zmcontrol -v を実行し、パッチが確実に適用されたことを確認する
すぐにパッチを適用できない場合（緩和策）
- トリガーとなるのは巧妙に細工された SMTPリクエスト ― 正常に稼働しているメールサーバーであれば常に開けておく必要があるのと同じ経路です。したがってSNMP trapポート（UDP 161/162）をファイアウォールで塞いでも、この攻撃経路は塞げません。あのポートはこのCVEが実際に使う経路とは別の種類のアクセスを制御しているだけです
- SNMP監視を実際には利用していないなら、
zimbra-snmp パッケージを無効化または削除する（最低限 snmp_notify だけでも無効化する） ― これがCERT PolskaとZimbra自身の推奨に沿った、脆弱なコードパス自体を取り除く実質的な緩和策です
- SNMP監視が必要で無効化できない場合、信頼できる緩和策はパッチ適用のみです ― ネットワーク層の制御では代替できないため、優先度の高いアップデートとして扱ってください
すでに侵害されていないかの確認（脅威ハンティング）
CERT Polska（このCVE専用のアドバイザリーを公開しているポーランドの国家CERT）は、ベンダーのアドバイザリーより具体的な調査手順を示しています：
/var/log/zimbra.log を確認し、不正なペイロードサービスが起動・停止した形跡がないか調べる- 過去30日間に
zimbra ユーザーが作成したファイルを、特に /opt/zimbra/jetty/webapps/、/opt/zimbra/jetty_base/webapps/、/tmp/ の各パスで確認する ― CERT Polskaは進行中のキャンペーンとの関連でこれらのパスを確認するよう推奨しています
CERT Polska自身の手順に加えて、以下の2点は私たち独自の追加提案です（CERT Polskaのアドバイザリーが直接求めているものではありません）：
zimbra-snmp サービスまたは zimbra ユーザーから、メール/コラボレーションサービスとして想定されない不審な子プロセスが生成されていないか確認するzimbra ユーザーが開始したアウトバウンド接続のログを確認し、見慣れないIPやドメインへの通信がないか調べる
CERT Polskaは8月17日付のアドバイザリー時点で、この脆弱性を悪用する「進行中のキャンペーン」を確認済みと述べています ― CISAがKEVカタログに追加した8月21日より数日早い時点です。アドバイザリー自体はキャンペーンの正確な開始時期までは明記していませんが、その時点ですでに実際の悪用が確認されていたことを踏まえると、貴社の環境がリスク条件に該当し、まだ調査していない場合は、少なくとも8月中旬まで遡って確認することをお勧めします。
セルフチェックリスト
| 条件 | 該当しますか？ |
|---|
| Zimbra Collaboration Suiteが10.1.20未満 | zmcontrol -v で確認 |
zimbra-snmp パッケージがインストール済み | パッケージマネージャーで確認 |
snmp_notify パラメータが有効 | Zimbraの通知設定で確認 |
| SNMP trapポートが一般のインターネットに公開されている | ファイアウォール／セキュリティグループのルールを確認 |
最初の3条件すべてに該当する場合、貴社は実際にリスクのあるグループに含まれており、まずアップデートを優先すべきです。並行して、メールサーバー・ファイアウォール・エンドポイントなど複数のログソースを一つの相関分析ビューにまとめる SIEM があれば、一台ずつ手作業で確認することなく、どのサーバーがリスク条件に当てはまるかを俯瞰できます。関心があれば zcrLogの料金プラン もご覧ください。
お問い合わせ
この脆弱性についてのご質問、または貴社環境におけるZimbraのリスク評価をご希望の場合は、お気軽にご相談ください。無料でご相談いただけます。
情報源： CISA KEV Catalog ・ NVD — CVE-2026-73570 ・ Zimbra Security Advisories ・ CERT Polska