公開 PoC が失敗しても「修正済み」とは限らない（Zimbra CVE-2026-73570）
Zimbra の CVE-2026-73570 は複数の公開 PoC が脆弱なサーバーでも失敗するため、「PoC が通らなかった＝安全」と判断できない。判断はバージョン（10.1.20 以降か）と構成（zimbra-snmp と通知の有無）で行い、Swatchdog → snmptrap のシェル → 想定外の子プロセスという連鎖を検知する。
何が起きるか
- 対象は 10.1.20 より前で、追加の SNMP パッケージ（zimbra-snmp）を入れて通知を有効にした構成。認証なしで zimbra ユーザー権限のコマンド実行に至る。zimbra ユーザーは全メールボックスの閲覧と任意アカウントでの送信ができる。
- 流れ: SMTP の
RCPT TOに細工した値 → メールログに記録 → 監視プログラム Swatchdog がサービス状態の変化と解釈 → SNMP 通知を作る Perl 処理が値の一部をシェルへ渡す。 - Elastic の検証では、複数の公開 PoC はログに書く文字列の書式が誤っていて Swatchdog の監視条件に一致せず失敗する。独自の検証コードでは実行に成功。
- CISA は 8 月 21 日に KEV へ追加済み。
確認と対処
- バージョンで判断する: 唯一の完全な修正は 7 月 20 日公開の 10.1.20 以降への更新（Elastic）。PoC の成否で判定しない（脆弱性スキャン結果の扱いは 脆弱性スキャン結果の誤検知を切り分ける 3 手 と同じく、根拠を版と構成に置く）。
- 更新までのつなぎ（Microsoft）: zimbra-snmp の削除、通知の無効化、SMTP と SNMP の接続元制限。
- 検知: Swatchdog の Perl プロセスから snmptrap 呼び出し用のシェルが起動し、そのシェルが snmptrap 以外の子プロセスを作る連鎖。Elastic は悪用成功の非常に強い兆候としている。
- 侵害が疑われるとき（Microsoft の観測と推奨）: JSP 形式の Web シェル、root 昇格、SSH 鍵を使った他ノードへの横展開が観測されている。
zimbraPreAuthKeyを交換し、不審な systemd ユニットを調べる。SSH 鍵による横展開への備えは SSH 鍵を盗まれても横に広がらせない（HashKnownHosts と短命の SSH 証明書、Panchan ワーム事例）。更新で痕跡が消えないよう、先に証拠を保全する（悪用済みの脆弱性は「痕跡を保全してから」更新する（SiteGuard Server Edition 事例））。
注意点
- 「公開 PoC で試して失敗した」は、他の CVE でも安全確認の根拠にならない。PoC 自体の不備で失敗することがある。