FlawOpen

flawopen.com/Teardowns/cve-2026-73570-zimbra-snmp-command-injection

● CVE-2026-73570 · CVSS 8.9[5], [10] · 高
セキュリティ研究 · FlawOpen

CVE-2026-73570：ZimbraのSNMP通知経路でコマンドインジェクションが起きた仕組み

CVE-2026-73570は、ZimbraのオプションSNMP通知経路にある未認証のコマンドインジェクションです。細工されたメールが状態値に影響し、その値が後でshellコマンドへ埋め込まれる可能性がありました。Zimbraは10.1.20で呼び出し方を修正しました。その後Microsoftは、公開前にスキャンツールが脆弱な経路を調査していたと報告しました。[1], [2], [5]

CVSS ベクトルCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L[5], [10]
💡 わかりやすい解説 (ELI5)

郵便担当者が封筒のラベルを作業指示書に写します。以前の仕組みでは指示書全体をコマンド解釈器に渡していたため、ラベルの文字を追加の命令と誤認する可能性がありました。修正後は通知プログラムに引数を個別に渡し、ラベルを単なるデータとして扱います。[8], [9], [3]

主要な概念と専門用語

swatchdog
このZimbra経路でログを監視し、サービス状態の行を検出して通知処理を起動するプロセスです。[1]
SNMP Trap
イベント発生時に管理対象システムからSNMP監視先へ送られる通知です。[1]
shell展開
shellが解析するコマンド文字列を組み立てることです。信頼できない値の文字がコマンドの解釈を変える可能性があります。[8], [7]
リスト形式のsystem
Perlの複数引数形式のsystemはプログラムを直接起動し、引数を個別に渡すため、shellにコマンド文字列を解析させません。[9], [3]

フレームワーク対応

根本原因の分析 (Root Cause)

影響を受けたコードはrpmconf/Conf/swatchrcのdosnmp関数にあります。swatchルールは状態行からサービス名を取得し、donotify経由でSERVICEとして渡します。dosnmpはその値を$snmptrapを含むバッククォートのコマンドに挿入していました。バッククォートはshellを起動するため、ログ由来の値がコマンド構文として解釈される可能性がありました。公表されている前提条件はすべて必要です。Zimbra Collaboration Suiteが10.1.20未満で、オプションのzimbra-snmpパッケージがインストールされ、SNMP通知が有効であることです。Microsoftは細工されたSMTP入力が通知経路に到達し得たと報告しています。また、2026年7月28日から8月7日にかけて、スキャンツールが脆弱な注入箇所を調査していたと観測しました。これは7月20日の修正後、8月13日の一般公開前のことです。Zimbraの修正はshell文字列をリスト形式のsystem(...)に置き換え、実行ファイルと引数を個別に渡します。実行経路からshellが外れます。この分析はSNMP通知コードに限られ、すべてのZimbra環境やSMTPメールが脆弱という意味ではありません。[1], [2], [3], [5], [7]

CVE-2026-73570 到達条件と修正のマトリクス

デプロイ条件文書化された経路に該当するか防御対応
Zimbra Collaboration Suite 10.1.20 未満、オプションの zimbra-snmp パッケージがインストール済み、SNMP 通知が有効。文書化された通知経路には3条件すべてが必要です。Microsoft は、細工された SMTP 入力がサービス状態の値に影響し、その後 dosnmp で処理される可能性を報告しています。10.1.20 以降に更新します。露出期間の関連ログとプロセステレメトリを確認し、痕跡は侵害の証明ではなく調査の手掛かりとして扱います。
zimbra-snmp パッケージがない、または SNMP 通知が無効。この構成では、説明された dosnmp 通知経路は有効ではありません。サーバーに他の脆弱性がないことを示すものではありません。サーバーを修正するまでは機能を無効にするか、パッケージを入れない状態にします。すべての mailbox ノードを棚卸しし、各ノードで設定を確認します。
Zimbra Collaboration Suite 10.1.20 以降で、ベンダー修正済みパッケージが導入済み。文書化された shell コマンド構築は 10.1.20 で修正されました。バージョン文字列だけでは全ノードやローカル変更を確認できません。各ノードの導入バージョンとパッケージを確認します。過去に3つの露出条件を満たしていた期間は、通常のインシデント調査を行います。

ステップ・バイ・ステップの攻撃フロー

ステップ 1

前提条件が成立

10.1.20未満、zimbra-snmpをインストール済み、SNMP通知が有効。[1]

ステップ 2

メールが監視値に影響

Microsoftによると、SMTP入力がログ内の状態値に影響し得ました。exploit文字列やネットワーク手順は省略しています。[1]

ステップ 3

swatchdogが値を引き渡す

ルールがサービス欄を取得し、通知有効時にdonotifyからdosnmpへ渡します。[1]

ステップ 4

shellが値をコマンドとして解析

修正前はPerlのバッククォートが取得値を含む文字列をZimbraサービス権限でshellへ渡していました。[1]

ステップ 5

10.1.20でshellを経路から除去

修正は引数を分けてsnmptrapを実行します。更新後も露出環境を調査してください。修正は過去の活動を否定するものではありません。[1]

ソースコード比較：脆弱 vs 堅牢化

脆弱なバッククォートは展開済み文字列をshellに渡します。上流の修正は複数引数のsystemを使い、実行ファイルと各引数を個別に渡すため、SERVICE内のメタ文字がshell命令になりません。これは変更箇所を示す抜粋であり、実行可能なexploitやファイル全体ではありません。[3], [4], [8], [9]

ソース抜粋: rpmconf/Conf/swatchrc: dosnmp

脆弱な実装
# 影響を受けたdosnmpの要約。exploit入力は示さない。
sub dosnmp {
    my %args = (@_);
    `$snmptrap $snmpsvctrap $snmpsvcname s $args{SERVICE} $snmpsvcstatus i $statuses{$args{STATUS}}`;
}
堅牢化されたセキュアパッチ
# Zimbra 10.1.20の修正：引数を分けてプログラムを直接起動する。
sub dosnmp {
    my %args = (@_);
    system(
        "/opt/zimbra/common/bin/snmptrap",
        "-v", "2c", "-c", "zimbra", $traphost, "",
        $snmpsvctrap, $snmpsvcname, "s", $args{SERVICE},
        $snmpsvcstatus, "i", $statuses{$args{STATUS}}
    );
}

エンジニアリング＆システム堅牢化チェックリスト

参考資料