文章总结： 本文介绍CVE-2026-76504思科CatalystSD-WANManager认证绕过漏洞，CVSS9.8分，已在野利用。漏洞源于URI十六进制编码字符导致认证规则匹配失败，攻击者可未认证获取管理员权限。文章详述影响版本、利用路径、日志排查方法及升级修复建议，强调管理口不应暴露公网，需尽快处置。
综合评分： 92
文章分类： 漏洞分析,应急响应,安全运营,红队,安全工具
(9.8分) CVE-2026-76504：思科SD-WAN管理平台认证绕过
红队安全圈
红队安全圈
红队安全圈
2026年10月1日 10:05
重庆
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
一个 hex 编码字符绕过认证拿 admin：思科 SD-WAN 管理平台 CVSS 9.8 漏洞已在野利用，修复刻不容缓。
01 漏洞速览
漏洞编号CVE-2026-76504
影响产品Cisco Catalyst SD-WAN Manager
漏洞类型认证绕过（CWE-288）
危害等级CVSS 9.8 Critical
在野利用已确认（2026-09 活跃利用）
公开 PoC暂无
影响面未认证直接拿 admin，控制全网
一个精心构造的 HTTP 请求，靠 URI 里一个十六进制编码字符，就能绕过认证直接拿到 Cisco Catalyst SD-WAN Manager 的管理员权限。CVSS 9.8，无需账号密码，无需任何交互，官方已确认在野利用。手里有 SD-WAN 的，今天早上就该去查日志。
02 漏洞成因
根因出在 API 会话认证管理对 URI 编码的处理上。
SD-WAN Manager 有一条认证规则，用来限制对某个特定 API 端点的访问。这条规则做匹配时，没有把 URI 里的十六进制编码字符归一化——请求里只要有一个字符用了 hex 编码，认证规则就匹配不上，访问控制直接落空。
举个官方给的例子：字母 j 的十六进制编码是 %6a。把登录端点 j_security_check 写成 /%6a_security_check，认证规则看到的是一条”不认识”的路径，放行；后端服务解析时又把它还原成正常的端点处理。一个字符的编码差异，前端规则和后端解析各看各的，经典的解释不一致（parser differential）问题。
利用效果：请求直达受保护端点，攻击者以 admin 用户权限操作 API，拿到 SD-WAN 全网配置的控制权——改路由、劫持流量、抓取敏感配置、以管理平台为跳板横向移动，都不在话下。
03 影响范围
受影响的是 Catalyst SD-WAN 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 之前的老版本没有修复版，只能迁移到修复版本。SD-WAN Cloud 托管版（思科管理）已在 20.15.605 修复，无需用户操作。
04 利用分析
暂无公开 PoC，但从成因看攻击路径非常清晰：
第一步 侦察：用 FOFA/Shodan/Censys 之类空间测绘引擎找暴露公网的 vManage 管理界面，这类资产指纹明显，一抓一大把。
第二步 构造请求：对认证受限的端点路径做单字符 hex 编码，%6a 只是示例，任意一个字符编码都能触发。
第三步 绕过：认证规则匹配失败，请求放行。
第四步 落地：以 admin 身份调用 API，导出配置、新建管理员、下发路由策略。
利用门槛极低：一个 Burp 就够了，改一个字符的事。这也是它被 KEV 收录、官方紧急警告的原因——这种”一个编码绕认证”的洞，通常在通告发布几天内就会出现批量利用脚本。
05 检测与排查
两份日志，两条排查线。
第一份，访问日志 serviceproxy-access.log（路径 /var/log/nms/containers/service-proxy/ 下），查来自陌生 IP 的 j_security_check 请求，重点看路径里带编码字符的：
grep -E “%[0-9a-f]{2}_
security_check” \
serviceproxy-access.log
命中后的特征示例（编码字符 j）：
POST /%6a_security_check
HTTP/1.1″ 200
第二份，应用日志 vmanage-server.log（/var/log/nms/ 下），查保留系统账号 viptela-reserved- 开头的用户被调用的记录：
grep “viptela-reserved-“
vmanage-server.log
注意：这两类日志在正常运维中也可能出现，要结合自家网络基线判断，不能见一个就当失陷。另外对暴露公网面做一次盘点，vManage 这种管理平面本来就不该直接挂公网。
06 修复建议
-
唯一正解是升级到修复版本，官方明确没有任何绕行方案（workaround）。
-
升级前的临时缓解：防火墙限制访问来源，只放行已知可信 IP 访问管理端口；Cloud 托管版思科侧已默认部署。
-
修复后验证：用带编码字符的路径（如 /%6a_security_check）访问，应返回认证拒绝而非 200。
-
升级前先留存日志，万一确认失陷，证据链要保住。
07 红队视角
这个洞的价值点不在复杂度，而在位置。SD-WAN Manager 是整张企业广域网的大脑，拿下它等于同时拿到：
-
全部分支站点的拓扑和配置（内网测绘直接送上门）
-
流量策略改写权（分流、镜像、劫持都在配置层面完成，终端侧无感）
-
与站点设备之间的信任关系（后续打穿站点边界设备的跳板）
实战评估：攻击复杂度低、无需凭据、无交互，对红队是教科书级的高价值入口；对防守方，这是一天内必须处置的洞。历史经验看，这类认证绕过从通告到武器化通常以天计，别等 PoC 出来再动手。
防御侧建议顺带检查：管理口是否暴露公网、默认管理账号是否还在用、管理平面有没有单独的访问控制层。
08 POC 链接
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-webauth-xr8beuuU
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
说明：暂无公开 PoC，以上为思科官方通告与 KEV 目录地址。
如果文章对您有收获，欢迎关注、点赞、推荐、转发。
— END —
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：红队安全圈 红队安全圈
红队安全圈《(9.8分) CVE-2026-76504：思科SD-WAN管理平台认证绕过》