2026-10-22 13:24:14 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

邮件网关被人写进文件，先查的不是补丁号

原创

tcode
tcode

字节脉搏实验室

2026年10月19日 14:10
北京

去阅读

10月14日16时（格林尼治时间），思科发布安全公告，编号CVE-2026-76519，描述的是邮件网关里一个不需要登录就能利用的任意文件写入问题：发件人只要让一封带特制附件的邮件经过设备，就可能把文件写到设备操作系统上，进一步以root权限执行命令。公开评分是9.8。同一天，这个编号被美国网络安全和基础设施安全局列入已被在野利用的漏洞目录。

这件事对国内运维最现实的含义不是“又有一个高危漏洞”，而是判断顺序。思科把受影响条件写得很窄：不是所有装了邮件网关的机器都算，必须同时满足两条；而修复路径也有两条，其中一条不需要升级系统、不需要重启。先把资产和条件对上，比先去找补丁号更重要。

两个条件同时成立才算暴露

第一条是文件信誉服务（File Reputation）处于启用状态，并且已经分配给某条邮件策略。它是高级恶意软件防护（AMP）里负责附件判断的那一部分；只在功能列表里看到它，不等于它真的在拦截邮件，要看它是否绑定到了具体策略。

第二条是内容扫描工具（Content Scanner Tools）的版本早于25.3.0.5525。两个条件缺一个，按公告的表述就不属于受影响的组合。设备形态上，物理机和虚拟机的邮件网关都在范围内；同一份公告明确排除了邮件与Web管理器、Web安全设备这两个产品，不要顺手把整条安全产品线都算进去。

这里有一个很容易踩的边界：思科建议运行16.5以前版本的客户迁移到16.5.0-780，而16.0分支没有列出修复构建。如果一台设备停留在16.0.4-302——那是修好了9月另一个SQL注入问题的版本——它在这个漏洞上仍然不算已修。换句话说，“我上个月刚打过补丁”不能替代这次的条件核对。

三道门的查法

第一道门在界面里。进入邮件策略下的入站或出站策略，找到高级恶意软件防护，选中具体策略，看“启用文件信誉”这一项是否被勾选。只勾了全局开关、没有分配给策略，不算满足条件。

第二道门在命令行里。在设备上执行contentscannerstatus，它会返回当前内容扫描工具的版本和最后一次更新的时间。公告给出的示例输出形如“25.2.0.5427.15.5.001 Never updated”，其中“Never updated”本身就提示这台设备从未自动拿到过扫描器更新。把返回值与25.3.0.5525逐位比较，不要凭“应该会自动更新”来判断。

第三道门是AsyncOS的版本线。15.5分支的首个修复版本是15.5.5-014，16.5分支是16.5.0-780，16.0分支没有修复构建，只能迁到已修复的版本。版本号要在设备上实测读取，不要从采购清单或CMDB里的记录推断——这类设备经常在项目交付后由不同团队接手，台账与实际运行版本对不上是常态。

三道门都通过，才算“已修”或“本来就不在范围内”；任意一道没过，就按暴露资产处理。这个顺序还有一个好处：它把“有没有装AMP”“扫描器是不是最新”“系统版本够不够”三个问题分开问，避免在跨部门沟通时把三件事搅成一句“我们已经升级了”。

修复有快慢两条路

快的一条是更新内容扫描工具。公告说明，25.3.0.5525或更高版本可以单独安装，不需要升级系统，也不需要重启。开启了自动更新的设备，等更新落地后仍需用contentscannerstatus确认版本已经到位；关闭了自动更新的设备，在命令行执行contentscannerupdate，或者到安全服务下的服务更新里把自动更新打开。

慢的一条是升级AsyncOS。15.5分支升到15.5.5-014，16.5分支升到16.5.0-780，16.0分支迁移到已修复版本。公告明确写了没有可用的临时规避方案，所以能做的只有把版本补到位，或者把设备从暴露面上撤下来。

两条路径的关系需要说清楚：扫描器更新本身就是公告列出的修复措施之一，不是“先顶着用”的权宜之计；AsyncOS升级则同时覆盖这处问题和其他修复。现场该走哪条，取决于变更窗口、版本合规要求和这台设备离下一次计划升级还有多远，而不是一律先排大版本升级。

设备里的日志可能被擦掉

公告提供了一段基于系统日志的入侵检查，并给出两种结论：命中则按建议处置，未命中则升级到修复版本。这里必须补一句：设备内的痕迹不是唯一证据。公告本身提醒，攻击者一旦拿到root，可能删除或隐藏利用痕迹和指标，因此要回头查设备之外的网络日志与防火墙日志，重点看从这台设备发往外部地址的异常上传，以及从陌生地址下载内容的记录。

排查时把时间轴对齐：邮件网关的日志时间、防火墙的时间、出口NAT的时间经常不在同一时区或同一时钟基准上。把三者的偏差先量出来，再去看“某封邮件进来之后设备有没有向外传东西”，否则很容易把正常的中继投递当成异常，也容易漏掉真正的那一段。

这里可以给一个可执行的核对方法：先从最近一次正常的外部附件邮件找到一条基线，记录它的邮件跟踪ID、AMP判定、送信时间和出口连接时间；再沿同一封可疑邮件看四个节点——邮件进入设备的时刻、附件被扫描器处理的时刻、设备向外部发起连接的出站时刻、DNS解析目标域名的时间。四个节点只要有一个对不上，就不要用“邮件没有投递”来证明没有触发，要把原始日志和邮件头一起留存。若设备只保留滚动窗口日志，先把当前窗口导出，再安排升级或重启；重启前导出的记录至少要覆盖最近30天，避免维护窗口把唯一证据覆盖掉。这份记录同时要标明是谁在什么时间从哪台设备导出的，避免后续复盘时无法说明来源。

今天该动的顺序

先盘资产：列出所有物理与虚拟邮件网关，标注AsyncOS版本、内容扫描工具版本、文件信誉是否启用并绑定了哪些策略，以及是否由思科托管。托管服务的客户有一个特殊点：思科表示已联系那些出现“可能受损迹象”的托管服务客户，并已在其设备上部署修复后的扫描器；这类客户可能没有命令行权限，也没有必要自行执行上面的检查命令，应按思科的通知和处置指引走，而不是照搬自建设备的步骤。

再决定路径：满足暴露条件且扫描器低于25.3.0.5525的，优先把扫描器更新到位并回读确认；版本线落在16.0或更早的，把迁移排进计划。任何一条都做不到的机器，先评估能否缩小邮件入口的暴露面，并把它单独登记为未闭合项。

最后补证据：保存一次系统的入侵检查结果、contentscannerstatus的输出、以及设备外部的网络日志片段。这三样东西在事后复盘时，比“当时升级过”这句话有用得多。

一个可以直接转述的判断是：文件信誉绑定了某条策略、扫描器版本低于25.3.0.5525、AsyncOS在16.0或更早，这三条同时成立时，这台邮件网关就需要按暴露资产处置，而不是按“已经打过补丁”归档。

边界

公告没有说明有多少台设备被攻击、攻击者是谁、是否有人真的取得了root；它能确认的是，思科在自己的内部安全扫描中发现这处问题，并在10月掌握了攻击活动。被列入在野利用目录，说明存在真实利用，不说明国内已有对应案例。另一个需要留意的口径是：攻击者获得root后可以清痕迹，因此“设备内检查未命中”只能作为一条证据，不能当成未失陷的结论。托管服务的修复由思科侧完成，自建设备则需要自己走完上面的核对与升级。

来源

Cisco Security Advisory，《Cisco Secure Email Gateway Arbitrary File Write Vulnerability》，Advisory ID cisco-sa-esa-afw-zqYJkjxp，发布时间2026-10-14 16:00 GMT，https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-esa-afw-zqYJkjxp

Cisco Security Advisory，《Cisco Secure Email Gateway and Secure Email and Web Manager Security Hardening Release: September 2026》，https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-hardening-esa-dfCrfXkm

The Hacker News，Swati Khandelwal，《Cisco Warns of Active Attacks Exploiting New Critical Secure Email Gateway Vulnerability》，2026-10-14（页面标注 Oct 14, 2026），https://thehackernews.com/2026/10/cisco-warns-of-active-attacks.html