情報取得日: 2026/08/13／最終確認: 2026/08/22・本ページは公開情報の非公式まとめです
| CVE ID | CVE-2026-73570 |
|---|---|
| 製品 | Zimbra（Synacor） / Zimbra Collaboration Suite (ZCS) 10.1.20 より前（かつ任意パッケージ zimbra-snmp を導入し SNMP 通知を有効にしている場合） |
| CVSS | 8.9（High） CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L |
| 種別 (CWE) | CWE-78 OS コマンドインジェクション |
| 登録／公開日 | 2026/08/13 |
| KEV 期限 | 2026/08/24 まで（米国連邦機関向け目安） |
| 推奨対応 | ベンダーの指示に従って緩和策を適用し、CISA の BOD 26-04（リスクに基づくセキュリティ更新の優先順位付け）および Forensics Triage Requirements に従うこと。緩和策が無い場合はクラウドサービス向けの BOD 26-04 ガイダンスに従うか、製品の利用を停止すること。 |
| 出典 | https://nvd.nist.gov/vuln/detail/CVE-2026-73570 |
Zimbra Collaboration Suite (ZCS) の SNMP 監視コンポーネントに OS コマンドインジェクションがある。NVD の記述によれば、SNMP 通知の処理における入力のサニタイズが不十分で、認証を受けていない攻撃者が細工した SMTP リクエストを送ることで、Zimbra ユーザーの権限で任意の OS コマンドを実行できる。CWE は CWE-78。NVD（Primary）の CVSS 3.1 は 8.9 High で、ベクタは AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L である。CVSS 4.0 は本稿の確認時点（2026-08-22）で NIST による評価が付いていない。注意すべきなのは成立条件である。この欠陥は ZCS の標準構成そのものではなく、任意パッケージである zimbra-snmp を導入し、かつ SNMP 通知を有効にしている場合に成立する。したがって同じバージョンを動かしていても、SNMP を使っていない環境は影響を受けない。逆に言えば、影響の有無はバージョン番号だけでは判定できず、パッケージの導入状況と通知設定を実際に見る必要がある。攻撃の経路が SNMP ではなく SMTP である点も見落としやすい。入力は SMTP で入り、SNMP 通知の処理経路で解釈される。CISA は 2026-08-21 に本件を KEV（悪用が確認された脆弱性カタログ）へ収載し、是正期限を 2026-08-24 に設定した。収載から期限まで3日しかない短い設定で、実際に悪用が観測されていることを示している。ランサムウェアキャンペーンでの使用は KEV 上「不明」として扱われている。ベンダーのアドバイザリは修正内容を『SNMP 通知が有効な場合の SNMP 監視コンポーネントにおけるコマンドインジェクションを修正した』と記載し、修正リリースとして 10.1.20 のみを挙げている。
各ベンダー公式アドバイザリで確認できた事実に基づき整理しています。確認できていない項目は「情報確認中」と明記し、存在しないパッチ番号・バージョンは記載しません。
| 環境 | 対応状況 | 対応方法・備考 |
|---|---|---|
| AWS (ECS/EC2) | 情報確認中 |
ZCS を 10.1.20 以上へ更新する。EC2 上で自前運用している場合、AMI やインスタンスの更新ではなく Zimbra のパッケージ更新が対象になる。
AWS のマネージドサービスに Zimbra は無く、修正対象は利用者が構築した ZCS そのものである。ECS/EKS 上でコンテナとして動かしている場合はイメージの再ビルドが必要で、ホスト側の更新では上がらない。
参照リンク
|
| GCP | 情報確認中 |
同上。GCE 上の ZCS を 10.1.20 以上へ更新する。
GCP 側に修正対象は無い。判定（zimbra-snmp の導入有無と SNMP 通知の設定）と更新はゲストOS内で行う。
参照リンク
|
| Azure | 情報確認中 |
同上。Azure VM 上の ZCS を 10.1.20 以上へ更新する。
Azure 側に修正対象は無い。Exchange Online 等のマネージドメールとは別物であり、本件は自前運用の ZCS に限った話である。
参照リンク
|
| Linux | 情報確認中 |
Zimbra が配布する 10.1.20 以上のパッケージへ更新する。ディストリビューションのセキュリティ更新（apt/dnf の標準リポジトリ）では上がらない。
ZCS はディストリの公式リポジトリではなくベンダー配布のパッケージで導入するため、Debian/Ubuntu/RHEL のセキュリティトラッカーには本件のエントリが立たない。『ディストリのトラッカーに出ていないので未対応』という読み方をしないこと。判定は dpkg -l | grep zimbra-snmp もしくは rpm -qa | grep zimbra-snmp で行う。
参照リンク
|
対応の順序は、（1）SNMP を使っているかの判定、（2）10.1.20 への更新、（3）更新できるまでの経路遮断、の3段である。まず判定から入るのが効率的である。zimbra-snmp パッケージが導入されているか（Ubuntu/Debian 系なら dpkg -l | grep zimbra-snmp、RHEL 系なら rpm -qa | grep zimbra-snmp）と、SNMP 通知が有効かを確認する。導入していない、あるいは通知を無効にしている環境は、本件に関しては影響を受けない。ただしこれは「今は影響が無い」という意味であって、更新を見送ってよいという意味ではない。運用の都合で後から SNMP を有効にした瞬間に条件が揃うため、判定結果は台帳に残しておくべきである。更新については、ベンダーのアドバイザリが挙げている修正リリースは 10.1.20 だけである。10.0.x や 9.0.x の系列に対する修正リリースは本稿の確認時点（2026-08-22）で advisory に記載が無い。これらの系列を運用している場合、同じ番号の修正が自分の系列に来ているという前提を置かず、ベンダーのアドバイザリを直接確認すること。記載が無い場合に取りうるのは、10.1.20 系への移行か、SNMP 通知の無効化と経路遮断による回避である。回避策としてベンダーが明示しているものは advisory に無い。ただし成立条件が SNMP 通知の有効化であることから、通知を無効化すれば経路そのものが閉じる。これは公式に workaround として提示されたものではなく、脆弱性の成立条件から導かれる措置である点に注意する。あわせて、SMTP が入口になるため、外部から 25/TCP に到達できる構成では露出が大きい。MTA の前段でフィルタしている場合でも、細工されたリクエストが SNMP 通知の処理まで届くかどうかは構成に依存するので、フィルタがあることをもって安全とはしない。KEV の是正期限が 2026-08-24 と近い。米国の連邦機関以外に法的な強制力は無いが、期限の短さは悪用の活発さの目安として読むのが妥当である。完了条件は、（1）ZCS が 10.1.20 以上であること、または zimbra-snmp が未導入もしくは SNMP 通知が無効であることを実機で確認済みであること、（2）その確認結果が資産台帳に記録されていること、（3）更新前の期間について、Zimbra ユーザー権限で実行された想定外のプロセスがないかログを確認済みであることの3点である。
High（CVSS 8.9）に分類されるZimbra（Synacor） Zimbra Collaboration Suite (ZCS) 10.1.20 より前（かつ任意パッケージ zimbra-snmp を導入し SNMP 通知を有効にしている場合）の脆弱性です。Zimbra Collaboration Suite (ZCS) の SNMP 監視コンポーネントに OS コマンドインジェクションがある。NVD の記述によれば、SNMP 通知の処理における入力のサニタイズが不十分で、認証を受けていない攻撃者が細工した SMTP リクエストを送ることで、Zimbra ユーザーの権限で任意の OS コマンドを実行できる。CWE は CWE-78。NVD（Primary）の CVSS 3.1 は 8.9 High で、ベクタは AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L である。CVSS 4.0 は本稿の確認時点（2026-08-22）で NIST による評価が付いていない。注意すべきなのは成立条件である。この欠陥は ZCS の標準構成そのものではなく、任意パッケージである zimbra-snmp を導入し、かつ SNMP 通知を有効にしている場合に成立する。したがって同じバージョンを動かしていても、SNMP を使っていない環境は影響を受けない。逆に言えば、影響の有無はバージョン番号だけでは判定できず、パッケージの導入状況と通知設定を実際に見る必要がある。攻撃の経路が SNMP ではなく SMTP である点も見落としやすい。入力は SMTP で入り、SNMP 通知の処理経路で解釈される。CISA は 2026-08-21 に本件を KEV（悪用が確認された脆弱性カタログ）へ収載し、是正期限を 2026-08-24 に設定した。収載から期限まで3日しかない短い設定で、実際に悪用が観測されていることを示している。ランサムウェアキャンペーンでの使用は KEV 上「不明」として扱われている。ベンダーのアドバイザリは修正内容を『SNMP 通知が有効な場合の SNMP 監視コンポーネントにおけるコマンドインジェクションを修正した』と記載し、修正リリースとして 10.1.20 のみを挙げている。
対応の順序は、（1）SNMP を使っているかの判定、（2）10.1.20 への更新、（3）更新できるまでの経路遮断、の3段である。まず判定から入るのが効率的である。zimbra-snmp パッケージが導入されているか（Ubuntu/Debian 系なら dpkg -l | grep zimbra-snmp、RHEL 系なら rpm -qa | grep zimbra-snmp）と、SNMP 通知が有効かを確認する。導入していない、あるいは通知を無効にしている環境は、本件に関しては影響を受けない。ただしこれは「今は影響が無い」という意味であって、更新を見送ってよいという意味ではない。運用の都合で後から SNMP を有効にした瞬間に条件が揃うため、判定結果は台帳に残しておくべきである。更新については、ベンダーのアドバイザリが挙げている修正リリースは 10.1.20 だけである。10.0.x や 9.0.x の系列に対する修正リリースは本稿の確認時点（2026-08-22）で advisory に記載が無い。これらの系列を運用している場合、同じ番号の修正が自分の系列に来ているという前提を置かず、ベンダーのアドバイザリを直接確認すること。記載が無い場合に取りうるのは、10.1.20 系への移行か、SNMP 通知の無効化と経路遮断による回避である。回避策としてベンダーが明示しているものは advisory に無い。ただし成立条件が SNMP 通知の有効化であることから、通知を無効化すれば経路そのものが閉じる。これは公式に workaround として提示されたものではなく、脆弱性の成立条件から導かれる措置である点に注意する。あわせて、SMTP が入口になるため、外部から 25/TCP に到達できる構成では露出が大きい。MTA の前段でフィルタしている場合でも、細工されたリクエストが SNMP 通知の処理まで届くかどうかは構成に依存するので、フィルタがあることをもって安全とはしない。KEV の是正期限が 2026-08-24 と近い。米国の連邦機関以外に法的な強制力は無いが、期限の短さは悪用の活発さの目安として読むのが妥当である。完了条件は、（1）ZCS が 10.1.20 以上であること、または zimbra-snmp が未導入もしくは SNMP 通知が無効であることを実機で確認済みであること、（2）その確認結果が資産台帳に記録されていること、（3）更新前の期間について、Zimbra ユーザー権限で実行された想定外のプロセスがないかログを確認済みであることの3点である。
Zimbra（Synacor） Zimbra Collaboration Suite (ZCS) 10.1.20 より前（かつ任意パッケージ zimbra-snmp を導入し SNMP 通知を有効にしている場合） を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-73570）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。
はい。CISA の既知の悪用された脆弱性カタログ（KEV）に登録されており、実環境での悪用が確認されています。米国連邦機関向けの対応期限の目安は 2026/08/24 です。推奨される対応: ベンダーの指示に従って緩和策を適用し、CISA の BOD 26-04（リスクに基づくセキュリティ更新の優先順位付け）および Forensics Triage Requirements に従うこと。緩和策が無い場合はクラウドサービス向けの BOD 26-04 ガイダンスに従うか、製品の利用を停止すること。
本ページの記載は下記の一次情報に基づく非公式まとめです。数値・対応状況は各出典元で最終確認してください（最終確認: 2026/08/22）。