一、9月30日，思科自己通报了一个正在被利用的零日漏洞
2026年9月30日，思科发布安全公告 cisco-sa-sdwan-webauth-xr8beuuU，披露 CVE-2026-76504：Catalyst SD-WAN Manager（原 vManage）API 会话认证存在身份验证绕过漏洞，CVSS 基础评分 9.8。思科 PSIRT 确认已在 2026 年 9 月发现该漏洞正被真实攻击者利用，且这个漏洞没有可用的临时规避方案（no workaround）。
几个关键事实需要先摆清楚：
- 利用难度极低：无需任何凭据、无需用户交互，攻击复杂度低，攻击路径为网络可达即可。
- 影响所有部署配置：思科明确说无论怎样配置都受影响。这意味着"我们没开公网访问所以安全"这个假设不成立——绕过的是认证规则本身，不是网络可达性规则。
- 后果是拿到 admin 权限。SD-WAN Manager 默认的 admin 用户拥有 netadmin 角色，理论上可以对被管理的 SD-WAN 全网做任意操作。
- 这是思科 2026 年第5个被在野利用的零日。据 Help Net Security 统计，2026 年已经有 8 个 SD-WAN 相关的 CVE 进入 CISA 已知利用漏洞目录（KEV）。两条统计口径不同（KEV 收录数 vs 零日利用数），但都指向一个事实：思科的网络设备正在被攻击者持续盯上。
二、漏洞原理：为什么一个小小的编码就绕过了认证
思科把根因归结为"对 HTTP 请求中 URI 编码的处理不当"。思科给出的示例请求是这样的：
POST /%6a_security_check HTTP/1.1
其中 %6a 是字母"j"的URL 编码形式。
这行命令里藏着什么？正常的认证路径是 /j_security_check，它受一条认证规则保护。思科自己也在公告里提醒，%6a 只是举例，任何一个被 URL 编码的单个字符都可能被用于攻击——所以只封这一个字符串是封不住的。
技术上的解释逻辑是：认证层和请求路由层对 URI 的解析方式不一致。安全规则匹配的是解码前的字面路径，而后端在分发前先解码，攻击者只要把某个字符编码，就能让请求绕过规则却仍然路由到受保护的接口上。这类缺陷在 Web 应用里由来已久，出现在网络设备的管理 API 上，说明同样的基础性错误在企业级设备里依然存在。
CSA（云安全联盟）实验室的分析里也明确标注了这一点：上述机制解释是 CSA 的分析推论，不是思科的官方发现，思科并未公开内部机制细节。这一点要写清楚——很多安全媒体报道会把这层推断说成厂商结论。
三、修复版本与暴露风险：谁在这次攻击面里
思科公布的各分支首个修复版本如下：
| SD-WAN 发行分支 | 首个修复版本 |
|---|---|
| 早于 20.9 | 必须迁移到已修复分支 |
| 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.15.605 已包含修复，这类客户不需要动作。需要动手的是本地部署（on-premises）的客户。
CSA 建议对这类 SD-WAN Manager 按"假定已被入侵"（presumed-compromise）来处理——凡是 9 月份管理控制台可从不受信网络访问的，都应该假设已经出过问题。理由很直接：打补丁堵住了后续入口，但不会消除攻击者已经获得的访问权。这两件事必须分开做：先查、再堵、然后再修，不是修完就翻篇。
四、查什么日志、怎么确认自己被打了
思科给了两个明确的日志位置，这是确认是否被利用的主要依据：
/var/log/nms/containers/service-proxy/serviceproxy-access.log：查来自陌生或未授权 IP 的 j_security_check 请求，特别注意路径里带 URL 编码字符的请求。/var/log/nms/vmanage-server.log：查涉及以viptela-reserved-开头的用户名的 j_security_check 请求。这类是系统服务账户，攻击者拿下 admin 权限后经常拿它做动作。
除了这两条，思科还建议运行 request admin-tech 命令生成 admin-tech 包，提交给思科 TAC（标题里带 CVE-2026-76504，Severity 3 级别）做深入分析。Rapid7 等机构也强调，面对已确认在野利用的漏洞，不要等常规补丁窗口，应立即升级。
国内企业如果用了 SD-WAN Manager，除了查思科指定的两条日志，建议再额外做三件事：（1）拉出管理控制台的公网访问记录，看 9 月以来有没有异常来源IP；（2）审计管理员账户和API token 列表，看有没有多出来的账号或 token；（3）核对近期的配置变更和路由策略改动——SD-WAN Manager 的权限能触达全网配置，攻击者拿到 admin 后最可能先改路由和分段策略，这一步比查日志更能发现实际损害。
再说一个结构性判断：SD-WAN Manager 位于它所管理的网络之上。拿到它的 admin 权限，攻击者就能读、改、删被纳管设备的配置、路由和分段策略，能把流量重定向去做中间人，能削弱整个 overlay 的安全策略，也能把它当作跳板去攻击下游各个分支和数据中心。这类管理平面的失陷，本质上等同于把全网钥匙一次性交了出去，所以即便日志干净、即使打完了补丁，也建议做一次全面的凭据和配置审计，而不是改完就放心。
五、还没被利用的同族漏洞：另外几条 Cisco SD-WAN CVE
需要说明的是，SD-WAN Manager 今年不是第一次上新闻。2026 年进入 KEV 目录的 8 个 SD-WAN 相关 CVE 之外，思科在更早时候还处理过 CVE-2026-20245（同样是 SD-WAN Manager 漏洞，曾被 Mandiant 发现于披露前利用）。这些加在一起说明一件事：SD-WAN 管理平面正在成为一个持续被针对的攻击面，不是一次性的偶发事件。
给国内企业的一个现实建议：SD-WAN 设备的管理控制台在很多部署里就直接暴露在公网，或者只靠一个简单的 IP 白名单防护。这次 CVE 的处置建议里，思科最强调的一条其实就是最朴素的那条——把管理控制台的公网访问关掉，只允许已知可信主机访问，并把控制面组件放到防火墙等过滤设备后面。这条建议在这次之前就该做，这次是补丁把它的紧迫性顶上来了。
本文漏洞细节、修复版本与日志排查建议均核对自思科官方安全公告 cisco-sa-sdwan-webauth-xr8beuuU（2026年9月30日发布）及 CISA KEV 收录信息、National Cyber Security Authority（卢旺达）与 Rapid7 等机构的公告。"假定已被入侵"的处置建议参考云安全联盟（CSA）实验室分析。文中关于漏洞原理的展开解释为基于思科公开描述的技术分析，思科未公开内部实现细节，具体机制以思科官方公告为准。如你的环境正在使用 Cisco Catalyst SD-WAN Manager 且为本地部署，建议立即按上述步骤核查日志并评估升级需求。
