文章总结： Zimbra邮件服务器CVE-2026-73570高危命令注入漏洞，CVSS8.9，无需认证通过SMTP请求即可在zimbra权限下执行任意命令，已在野外被积极利用。影响ZCS10.1.20之前版本，需安装zimbra-snmp并启用SNMP通知。建议立即升级至10.1.20或临时关闭SNMP通知，排查webshell痕迹并轮换凭证。 综合评分： 85 文章分类： 漏洞分析,命令注入,红队,安全运营,应急响应

CVE-2026-73570：Zimbra 邮件服务器 SMTP 命令注入，SNMP 通知触发未认证 RCE（CVSS 8.9）

红队安全圈 红队安全圈

红队安全圈

2026年8月22日 10:51 重庆

在小说阅读器读本章

去阅读

Zimbra 邮件服务器高危命令注入，无需认证打一条 SMTP 请求即可在 zimbra 权限下执行任意命令，CVSS 8.9，已在野外被积极利用。

01  引言

Zimbra Collaboration Suite（ZCS）是全球部署量很大的邮件与协作套件，政企环境用得多，上面堆着邮箱、通讯录、密码和大量内部资料。这次的 CVE-2026-73570 是一个 CVSS 8.9 的未认证命令注入：只要目标装了 zimbra-snmp 组件并启用 SNMP 通知，攻击者绕过一切认证，发一条精心构造的 SMTP 请求，就能在 Zimbra 用户权限下执行任意系统命令。这个洞已经被确认在野外被积极利用，8 月 21 日进入 CISA 已知被利用漏洞目录。邮件服务器一旦被打穿，等于把员工的邮箱凭证、内网入口一把交出去，威胁等级直接拉满，还在跑 ZCS 的单位今天就必须处理。

02  漏洞速览

漏洞编号CVE-2026-73570

影响产品Zimbra Collaboration Suite（ZCS），10.1.20 之前版本

漏洞类型OS 命令注入（CWE-78）

危害等级CVSS 8.9 高危

是否在野是，已在野外被积极利用

攻击前提安装 zimbra-snmp 且启用 SNMP 通知

影响面无需认证、SMTP 可达即可 RCE

03  漏洞成因

根因出在 SNMP 通知的处理流程上：Zimbra 的 mail 服务在会话状态发生变化时，会把一份服务状态通知交给 swatchdog 和 SNMP 通知机制处理。问题在于，这个处理过程对不可信输入没有做正确清洗。攻击者发送的特制 SMTP 请求，能把恶意字符串注入到这份服务状态通知里；swatchdog 拿到这段没被安全处理的字符串后，不做校验就直接当作系统命令去执行。

命令以 zimbra 系统用户身份运行。这个权限能往站点的 web 目录里写文件（沦陷后放 webshell）、能读写本地配置、能读取邮箱数据，进攻链路一下子就通了。正规口径是 CWE-78 命令注入，但本质上这是一条把网络输入送进 shell 的危险链路，SMTP 流量和系统命令执行之间缺了一道校验闸门。

04  影响范围

受影响版本：ZCS 10.1.20 之前的所有版本。官方修复版本是 10.1.20，升级即可封堵。

这是条件触发型漏洞：不影响所有 Zimbra 部署，前提是装了可选组件 zimbra-snmp 且启用了 SNMP 通知（snmp_notify）。但问题恰恰在于，很多运维图省事、为了监控告警，随手就把这个功能开着，没想过监控功能会变成 RCE 入口。只要满足条件，SMTP 对外可达就等于把命令执行接口暴露在公网上。

05  利用分析

暂没有可靠公开的 EXP 全套，但攻击链本身已经被完整披露过，按实际思路推演：

先摸清目标：SMTP 端口（25/465/587）是否可达，目标是否启用 SNMP 监控，通过 TLS 指纹、版本 banner 和常见 Zimbra 页面判断是不是 ZCS。然后向 SMTP 服务发送一条特制请求，把恶意字符串注入到会话相关的服务状态通知里。swatchdog / SNMP 通知进程不校验这段字符串，直接当作系统命令执行，命令落到 zimbra 用户权限。

拿到执行能力后，首选动作是往 web 目录写 webshell 建立持久化，再读邮箱、通讯录、配置文件里的凭证，最后凭邮件服务器身份往内网横向。

邮件服务器是内网里的高价值节点，所有人都在这上面收发邮件、存通讯录，还经常能翻到系统间互信的账号。这条路径只要打进一次，后面能做的事非常多。判断自己能不能打，一句话：目标 SMTP 可达 + SNMP 通知开着，基本就满足条件了。

06  检测与排查

先确认自己是不是在暴露面里，查 SNMP 通知是否启用：

su – zimbra -c ‘zmlocalconfig -s snmp_notify’

如果 snmp_notify 被打开，再翻邮件日志，找异常的服务状态变更记录。命令执行的成功路径会在 /var/log/zimbra.log 里留下可疑的 Service status change 记录：

grep -i “service status change” /var/log/zimbra.log | tail -100

再找近期新增、属主为 zimbra 的可疑文件，重点盯 web 目录和临时目录：

find /opt/zimbra -user zimbra -mtime -1 -type f | grep -Ei ‘.(php|jsp)$’

检查是否有跟随 SMTP 流量出现的异常子进程或出站外联（webshell / C2 维度）：

ss -tnp | grep -E ‘zimbra.*ESTAB’

邮件会话本身看起来可能完全正常，漏洞利用发出的请求不一定送到用户邮箱里，所以别只盯正常收信日志，要看完整的 SMTP 会话与命令记录。

07  修复建议

立即升级到 ZCS 10.1.20 及以上，这是官方封堵版本。暂时打不上补丁的，临时关闭 SNMP 通知，或直接卸载 zimbra-snmp 组件，把攻击面先收掉。同时收紧 SMTP 暴露面，限制公网来源；如果邮件系统确实要对公网开 25 端口，就用 ACL 和监控兜底。

怀疑已中招的：全盘排查 webshell 痕迹，检查 zimbra 用户下的异常文件，轮换邮箱账号密码，重点看有没有被植入持久化。

08  红队视角

这个洞很典型地体现了监控功能反而放大了攻击面：运维为了告警装个 SNMP 监控，结果把一条网络输入直接送进了 shell。对红队来说，邮件服务器本来就是内网链路里最值钱、最该先摸的节点之一，这次等于多了一条无需认证的 RCE 入口，而且走的是很多人根本没想过要设防的侧。

实战判断：先别急着扫全网的 Zimbra，先想想哪些目标大概率开了 SNMP 监控——监控体系完善、告警体系健全的政企单位中招面更大。打进之后，邮件服务器带来的账号与内网横向价值远高于普通 web 服务器，值得花时间立稳。

提醒一句：这洞已经在野外被大规模利用，南北向和东西向监控大概率都在盯着 SNMP 通知链路和 webshell 痕迹。做完渗透务必把 webshell、临时文件、Session 痕迹清干净，别打进去了反倒把自己暴露出来。

如果觉得有收获，欢迎点个赞、在看，或者转发给身边的同行。

— END —

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：红队安全圈 红队安全圈 红队安全圈《CVE-2026-73570：Zimbra 邮件服务器 SMTP 命令注入，SNMP 通知触发未认证 RCE（CVSS 8.9）》