バージョンだけでは判定できない — Zimbra CVE-2026-73570

脆弱性対応の手順は、たいてい「バージョンを調べて、直っている版より下なら当てる」という形に落ちる。資産台帳にバージョンが並んでいれば、あとは比較するだけで済む。

その前提が崩れる種類の脆弱性がある。バージョンは条件の一部でしかなく、残りは構成を見ないと分からないというものだ。台帳に載っているのはバージョンだけなので、こういう欠陥は台帳を眺めているかぎり判定できない。

Zimbra Collaboration Suite (ZCS) の CVE-2026-73570 がそれにあたる。CISA が 2026年8月21日に KEV（悪用が確認された脆弱性カタログ）へ収載し、是正期限を 2026年8月24日に設定した。収載から3日というのは短い部類で、実際に悪用が観測されていることを示している。

この記事では、条件が3つに分かれていることを整理し、最後にその3つを一度に判定するシェルスクリプトを置く。

何が起きるのか

NVD の記述によると、ZCS の SNMP 監視コンポーネントで、SNMP 通知の処理における入力のサニタイズが不十分である。認証を受けていない攻撃者が細工した SMTP リクエストを送ることで、Zimbra ユーザーの権限で任意の OS コマンドを実行できる。

CWE は CWE-78（OS コマンドインジェクション）。CVSS 3.1 は NVD（Primary）で 8.9 High、ベクタは CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L である。CVSS 4.0 は本稿執筆時点（2026年8月22日）で NIST の評価が付いていない。

ベクタで目を引くのは2つある。PR:N（権限不要）と S:C（スコープ変更あり）だ。一方で AC:H（攻撃条件が複雑）が付いていて、これが 9点台に届かなかった理由になっている。

入口と出口がずれている

この欠陥でいちばん誤読しやすいのは、攻撃の入口が SNMP ではないことだ。

  • 入口は SMTP。細工したリクエストはメールの経路から入る。
  • 解釈するのは SNMP 通知の処理。そこでコマンドとして実行される。

「SNMP の脆弱性」と聞くと、UDP 161 番を閉じているから大丈夫だろう、と考えたくなる。だが攻撃者が叩くのは SNMP のポートではない。メールサーバとして当然開いている口から入る。SNMP 側は入口ではなく、入ってきた文字列を実行してしまう側である。

したがって「SNMP のポートを外部に出していない」は、この欠陥に対する緩和にならない。

条件は3つあり、AND で結ばれている

ベンダーの Zimbra Security Advisories は、修正内容を「SNMP 通知が有効な場合の SNMP 監視コンポーネントにおけるコマンドインジェクションを修正した」と記載している。この一文に条件が畳み込まれている。

  1. ZCS が 10.1.20 より前であること
  2. 任意パッケージ zimbra-snmp が導入されていること
  3. SNMP 通知が有効になっていること

3つがそろってはじめて成立する。逆に言えば、10.1.19 を動かしていても zimbra-snmp を入れていなければ、この欠陥については影響を受けない。

ここが冒頭の話につながる。バージョン番号だけを見ている資産台帳は、2と3を答えられない。 「10.1.19 が5台ある」ことは分かっても、そのうち何台が該当するかは分からない。実機を見るまで確定しない。

これは楽観していい話ではなく、むしろ逆である。判定を後回しにすると、「該当なし」と「未確認」の区別が付かないまま台帳に残る。

CVSS 8.9 の内訳を読む

NVD の CVSS v3.1 は 8.9 / HIGH、ベクタは次のとおりである。

1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L

上で見た「条件が3つあって AND で結ばれている」という性格が、そのままベクタに出ている。

項目 値 読み方
AV N（ネットワーク） インターネット越しに届く。SMTP を開けている以上、経路はある
AC H（高） 攻撃条件が複雑。上の条件2・3がそろっている必要があるため
PR N（不要） 認証は要らない。メールを送れれば足りる
UI N（不要） 誰かがクリックする必要はない
S C（変更あり） 脆弱なコンポーネント（SNMP 通知）の外へ影響が出る。OS コマンドが動くので当然
C / I H / H 機密性・完全性への影響は高い
A L（低） 可用性への影響は低い。落とすための脆弱性ではない

AC:H が付いているのに 8.9 という高い点になっているのは、S:C の効きが大きいからである。 スコープ変更は基本値をはっきり押し上げる。「条件が要るので難しい」と「そろったときの被害は大きい」が両方入った、正直な点の付き方だと思う。

運用上は、**AC:H を「うちは大丈夫」と読んではいけない**。ここでいう「条件が複雑」は攻撃者にとっての話であって、条件がそろっているかどうかを決めているのは防御側の構成である。そろっている台にとって難易度は下がらない。KEV に載っているということは、実際にそろっている台が現に狙われている、という意味だ。

修正版は 10.1.x にしか出ていない

もう一点、advisory を読むときの注意がある。修正リリースとして挙げられているのは 10.1.20 だけである。本稿の確認時点で、10.0.x や 9.0.x の系列に対する修正リリースは記載が無い。

古い系列を運用している場合、「同じ番号の修正が自分の系列にも来ているはずだ」という前提を置いてはいけない。advisory を直接確認し、記載が無ければ取りうる選択肢は次の2つになる。

  • 10.1.20 系へ移行する
  • SNMP 通知を無効化して、条件の3つ目を外す

後者について補足しておく。ベンダーが公式の workaround として提示しているものは advisory に無い。SNMP 通知の無効化は、脆弱性の成立条件から導かれる措置であって、ベンダーが検証したうえで案内している回避策ではない。恒久対策は更新であり、無効化は更新までの時間を稼ぐためのものと位置づけるべきである。

実際に試す

3つの条件を一度に判定するスクリプトを置く。ZCS が動いているホスト上で実行する。root でなくても、パッケージ問い合わせとバージョン表示ができれば動く。

前提: Linux（Debian/Ubuntu 系または RHEL 系）、bash。ZCS が /opt/zimbra に導入されている標準構成を想定している。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
#!/usr/bin/env bash
# CVE-2026-73570 (Zimbra ZCS) の該当判定
# 3条件すべてが yes のときだけ「該当」。1つでも no なら、この欠陥については非該当。
set -u

FIXED="10.1.20"
zmpath="/opt/zimbra"

say() { printf '%-28s %s\n' "$1" "$2"; }

# --- 条件1: バージョン ---
ver="unknown"
if [ -x "$zmpath/bin/zmcontrol" ]; then
  ver=$(su - zimbra -c "$zmpath/bin/zmcontrol -v" 2>/dev/null \
        | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  [ -n "$ver" ] || ver="unknown"
fi
say "ZCS version" "$ver"

# バージョン比較（未取得は安全側＝不明として扱い、合格に倒さない）
if [ "$ver" = "unknown" ]; then
  c1="unknown"
elif [ "$(printf '%s\n%s\n' "$FIXED" "$ver" | sort -V | head -1)" = "$FIXED" ] \
     && [ "$ver" != "$FIXED" ]; then
  c1="no"      # ver > FIXED
elif [ "$ver" = "$FIXED" ]; then
  c1="no"      # ver == FIXED
else
  c1="yes"     # ver < FIXED
fi
say "1) version < $FIXED" "$c1"

# --- 条件2: zimbra-snmp パッケージ ---
if command -v dpkg-query >/dev/null 2>&1; then
  dpkg-query -W -f='${Status}' zimbra-snmp 2>/dev/null | grep -q "install ok installed" \
    && c2="yes" || c2="no"
elif command -v rpm >/dev/null 2>&1; then
  rpm -q zimbra-snmp >/dev/null 2>&1 && c2="yes" || c2="no"
else
  c2="unknown"
fi
say "2) zimbra-snmp installed" "$c2"

# --- 条件3: SNMP 通知（トラップ送信先が設定されているか） ---
c3="no"
for f in "$zmpath/conf/swatchrc.in" /etc/snmp/snmpd.conf "$zmpath/conf/zmsnmp.conf"; do
  [ -r "$f" ] || continue
  if grep -Eq '^[[:space:]]*(trap2sink|trapsink|informsink)[[:space:]]+[^[:space:]]' "$f"; then
    c3="yes"; break
  fi
done
say "3) SNMP notification set" "$c3"

echo "---"
if [ "$c1" = "yes" ] && [ "$c2" = "yes" ] && [ "$c3" = "yes" ]; then
  echo "該当: 3条件すべて成立。$FIXED 以上へ更新すること（KEV 是正期限 2026-08-24）。"
  exit 2
elif [ "$c1" = "unknown" ] || [ "$c2" = "unknown" ]; then
  echo "判定不能: 取得できなかった項目がある。手で確認すること（未確認を非該当に倒さない）。"
  exit 1
else
  echo "非該当: この欠陥の成立条件を満たさない。ただし更新自体は別途計画すること。"
  exit 0
fi

期待される出力は次の形になる。

1
2
3
4
5
6
ZCS version                  10.1.19
1) version < 10.1.20         yes
2) zimbra-snmp installed     no
3) SNMP notification set     no
---
非該当: この欠陥の成立条件を満たさない。ただし更新自体は別途計画すること。

意図してそうしている点が2つある。

判定不能を非該当に倒していない。 バージョンやパッケージ状態を取得できなかった場合は exit 1 で「判定不能」と言う。ここを exit 0 にすると、取得に失敗したホストが「安全」として台帳に載る。測れなかったことと問題が無いことは別である。

非該当でも更新を勧めている。 今日 SNMP を使っていなくても、運用の都合で明日有効にすれば条件がそろう。判定結果は「今の構成での話」であって、更新を見送ってよい理由にはならない。

完了条件

対応が終わったと言うために確認すべきものを3つ挙げておく。

  1. ZCS が 10.1.20 以上であること。または zimbra-snmp が未導入か SNMP 通知が無効であることを実機で確認済みであること
  2. その確認結果が資産台帳に記録されていること（バージョン欄だけでは足りない）
  3. 更新前の期間について、Zimbra ユーザー権限で実行された想定外のプロセスがないかログを確認済みであること

3つ目を入れているのは、KEV 収載が「既に悪用されている」という意味だからだ。更新は今後の侵入を止めるが、済んでしまった侵入は止めない。

各クラウド・ディストリでの対応状況は CVE Watch の該当ページにまとめている。なお ZCS はディストリの公式リポジトリではなくベンダー配布のパッケージで入るため、Debian/Ubuntu/RHEL のセキュリティトラッカーには本件のエントリが立たない。トラッカーに出ていないことを未影響の根拠にしないこと。

セキュリティ
#CVE #脆弱性対応 #KEV #Zimbra #SNMP
バージョンだけでは判定できない — Zimbra CVE-2026-73570
https://blog.hashito.biz/2026/08/22/zimbra-cve-2026-73570-snmp-optional-package/
著者
hashito
作成日
2026年8月22日
著作権