Zimbra漏洞仍遭利用：启用SNMP通知的旧版必须升到10.1.20

台湾国家资通安全研究院于2026年9月4日再次将CVE-2026-73570列入 Zimbra高风险漏洞警讯，要求尽快确认并修补。此前披露的实战利用状态仍未被撤回，但风险范围有明确边界，并非所有Zimbra Collaboration服务器都满足已知攻击条件。

需要优先处置的是版本低于10.1.20、安装可选zimbra-snmp软件包并启用SNMP通知的实例。新加坡网络安全局在8月21日发布的 官方安全警报 中称该漏洞正被用于真实攻击；成功利用可让未经身份验证的攻击者执行任意命令，并可能进一步控制服务器、建立持久化、访问邮箱、收集凭据和横向移动。

第一步：用三个条件划定受影响实例

管理员应逐台核对Zimbra Collaboration的实际运行版本、zimbra-snmp软件包是否安装，以及SNMP通知是否启用。三项条件同时成立，才落入目前公开通告描述的已知可利用范围；只看资产台账中的产品名称，无法判断一台服务器是否符合条件。

核查范围应覆盖生产、灾备、测试以及仍能联网的退役节点。可选软件包可能因早期监控需求而保留，SNMP通知也可能延续自旧配置或部署模板，因此“当前没有查看SNMP监控数据”不能替代对安装状态和生效配置的检查。

未安装zimbra-snmp，或能够以配置证据确认SNMP通知未启用的实例，不符合此次公开攻击路径的完整前提。这只意味着其处置优先级不同，并不等于旧版本没有其他漏洞，也不能替代常规安全更新。

第二步：升级到10.1.20并验证生效

对符合三个条件的节点，直接修复是部署10.1.20；如果组织采用更高的受支持版本，则应安装相应的最新安全更新。Zimbra官方漏洞表 明确将CVE-2026-73570描述为SNMP通知启用时的命令注入问题，并把修复版本列为10.1.20。

若维护窗口尚未开始，关闭SNMP通知或移除不需要的可选软件包可以切断公开描述的利用前提，但不应被记录为永久修复。受影响节点应按外部可达性和业务重要性排序，其中能够从互联网接收相关流量的服务器应优先安排。

升级完成不等于工单结束。管理员还需从运行中的节点重新读取版本，确认相关服务已加载更新后的组件，并检查自动化部署、配置管理或灾备切换是否会恢复旧版本或重新启用原有配置。

第三步：把升级前的暴露窗口视为调查范围

漏洞已经出现实战利用，因此补丁只能关闭后续入口，不能清除攻击者此前留下的访问能力。若服务器在升级前曾同时满足三个条件，应以该配置的启用时间至补丁生效时间作为初步暴露窗口，并在清理或重装前保全邮件服务日志、系统日志和必要的取证副本。

排查应把异常邮件流量与主机行为放到同一时间线上，关注无法由正常运维解释的命令执行、陌生进程、计划任务、启动项、脚本文件、账户变化和异常出站连接。公开警报说明了潜在后果，却没有提供足以覆盖所有攻击活动的统一入侵指标，因此未命中某个文件名、IP地址或进程名不能单独证明服务器安全。

如果发现可疑行为，调查边界应扩展到同一管理域内的其他邮件节点、目录服务、备份系统和运维入口。是否扩大隔离范围应依据日志、账户活动和网络连接，而不是仅凭服务器已经显示10.1.20来结束判断。

邮箱、会话与凭据需要单独核查

邮箱访问和凭据收集是官方警报列出的成功利用后果，因此这部分不能被一般主机检查替代。调查人员应核对管理员与服务账户、邮箱委派权限、异常登录、活动会话、转发规则、邮件读取记录以及近期权限变更，判断攻击者是否已从服务器入口转向账户层面。

若证据表明认证材料可能泄露，应先隔离仍可能受控的节点和管理入口，再撤销相关会话，并按组织的事件响应流程轮换密码、密钥或令牌。顺序很重要：在受控状态尚未解除时直接写入新凭据，可能让新凭据再次暴露。

截至9月4日的公开信息可以确认，CVE-2026-73570已遭实战利用，受影响配置和10.1.20修复版本均已明确；尚不明确的是所有攻击活动使用的基础设施、持久化方式和完整取证指标。因而，对符合利用条件且曾处于暴露状态的服务器，当前合理的处置终点不是“补丁已安装”，而是升级得到验证、暴露窗口完成调查、相关邮箱和凭据风险得到处置。