Cisco 披露了 Cisco Secure Email Gateway 中一个正在遭到积极利用的漏洞。对于使用实体设备或虚拟设备的组织，这一问题需要立即处理。CVE-2026-76461 是产品邮件解析逻辑中的一个无需身份验证的 SQL 注入漏洞。Cisco 将其 CVSS 评分定为 9.8，并表示成功攻击后可能在底层操作系统上以 root 权限执行命令。

带有警报指示灯和取证日志分析的通用企业电子邮件安全网关

真正重要的运营细节并不只是评分本身。该设备位于组织进出邮件的路径上，Cisco 表示，无论设备采用何种配置，Secure Email Gateway 都会受到影响。不存在能够让受影响安装保持安全的厂商临时缓解措施，必须安装补丁，随后检查设备是否已经被使用过。

这是一项包含两个独立问题的响应工作：组织能多快把易受攻击的网关迁移到修复版本，以及组织能多有把握地判断网关在更新前是否遭到滥用。如果把第一个问题当成全部工作，第二个问题仍然没有答案。

Cisco 披露了什么

Cisco 于 2026 年 9 月 14 日发布的安全公告指出，CVE-2026-76461 存在于 Cisco Secure Email Gateway 所使用的 Cisco AsyncOS Software 邮件解析逻辑中。根本弱点是输入验证不足。实际攻击中，攻击者可以通过受影响设备发送经过特殊构造的电子邮件。Cisco 将由此产生的问题描述为 SQL 注入，攻击者可能借此执行任意 SQL 语句，继而以 root 权限执行命令。

攻击不需要身份验证、特权账户，也不需要用户交互。Cisco 公布的 CVSS 向量为 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，表示这是一个可通过网络触达、攻击复杂度低，并且可能对机密性、完整性和可用性造成高影响的漏洞。这个评分有助于说明问题为何紧急，但不能证明每一台网关都已经被入侵。

Cisco 将实体部署和虚拟部署的 Secure Email Gateway 都列为受影响对象。公告表示，无论设备配置如何，风险都适用。Cisco 另行指出，Secure Email and Web Manager 以及 Secure Web Appliance 不受这项特定漏洞影响。对于同时拥有多个 Cisco 安全产品的资产负责人，这一区分很重要：名称相近的产品不能用来判断是否暴露，未直接面向互联网的网关也不能因此自动被视为安全。

Cisco 的公告是有关漏洞、受影响产品家族、入侵指标和修复软件的主要技术来源。加拿大网络安全中心于 9 月 14 日转发了这项警报，并记录 Cisco 已报告存在积极利用。CISA 也将该 CVE 加入已知遭利用漏洞目录，使其成为漏洞管理团队进行优先级排序的重要信号；对于美国联邦民事机构而言，在适用的 CISA 流程下，这还意味着必须完成修复。

积极利用会改变决策

Cisco 表示，其 PSIRT 于 2026 年 9 月获悉该漏洞正在遭到积极利用。这个措辞具有实际意义。它比研究人员展示概念验证，或安全社区讨论理论攻击路径更强，意味着防守方应假设该漏洞已经被用于现实活动，同时仍不能无依据地断言某个特定组织已经遭到入侵。

在本文审阅的公告中，公开记录没有把相关活动归因于某个已命名的威胁行为者，也没有描述针对某个特定行业的已确认行动。这种信息缺失不是等待的理由。相关决策应依据暴露情况、漏洞利用状态以及设备在邮件投递中的角色。组织不需要等到出现醒目的事件报道，才开始遏制和检查。

因此，优先级应当明确而迅速：

  • 如果组织运行着易受攻击的 Secure Email Gateway，应识别确切的 AsyncOS 版本，并将修复更新安排为紧急变更。
  • 如果设备在易受攻击期间接收过邮件，应在常规留存或轮转机制删除有用证据之前，保存并检查其日志。
  • 如果发现可疑活动，应把设备视为可能遭到入侵的安全控制组件，并让事件响应人员、Cisco 支持团队和组织的邮件安全负责人参与处理。

补丁能够关闭软件中的已知缺陷，却不能追溯删除攻击者可能已经执行的命令、建立的持久化机制，或已经访问的凭据和邮件数据。

哪些版本已经修复

Cisco 9 月发布的加固版本为管理员提供了最实用的升级映射。对于 Cisco Secure Email Gateway Release 15.5 及更早版本，第一个修复版本是 15.5.5-014。Cisco 加拿大警报还列出了该产品家族的修复分支：15.5.5-014、16.0.4-302 和 16.5.0-780，具体取决于当前使用的分支。管理员应依据 Cisco 当前针对具体产品的公告和软件下载信息，为自身部署选择受支持的修复版本，不要直接把与当前分支无关的版本号照搬过来。

这项更新并不是一个小型配置变更。Cisco 的加固公告说明，设备会在升级后重启。这会给邮件团队带来短时的服务规划问题，但不足以成为无限期推迟修复的理由。变更窗口应包括重启后对邮件队列、路由、隔离区、证书、管理访问以及高可用或集群安排的确认，确保这些功能正常工作。

Cisco Secure Email Cloud 需要采用略有不同的运营路径。Cisco 表示，该服务方案包含 Secure Email Gateway 和 Secure Email and Web Manager 设备，Cisco 会提供定期维护。客户可以通过 Cisco Secure Email Cloud 支持请求升级。使用云服务的组织应提交或核实支持工单，询问哪些底层设备和维护版本覆盖这个 CVE；在问题得到确认期间，还应保存客户能够访问的日志。

不要把本地没有补丁按钮误认为没有责任。托管服务改变的是由谁执行升级，并没有消除确认升级确实完成的需要，也没有消除审查相关时段可疑活动的需要。

为什么只打补丁还不够

Cisco 提供了一个范围有限但很有价值的入侵迹象检查：检查设备的 mail_logs，寻找可疑 SQL 语句。公告以 COPY ... TO PROGRAM 为示例模式，并说明出现这类记录可能意味着有人尝试利用漏洞。在集群部署中，Cisco 要求检查每个集群设备的日志。

这项检查应被视为证据收集，而不是寻找某个神奇字符串。没有搜到示例模式，不能证明没有发生其他活动；反过来，匹配到字符串也需要上下文。分析人员应在下结论前保存时间戳、来源信息、邮件标识符、设备身份、管理事件、配置变更和相关遥测数据。该搜索只是厂商提供的起点，并不是完整的入侵评估。

一次实际审查至少应回答以下问题：

  • 哪些网关运行过易受攻击的版本？确切的暴露时间区间是什么？
  • 这些网关中，哪些接收过来自不受信任来源或广泛可达来源的邮件？
  • 每个节点在完整暴露期间的 mail_logs 是否仍然可用，包括保留、轮转或集中存储的副本？
  • 日志中是否出现可疑 SQL 语法、异常邮件处理、意外的管理活动、配置变更，或者设备本不应创建的进程与连接？
  • 网关是否处理过凭据、令牌、证书、隔离区内容、地址簿，或其他一旦暴露就需要通知或轮换的信息？
  • 网关是否属于某种管理或监控体系，而该体系可能让攻击者把访问范围扩展到设备之外？

最后两个问题，正是漏洞响应转变为事件响应的地方。邮件网关可能不是组织的主要数据存储，但它处理的邮件可能包含业务信息、密码重置链接、发票、身份证明文件、恶意软件样本和内部路由细节。攻击者还可能借此干扰过滤或投递，即使没有大规模数据窃取证据，也会造成信任问题。

一套可经得起审查的响应顺序

先明确责任和资产清单。漏洞管理团队可能拥有软件清单，邮件团队负责设备，网络团队负责暴露路径。把这些记录合并起来。记录序列号或虚拟实例标识、部署位置、产品角色、AsyncOS 版本、管理路径、集群成员关系、最近一次备份、日志留存状态以及变更负责人。目标是形成一份有限的设备列表，并用带时间戳的方式说明哪些设备曾经易受攻击。

接着，在准备变更期间减少可以避免的暴露。不要自行臆造临时解决方案，也不要认为防火墙规则等同于厂商修复。检查管理接口是否限制在管理网络内，入站邮件路径是否能够限制为组织预期的中继，监控是否正常工作。这些措施可以减少不必要的可达性，但无法修正仍需接收外部邮件的设备中的解析缺陷。

然后，将每台受影响设备更新到适用的修复版本。记录更新前后版本、维护窗口、重启时间、验证结果，以及任何失败或延期的节点。对于集群，要逐个核实每个成员。部分更新的集群仍然处于暴露状态，过时的虚拟设备镜像也可能在恢复或扩容时重新引入易受攻击版本。

升级后立即保存可能因日常运转而丢失的证据。根据组织的事件处理流程导出或复制相关日志，保留原始时间戳，并记录每个文件由谁收集。如果设备看起来被篡改过，应避免反复进行会破坏取证上下文的改动。将问题升级给专业人员，由他们判断干净重建或更换设备是否比信任已升级系统更安全。

最后，根据调查结果轮换可能已经暴露的内容。具体清单取决于网关配置和证据，候选项可能包括本地管理凭据、服务凭据、API 令牌、证书及私钥、中继凭据、隔离区访问权限，以及集成中保存的秘密。轮换工作应与邮件流协调，避免安全改进悄然造成服务中断。

不同团队分别要做什么

对邮件管理员而言，第一项任务是找出全部实体、虚拟和云后端网关，并确认其修复版本。逐个检查集群成员。重启后验证邮件流，确认日志仍然启用，并尽可能保持集中化存储。

对安全运营团队而言，应围绕每台设备的易受攻击时段建立重点调查窗口。检查厂商指定的日志位置及相关遥测，再与身份验证、网络、DNS、终端和身份系统事件进行关联。目标是判断网关只是暴露在风险中、遭到过探测，还是已经被成功修改。

对漏洞管理团队而言，应把 CVE-2026-76461 记录为遭到利用的漏洞，而不只是一个高分项目。CISA 的 KEV 条目很有用，因为它为风险决策增加了实际利用证据。所有例外都应有负责人和到期时间。没有补偿控制、证据计划和截止日期的例外，本质上只是没有记录的延期。

对托管服务客户而言，应向服务提供商提出精确问题：部署的具体产品和版本是什么，提供商是否已将每个相关节点更新到修复版本，工作何时完成，日志保存多久，以及提供商是否发现恶意活动。要求答案对应组织实际使用的实例，而不是笼统地说服务会得到维护。

对领导者而言，有用的状态报告应简短而具体：受影响设备数量、已修复数量、待处理数量、暴露时间段、日志可用性、可疑发现、已轮换的凭据或证书，以及下一次复查时间。不要把 CVSS 分数当成事件状态来汇报。分数说明潜在严重性，却不能告诉领导组织是否已经遭到入侵。

公告没有回答的问题

公开公告在初期往往会有意保留信息。Cisco 确认存在积极利用，但在本文审阅的材料中没有提供完整的行动叙事。由此不能推断所有技术细节都已公开，也不能推断公开利用代码已经出现，更不能因为某个网关没有明显异常就认为它干净。防守方应依赖厂商修复版本和入侵指标，同时把调查当作一个基于本地证据的问题。

公告也没有把日志审查变成简单的二元测试。日志可能不完整，集中化过程可能存在缺口，复杂入侵者也可能使用与厂商示例不同的活动。结论质量取决于设备本身以及周边系统能够提供的可见性。如果相关时段的设备记录已经丢失，应明确记录这一限制，而不是把它转化成虚假的安心。

公告同样不意味着所有 Cisco 安全产品都面临相同暴露。被点名的受影响产品是 Cisco Secure Email Gateway。Secure Email and Web Manager 被指出不受这项特定 SQL 注入公告影响，不过 Cisco 另行发布的 9 月加固公告覆盖范围更广，并包含 Manager 产品。资产负责人应将每个 CVE 映射到确切的产品和版本，不要给整个 Cisco 资产环境贴上一个笼统标签。

保持冷静，但不要拖延

CVE-2026-76461 之所以紧急，是因为受影响组件对许多组织而言是面向互联网的邮件控制设备，攻击无需身份验证，Cisco 将其严重性评为 9.8，而且 Cisco 表示漏洞正在遭到积极利用。只要把工作拆成具体动作，响应仍然是可管理的。

找出设备，确认版本，升级到修复的 AsyncOS 分支，在每个相关节点保存并检查 mail_logs。在宣布关闭事件前调查可疑结果；当证据或架构表明有必要时，轮换凭据或证书。如果服务由云端管理，要从提供商那里取得针对实际实例的确认。

最重要的区别在于修复与证明。安装补丁可以修复已知漏洞；审查暴露期间和现有证据，才能让组织以诚实且与证据相称的把握说明网关是否曾被用于攻击自身。

来源与延伸阅读