漏洞
Cisco SD-WAN：一个登录入口，为什么牵动整张网络
Cisco 已确认，攻击者利用 CVE-2026-76504 绕过 SD-WAN Manager 的认证，取得管理 API 权限。修复要留在现有版本分支推进；入口补上以后，还要查清此前是否有人借它改过网络。
文章导航
网络还在正常转发，负责管理它的人却可能已经换了。9 月 30 日，Cisco 披露 SD-WAN Manager 的认证绕过漏洞，并确认 9 月已发生实际利用。攻击者无需先拿到管理员密码，就可能取得管理 API 的权限。对于集中管理多处分支网络的系统，这个位置值得优先处理：一台 Manager 能接触的设备和配置，远多于它自己的操作系统。
CISA 在披露当天将它加入 KEV。Cisco 给出的 CVSS 3.1 分数为 9.8，实际利用则进一步明确了处理的紧迫性。公开公告中的入口很小：请求路径里，一个字符换成了百分号编码。先跟一次正常登录，就能看懂这道本该检查身份的规则为何重要。
1 登录成功后，浏览器拿到了什么
SD-WAN Manager 原名 vManage。管理员可以在网页里配置网络，也可以让自动化程序调用 API。两种操作最后都要回答同一个问题：这次请求属于哪个用户，这个用户能做什么。
Cisco 的认证文档把正常流程写得很清楚。客户端向 /j_security_check 提交用户名与密码，通过后取得 JSESSIONID 会话 Cookie；随后带着它访问 /dataservice/client/token，取得后续请求所需的 CSRF 令牌。多数修改类 POST 请求同时携带会话和 X-XSRF-TOKEN。后者帮助服务端判断请求是否来自既有会话，前提仍然是会话身份可信。
这也是该漏洞的危险之处。PSIRT 公告确认的结果是管理 API 权限。身份一旦在前面被错误接受，后面的 API 便会在这个权限下处理请求。换一个更复杂的管理员密码，无法修复跳过认证的路径；正常登录使用的多因素认证，也不能替一条没有正确进入该流程的请求补做检查。
管理 API 的价值在于它能操作什么。官方接口提供读取设备运行配置等能力，管理员还通过 Manager 维护网络策略和管理账号。由此可以判断，排查范围应包括管理操作及其落到设备上的结果。公开材料没有列出本次攻击者在每个受害环境里执行了哪些动作，也没有据此确认所有被管理设备的操作系统都已失陷。
2 一个字符换种写法，认证规则就漏了
百分号编码很常见。地址里的 %20 表示空格，%6a 表示小写字母 j。RFC 3986允许对字母这类非保留字符做规范化：比较路径时，编码形式可以还原为相同字符。这里不能推广到所有符号；斜杠等保留字符参与分隔路径，解码可能改变结构。
Cisco 在检测说明中给出的路径例子是 /%6a_security_check。人读起来很容易看出它和 /j_security_check 的关系；程序若在不同阶段使用不同形式，保护规则和实际处理的入口就可能对不上。厂商将此次原因定为 URI 编码处理不当，导致保护特定 API 端点的认证规则被绕过。
等价写法没有得到等价保护，这是公告能够确定的失效位置。内部哪一层保留原始路径、哪一层做了解码，Cisco 尚未公开相关函数和完整补丁。图中的关口因此只表示认证规则，不代表某个已经确认的代理或过滤器。
%6a 与 j 表示同一字符。图中下方列出管理权限涉及的对象；公开公告没有逐项确认攻击者对这些对象做过哪些改动。这也解释了为什么只封锁一个字符串很脆弱。Cisco 特别提醒，路径中的其他字符也可能采用编码形式。只匹配 %6a，既无法覆盖这类等价写法，也没有修复服务端认证。需要在产品内部把请求所指向的入口与适用的权限规则对齐，再决定是否执行。
同类系统的代码审查可以从一个具体问题开始：权限判断用的路径，是否就是后面路由使用的路径？大小写、百分号解码和路径整理在哪一步发生，都应有明确顺序。测试也要让普通写法与等价编码落到同一个鉴权结果，同时保留合法 API 调用。这是由公开失效方式得到的检查方向；本文没有执行 Cisco 产品利用或验证其闭源补丁。
3 先留日志，随后在原分支升级
这次处置容易在两个地方走偏：等调查彻底结束才升级，或者为了“最新”直接跨版本分支。Cisco 的10 月 1 日处置指南同时纠正了这两点。每个 Manager 节点先生成包含 Log 和 Tech、无需 Core 的 admin-tech 诊断包；保存后立即安排修复，无需等待 TAC 的 IOC 扫描结果。升级沿现有分支进行，跨分支变更须先取得 TAC 的明确指导。
截至 10 月 2 日，官方针对本漏洞给出的分支内目标如下。这些版本既是本次首次修复边界，也是当前处置指南指定的落点；表中较大的版本号没有替其他分支作升级决定。
| 现有 Manager 分支 | 本次修复目标 |
|---|---|
| 20.9 | 20.9.10.1 |
| 20.12 | 20.12.8.2 |
| 20.15 | 20.15.6.1 |
| 20.18 | 20.18.4.1 |
| 26.1 | 26.1.2.1 |
| 26.2 | 26.2.1 |
20.9 以前的版本需要迁移到受支持分支。集群、主站和灾备站的所有 Manager 都在检查范围内，不能只确认当前登录的节点。此次漏洞针对 Manager；Cisco 对 Controller 和 Validator 的安排，建立在这些组件已完成 2026 年 8 月安全升级的前提上。例如，官方允许已修复的 Manager 20.15.6.1 与 Controller、Validator 20.15.6 搭配。还没有完成此前升级的环境，需要按厂商流程补齐组件，避免把这张 Manager 表当成整套网络的兼容性清单。
云上部署也要分清服务类型。公告明确指出，Cisco Managed Cloud 的 20.15.605 已含修复，客户无需额外操作，可在 Help 界面确认。其他云托管 overlay 仍有自己的升级安排，应在自助门户检查变更窗口和实际版本；“托管在 Cisco 云上”不能自动推出“这一实例已经升级”。
暂时无法升级时，把管理界面的网络访问限制在确实需要的可信来源，能减少可达范围，也会影响原先从其他地址接入的管理员和自动化。云门户的 Allow Inbound 同样应收紧到必要管理网段。厂商没有提供能够完整替代修复的 workaround。若升级失败，应保留这些访问限制并联系 TAC 选择兼容的已修复恢复路径；回到旧漏洞版本会重新开放入口，不能以网页重新能登录作为恢复完成的标志。
4 可疑请求之后，网络上发生了什么
保存升级前的材料，是为了回答补丁本身回答不了的问题：这条入口此前有没有被用过，用过以后改了什么。Cisco 建议向 TAC 提交 admin-tech 作 IOC 扫描；无法生成诊断包时，再按官方说明收集 serviceproxy-access.log、vmanage-server.log 及轮转日志。公告和后续指南对 service-proxy 目录的拼写并不完全一致，按实际安装路径取文件比照抄其中一个绝对路径更可靠。
检查线索包括编码后的 j_security_check 请求，以及 viptela-reserved-* 相关账号活动。它们能帮助缩小时间范围，单条命中仍需和来源地址、响应、会话、账号及后续操作对应。Cisco 提醒，授权扫描和正常操作也可能产生相似记录。漏掉轮转文件或其他集群节点，则可能丢失较早的一段过程。
响应码也需要结合内容读。正常认证文档注明，未认证请求可能得到 HTML 登录页；看到 HTTP 200，并不能单独说明攻击成功。相反，如果相邻时间出现了不在变更计划内的管理账号、策略或配置操作，就需要顺着实际对象继续检查。对比可信配置备份、变更记录和设备当前状态，可以区分一个入口被访问过，与一次管理变更已经生效。
设备上的配置可以在 Manager 升级后继续留存。补丁限制之后进入系统的请求，先前经管理 API 发出的合法格式配置，则需要从变更记录中核对。若发现或高度怀疑未经授权的活动，继续调查身份和配置，必要时恢复；Cisco 的 TAC IOC 扫描不承担整场取证。没有发现 IOC 的环境，厂商仍要求完成升级，无需为等待扫描推迟修复。
我会把这次事件带进集中管理系统的恢复演练：除了恢复管理台本身，还要能回答它曾向下游发出什么决定。策略和账号可以比一次会话存活得更久，甚至在登录入口修好以后继续生效。平时留下可对照的配置与变更记录，出事时才有办法把这些决定逐一追到实际设备。
