2026-11-09 01:06:11 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

SonicWall VPN 一个旧密码跳过 MFA CVE-2026-19868

红队安全圈
红队安全圈

红队安全圈

2026年11月7日 20:00
重庆

去阅读

30 秒看懂

影响范围 · SonicOS Gen7 7.3.3-7015 及更早、Gen8 8.2.2-8015 及更早，且 SSLVPN 开了 SAML 登录。同时还留着本地用户、LDAP 或 RADIUS 账号能登 VPN 的环境，风险最高。

利用状态 · 已在野利用。CISA 11 月 6 日收进 KEV，限期 11 月 20 日；厂商称已调查到一份利用报告，未公布细节，暂无公开 PoC。

补丁状态 · 已修（Gen7 7.3.4-7013 或更新，Gen8 8.2.3-8015 或更新）＋厂商明确说没有临时缓解，升级是唯一解。

一个已经泄露的普通密码，本该在 MFA 那一步被拦住。这条漏洞让它不必经过那一步：只要防火墙还认另一种登录方式，请求就压根不会走到身份提供商，MFA 连被触发的机会都没有。

01 事情是什么

11 月 6 日，SonicWall 发布公告 SNWLID-2026-0014，一次修掉 7 个 SonicOS 漏洞，CVE-2026-19868 是其中最要紧的一个。同一天它被加入已知被利用漏洞目录 KEV，联邦机构被要求在 11 月 20 日 前完成处置。

类型是 CWE-308，使用单因素认证。描述很短：SonicOS SSLVPN 存在认证强制缺陷，持有替代认证方式有效凭据的用户可以绕过 SAML 认证控制；利用成功后，SAML 强制的多因素认证也一并被绕过。

分数不好看也不算难看。厂商自评 7.1，CISA 的富化记录给 7.5，利用复杂度被标成高。两个数都在高危区间，但都不是 9 分往上的震撼数字。这条的分量不在分数上，在于它拆掉的是很多人以为已经建好的那道门。

02 为什么危险

问题的根子是并列，不是串联。

SonicOS 的 SSLVPN 允许同时挂几种认证方式：SAML 单点登录、本地用户库、LDAP/AD、RADIUS。每一种都是独立的登录入口，各自独立配置。当一个用户从非 SAML 入口登录时，SAML 强制检查这段逻辑没有被执行到，身份提供商那边不会收到断言请求，挂在上面的 MFA 自然也不会弹出来。CWE-308 说的就是这个状态：系统实际上允许了单因素登录。

攻击链因此短得不像漏洞利用：

· 拿到一组替代入口的有效密码：撞库、信息窃取木马日志、离职没删的账号、给监控或备份开的本机账号、从初始访问中介手里买

· 连上暴露在公网的 SSLVPN 服务，默认 4433 端口，用这组密码登录

· 不触发 SAML，不触发 MFA，直接拿到 VPN 会话，落进内网地址池

整个过程不需要利用代码，不需要绕过内存保护，也不需要什么 0day 链。这也是它能进 KEV 的原因：门槛低到这个程度，只要有人手上有密码就会试。

第二个危险点是隐蔽。防火墙日志只记下一条成功登录，看不出这次登录走没走 SAML；身份提供商那边干脆没有记录，因为请求从来没到过。两边单看都正常，只有把两份日志按时间和用户对起来，才会发现缺口。而对账这件事，绝大多数单位没做过。

想确认自己有没有被人从侧门进来过，按这个思路对账：

// 防火墙与 IdP 双向对账

防火墙：启用事件 1080 登录成功

以及 263 用户登出

导出用户、源 IP、时间

IdP：查同一用户的 SAML 断言

// 防火墙有 1080，IdP 无对应断言

判定：没走 SAML，按可疑会话处理

第三个危险点是历史。2025 年 3 月的 CVE-2024-12802，9.1 分，走的是同一类逻辑：AD 集成下，防火墙把 UPN 和 SAM 两种用户名当成两条独立登录路径，MFA 可以按登录方式分别配置，换个写法登录就绕过了 MFA。两次漏洞的代码当然不同，但教训一样：MFA 保护了一条登录路径，管不住另一条路径上的密码。而边界设备上活下来的账号，恰恰都是没人愿意去动的那批。

03 谁受影响

· Gen7：TZ270 到 TZ670、NSa 2700 到 6700、NSsp 10700 到 15700，以及 NSv 270 / 470 / 870，版本 7.3.3-7015 及更早

· Gen8：TZ80 到 TZ680、NSa 2800 到 5800，以及 NSv XS / S / M / L，版本 8.2.2-8015 及更早

· 前提条件：SSLVPN 上启用了 SAML 登录。没配 SAML 的防火墙不受这条 CVE 影响

· 真正的高危组合是 SAML 开着，同时本地用户库或 LDAP/RADIUS 里还有能登 VPN 的账号。为了上 MFA 才切到 SAML 的单位，往往正好留着这类账号做应急

· 云上部署的 NSv 同样在范围内：ESX、KVM、Hyper-V、AWS、Azure

04 怎么修

1. 先升级，这一步没有替代方案。Gen7 到 7.3.4-7013 或更新，Gen8 到 8.2.3-8015 或更新

2. Gen8 的版本号要看全：受影响的是 8.2.2-8015，修好的是 8.2.3-8015，只有中间一位不同，别把 8.2.2 的补丁号当成已修

3. 进 SSL VPN 的 Server Settings 确认 Authentication type，看 SAML 是不是开着。没开 SAML 的可以降优先级，但同批其他洞还是要补

4. 把非 SAML 的凭据盘一遍：本地用户、LDAP/RADIUS 账号、服务账号、离职遗留账号。不需要的删掉，留下的改密码。这条比打补丁更能降风险，因为漏洞的前提就是存在这样一组有效密码

5. 开日志做对账：按上面的事件 1080 与 IdP 断言比对，至少回溯到公告发布日。发现无对应断言的成功登录，当入侵处理，别当日志故障

6. 顺手把同批 7 个洞一起补掉：两个管理界面漏洞 8.8 分，特定条件下未认证就能执行未授权操作；SSL-VPN 与 TACACS+ 各有一个预认证缓冲区溢出可打瘫服务；虚拟化平台还有弱口令哈希问题

7. 打了补丁还要收结构：SSLVPN 地址池单独划 zone，别留 VPN 到内网 any 的规则；管理界面和 SSH 不对 VPN 池开放；WAN 侧加登录速率限制，压住针对非 SAML 入口的撞库

05 一句判断

值不值得连夜修，看你的 SAML 是不是只为过审计。SAML 开着、本地账号还留着能登 VPN 的，值得今晚动手，因为这条路的成本只是一组泄露密码，而进了 KEV 意味着已经有人在走。纯 SAML-only、非 SAML 账号全清干净的环境，风险降一档，本周内升级即可，但同批那两个 8.8 的管理界面洞不该拖。

还有一件比补丁更值得做的事：把 VPN 登录和身份提供商的断言做成常规对账。这次是厂商和 CISA 告诉我们有人在用，下次不一定有公告。