Zimbra脆弱性が悪用中、SNMP有効なら未認証RCE

自社サーバでグループウェア「Zimbra Collaboration Suite（ZCS）」を運用している組織は、今すぐバージョンを確認してください。SNMP監視を有効にしている環境では、認証なしで、細工したSMTP通信を送りつけるだけでサーバ上の任意のOSコマンドを実行される脆弱性（CVE-2026-73570）が悪用されています。

修正版の 10.1.20 は2026年7月20日に公開済みです。つまりパッチは1か月以上前から出ており、遅れているのは適用側という構図です。ポーランドのCERT Polskaが2026年8月17日に悪用を確認したと公表し、米CISAも8月21日に悪用が確認された脆弱性カタログ（KEV）へ追加しました。

この記事でわかること

  • Zimbra Collaboration Suiteとは何をする製品で、どこで動いているのか
  • CVE-2026-73570の中身と、「該当する環境」を分けている3つの条件
  • なぜ「SMTPで届く攻撃」が、Web脆弱性より止めにくいのか
  • 自社が該当するかを判定する具体的なコマンドと、侵害確認の手順
  • 10.1系以外（10.0系・9系・8.8.15系）を使っている場合に起きる問題

Zimbra Collaboration Suiteとは何者か

Zimbra Collaboration Suite（ZCS）とは、メール・カレンダー・連絡先・ファイル共有をまとめて提供する、自社サーバに設置して使う統合グループウェアです。Microsoft 365 や Google Workspace のようなSaaSではなく、自分たちでサーバを立て、自分たちで更新する製品だと考えてください。

使われる場面は「メールを自社の手元に置きたい」組織です。大学・自治体・官公庁・ISP・中小企業などで、ライセンス費用を抑えたい、あるいは外部クラウドにメールを預けたくないという理由から選ばれてきました。CISAのKEVカタログでは、ベンダー名が開発元の系譜を反映して「Synacor」と記載されています。

ここが「自分ごと」に変わるポイントです。Zimbraは、自社で導入した記憶がなくても使っていることがあります。レンタルサーバやホスティング事業者が提供する「Webメール」の中身がZimbraであるケースがあるためです。契約書に製品名が書かれていないこともあるので、次のいずれかで確認してください。

  • Webメールのログイン画面のURLに /zimbra/ が含まれていないか
  • ログイン画面やヘルプに「Zimbra」の表記がないか
  • サーバに入れるなら、zimbraユーザーで zmcontrol -v を実行してバージョンが返るか

何が起きたのか

CVE-2026-73570は、ZimbraのSNMP監視コンポーネントにおけるOSコマンドインジェクション（CWE-78）です。NVDの説明では、オプションの zimbra-snmp パッケージが導入されSNMP通知が有効な環境において、認証されていない攻撃者が細工したSMTPリクエストを送ることで、zimbraユーザー権限で任意のOSコマンドを実行できるとされています。CVSS v3.1 の基本値は 8.9（HIGH）です。

時系列で見ると、この件の「間の悪さ」がはっきりします。

日付 できごと
2026年6月26日 ZimbraがSNMP監視コンポーネントの脆弱性を最初に開示（この時点では暫定的な対処のみ）
2026年7月20日 ZCS 10.1.20 を公開。恒久修正が入る
2026年8月13日 NVDでCVE-2026-73570が公開（CVSS v3.1 8.9）
2026年8月17日 CERT Polska（ポーランド）が「実際に悪用されている」と注意喚起
2026年8月21日 米CISAがKEVカタログへ追加。米連邦機関の対応期限は8月24日

恒久修正から悪用の公表まで、およそ1か月です。修正版が出て1か月後、そしてCVE番号がNVDに載ったわずか4日後に、各国のCERTが「すでに悪用されている」と公表したという順序に注意してください。CVE番号の公開やスコアの確定を待ってから動く運用では、この種の案件は間に合いません。

該当する環境を分ける3つの条件

この脆弱性は、Zimbraを使っていれば必ず該当するわけではありません。公開情報を整理すると、次の3条件がそろった環境が対象です。

  • オプションの zimbra-snmp パッケージが導入されている
  • localconfigの snmp_notify でSNMPトラップ通知が有効になっている
  • swatchdog サービスが動いている（既定で有効）

注意したいのは3つ目です。swatchdogは既定で動くため、実質的な分かれ目は「SNMP監視を入れて有効にしたかどうか」になります。監視ツールとの連携でSNMPトラップを飛ばす設定は、運用チームが数年前に入れたまま誰も覚えていない、という典型的な設定項目です。「使っていないつもり」が最も危ないパターンだと考えてください。

なぜ「SMTPで届く攻撃」は止めにくいのでしょうか

メールサーバにとって、SMTPの受信口は閉じられないからです。これがこの脆弱性の一番厄介な点です。

管理画面やWebクライアントの脆弱性であれば、「管理画面をインターネットに出さない」「WAFやリバースプロキシで前段に置く」といった構成上の緩和が効きます。しかしCVE-2026-73570の入口はSMTP、つまり外部からメールを受け取るための、その組織が閉じるわけにいかない経路です。境界で守る発想が、この一本については働きません。

もう一点、公開されている侵害確認の手順から仕組みを逆算すると、この脆弱性の性質が見えてきます。CERT Polskaが確認を推奨しているのは /var/log/zimbra.log に残る「Service status change: ＜不審な文字列＞ changed from stopped to running」という形のログです。swatchdogはこのログファイルを監視してSNMPトラップを送る仕組みですから、ログに書き込まれた文字列が、そのまま外部コマンドの一部として扱われていると読めます。攻撃者の入力がログを経由してシェルに届く、いわば遠回りの経路です。

この構造は、入力値の検証をHTTPの入口だけで考えている限り見つかりません。ログは「書き出すもの」であって「実行されるもの」ではない、という思い込みが、そのまま穴になっています。同じ発想の落とし穴は、ログを機械的に読んで自動処理する仕組み全般に潜んでいます。

自社は該当するのか（判定手順）

サーバにログインできるなら、zimbraユーザーで次を順に確認するのが早道です。

  1. バージョン：zmcontrol -v … 10.1.20 未満なら修正が入っていません
  2. SNMPパッケージの有無：RHEL系は rpm -qa | grep zimbra-snmp、Debian/Ubuntu系は dpkg -l | grep zimbra-snmp
  3. SNMP通知の設定：zmlocalconfig snmp_notify … 有効になっていないか
  4. サービスの稼働：zmcontrol status … snmp が Running になっていないか

1〜4のすべてを確認する時間がないなら、まず1だけでも構いません。10.1.20以降であれば、条件の確認は不要です。条件の精査に時間をかけるより、更新できるものを先に更新するほうが速いという判断は、この件では十分に合理的です。

10.1系以外を使っている場合の問題

ここが実務では一番重い論点になります。NVDは影響範囲を「10.1.20より前のすべてのバージョン」としていますが、Zimbraが提示している修正先は 10.1.20 のみです。10.0系・9系・8.8.15系にはサポート期間が終了しているものがあり、そこに向けた個別の修正版は示されていません。

Zimbraのセキュリティアドバイザリ一覧のページにも、「掲載しているのはサポート対象バージョンのみであり、サポート外の古いバージョンも同じ脆弱性を抱えていることが多いため、速やかにサポート対象へ上げること」という趣旨の注記が置かれています。古い系列を使っている組織にとって、この件の対応は「パッチ適用」ではなく「バージョンアップ計画」になります。

すぐに上げられない場合に検討できるのは、SNMPトラップ通知を無効にする、あるいは zimbra-snmp を外すという方向です。ただしこれは監視の停止を意味しますので、監視側の運用と必ずセットで判断してください。影響を確認せずに監視を止めると、別の障害に気づけなくなります。

侵害の有無をどう確認するか

すでに悪用が確認されている以上、「更新したから終わり」にはできません。CERT Polskaは、次の2点の確認を推奨しています。

  • /var/log/zimbra.log に「Service status change: ＜不審な文字列＞ changed from stopped to running」（または running から stopped）という形のログがないか
  • zimbraユーザーが過去30日以内に作成したファイルが、/opt/zimbra/jetty/webapps/、/opt/zimbra/jetty_base/webapps/、/tmp/ 配下に無いか

jetty配下のwebappsは、Webシェルを置かれやすい場所です。ここに身に覚えのないファイルがあれば、単なる更新漏れではなくインシデントとしての初動に切り替える必要があります。

なお米CISAのKEV掲載時の要求事項では、BOD 26-04に基づく更新の適用に加えて「フォレンジック・トリアージ要件」への準拠が求められています。更新するだけでなく、侵害されていないかを調べるところまでが求められているという点は、日本の組織にとっても参考になります。悪用が確認された脆弱性への対応で、ログの保全と確認を後回しにしないでください。

現場目線：一次情報の窓口が食い違っている

今回、確認していて素直に困った点を書いておきます。Zimbra公式の情報が、ページによって内容がそろっていません。

執筆時点（2026年8月23日）で、公式Wikiの「Security Center」ページに掲載されている最新の情報は 10.1.19（2026年7月7日公開）で、10.1.20 の記載がありません。一方、同じWikiの「Zimbra Security Advisories」ページにはCVE-2026-73570が掲載され、修正版として 10.1.20 が示されています。ただしその行のCVSSスコア欄は「TBD」、Zimbra独自の深刻度評価欄は「-」のままです。KEVに載るほど悪用されている脆弱性が、ベンダーの一覧では深刻度未設定で並んでいる状態です。

これは「ベンダーが悪い」で終わらせるより、自分たちの情報収集の設計を見直す材料として使うべきだと考えています。製品ごとに、どのページ・どのRSS・どのメーリングリストが「最も早く・最も確実に」更新されるかは違います。Zimbraの場合、公式Wikiはブログ（blog.zimbra.com）とアドバイザリ一覧の両方をRSSで購読できる旨を案内しています。窓口を一つに絞ると、今回のように取りこぼします。

もうひとつ率直に言えば、「深刻度が付いていないから優先度が低い」と読んでしまう危うさもあります。ベンダーの評価が空欄でも、KEVに載っているかどうか、パッチ公開から時間が経っているかどうかで、優先度は動きます。パッチ公開からKEV登録まで39日かかった事例のように、スコアと実際の危険度は必ずしも同じ速度では動きません。

情シスはどうすべきか

やることは3つに絞れます。

  1. Zimbraの所在確認：自社運用のZimbraだけでなく、ホスティング事業者経由のWebメールも含めて洗い出す
  2. 10.1.20以降への更新：条件の精査より更新を優先する。古い系列ならバージョンアップの計画に落とす
  3. 侵害確認：ログとjetty配下のファイルを確認し、痕跡があればインシデント対応へ

体制面の整備については、自前でチェックリストを作るより公的機関の資料に沿うほうが確実です。組織の規模に応じて、IPAの中小企業の情報セキュリティ対策ガイドラインが、資産の把握と脆弱性対応の位置づけを整理する出発点になります。「侵害されていた場合に誰がどう動くか」を事前に確かめておきたい場合は、IPAのセキュリティインシデント対応 机上演習教材が使えます。今回のような「更新は終わったが侵害確認が残っている」状況こそ、演習の題材として現実的です。

あわせて、利用者側への地道な周知も効きます。Webメールの挙動がおかしい、覚えのない転送設定がある、といった違和感を上げてもらえる関係を作っておくことは、監視の網の目を細かくすることと同じ意味を持ちます。

まとめ

  • CVE-2026-73570は、ZimbraのSNMP監視経由で未認証のOSコマンド実行を許す脆弱性で、すでに悪用が確認されています。入口がSMTPのため、境界での緩和が効きにくい点が厄介です。
  • 修正版 10.1.20 は2026年7月20日公開済みです。該当条件（zimbra-snmp・snmp_notify・swatchdog）の精査に時間をかけるより、まずバージョンを確認して更新するのが早道です。
  • 更新だけで終わらせず、侵害確認まで行ってください。/var/log/zimbra.log の不審な「Service status change」と、jetty配下・/tmp配下に置かれた身に覚えのないファイルが確認の起点になります。

同じ週にはTrueConf Serverの脆弱性2件も悪用確認としてKEVに追加されており、SharePointの認証バイパスも同時期に対象となっています。自社が持っている「外部に露出したサーバ製品」の一覧を、この機会に見直しておくことをおすすめします。

出典

タイトルとURLをコピーしました