SonicWall SSL VPN 漏洞 CVE-2026-19868：当启用了 MFA，登录却绕过了它

即使你的身份平台可以要求每位员工每天都进行手机确认，VPN 登录却依然可能无需确认即可进入。这就是 SonicWall 新漏洞带来的令人不安的教训。

今天是 2026 年 11 月 7 日，这个问题现在就需要引起重视。CVE-2026-19868 已被添加到美国网络安全和基础设施安全局（CISA）维护的已知被利用漏洞（Known Exploited Vulnerabilities）目录中。加拿大网络安全中心于 11 月 6 日发布警报，警告该漏洞已被利用，并敦促各组织尽快更新。受影响的 Gen 7 和 Gen 8 防火墙现已提供修复固件。

在本指南中，我将用通俗易懂的语言解释该漏洞的作用、未涉及的范围以及相关的固件版本。随后，我们将通过一个虚构示例完整走一遍应对流程，以便你了解如何将打补丁与调查排查结合起来。

简要概括

• 它是什么： SonicOS SSL VPN 服务中的一个身份验证漏洞。
• 它会导致什么： 持有备用身份验证方式有效凭据的人可能能够绕过 SAML 身份验证控制，进而绕过通过该 SAML 流程强制执行的 MFA。
• 它是否已被利用？ 是的。加拿大安全通告指出该漏洞正被利用，且它已于 11 月 6 日被列入 CISA 目录。
• 应对措施： 安装修复固件，确认运行的构建版本，测试身份验证行为是否符合预期，并排查更新前是否存在不明远程访问。

先了解几个术语

一个 SSL VPN 允许远程用户通过加密连接访问内部系统，通常经由浏览器或小型客户端应用程序。防火墙通常提供此服务，这意味着它暴露在互联网上，并响应任何人的登录尝试。

MFA，即多因素身份验证，意味着仅凭密码是不够的。你还需要第二重凭证，例如手机上的批准确认。

SAML，即安全断言标记语言，允许服务将登录任务交由外部身份提供商处理。身份提供商是处理员工登录的集中平台。VPN 无需维护自己的密码和规则，而是将用户引导至该平台，由该平台验证密码、应用 MFA 要求并返回结果。

这种设计之所以流行是有充分理由的。策略由一个中心位置统一管理，因此当你收紧策略时，所有连接的服务都会变得更安全。但它基于一个隐含的假设：服务必须切实将每一次登录都交由该中心位置处理。

绕过是如何运作的

根据 SonicWall 撰写的 CVE 描述，持有备用身份验证方式有效凭据的人可能能够绕过 SAML 身份验证控制。成功利用还可能绕过通过该 SAML 流程强制执行的 MFA 要求。该记录将此缺陷归类为 CWE-308：使用单因素身份验证（Use of Single-factor Authentication）。

想象一下有一栋配有前台接待的办公楼。保安会检查你的证件并致电你的经理，然后才准许你上楼。大家都认同这是非常严密的安全措施。现在设想有一扇可以用普通钥匙打开的侧门。保安依然尽职尽责，检查依然严格，但持有那把钥匙的人根本不会遇到保安。

人们的预期是远程用户在获得访问权限前必须完成所需的身份提供商检查。但如果可以在不经过这些检查的情况下建立会话，备用路径就会打破这种预期。

有两点需要客观看待。

首先，这并不是说攻击者可以攻破所有 MFA 技术或入侵身份提供商。你的手机确认流程和身份平台本身并没有被攻破。披露的弱点是一条绕过强制执行附加因素流程的路径。

其次，攻击者需要先掌握一定的初始条件。公开发布的描述中明确指出，前提条件是必须持有另一种身份验证方式的有效凭据。因此，这并非任何互联网用户仅凭空手就能登录的情况。这也指明了排查方向：你既需要考虑存在漏洞的 VPN 服务，也需要考虑能够向其进行身份验证的账户。

为何已被利用改变了处理的优先级

纸面上的漏洞可以留到下一个维护窗口处理。但面向互联网的登录服务上正被利用的漏洞通常不能等。

现在问题的性质变了。不再是“某天是否会有人尝试这么做？”，而是“我们暴露在外的设备是否已经被盯上了？”

我们应该坦诚面对未知的信息。公开信息并未确认受影响组织的具体数量，未指出具体的威胁行为者，也未详细说明攻击者进入系统后的行为。因此，不要以为每次异常的 SonicWall 连接都是由于此 CVE 引起的。这需要佐证。

即便如此，一次成功的 VPN 登录即可为入侵者提供立足点，接下来的情况取决于该账户的权限以及网络分段的完善程度。未经授权远程访问的可能后果包括触及内部应用程序、发现其他系统并试图窃取更多凭据。这些是常规的潜在危害，而非针对此次攻击活动已确认的行为。

受影响版本及修复方案

SonicWall 的 Gen 7 和 Gen 8 公告列出了以下分支。

平台	列为受影响	已修复
Gen 7 物理和虚拟防火墙	SonicOS 7.3.3-7015 及更早版本	7.3.4-7013 及以上版本
Gen 8 物理和虚拟防火墙	SonicOS 8.2.2-8015 及更早版本	8.2.3-8015

此处有三个关键细节。

• 阅读完整安全通告。 该通告在 SNWLID-2026-0014 编号下涵盖了多个高危和中危漏洞。切勿仅根据 MFA 绕过这一项来评估本次更新。
• 检查完整的构建编号。 仅看主版本号说明不了什么。你需要完整的发行和构建编号，才能确认设备运行的是否为修复后的版本。
• 参考针对你具体型号的指引。 请根据厂商最新的安全通告以及针对该具体设备的升级指南来选择固件。

实操案例：Rohit 的星期五

下面通过一个虚构场景将这些内容串联起来。其中的一切皆为虚构。公司、数据和登录情况均为示例，并不代表真实攻击或此 CVE 的具体行为。

Rohit 在 Acme 负责安全工作。Acme 是一家中型公司，拥有一个总公司、四个分支机构和一个容灾站点。员工通过 vpn.example.com，且 VPN 使用 SAML，因此每次登录都会转至公司的身份提供商，并需要手机确认。

周五早上 Rohit 读到了这则警报。一位同事说：“我们没事的，我们所有的东西都启用了 MFA。”Rohit 以前听过类似的话，他决定用证据说话而不是盲目信任。以下是 Rohit 执行的计划。

步骤 1：建立完整的资产清单

Rohit 列出了每一台 SonicWall 设备，而不仅限于团队日常关注的设备。有效的资产清单应包含虚拟设备、分支办公室防火墙、容灾系统以及由服务提供商维护的设备。即使是不常使用的网关，只要其远程访问服务暴露在外，依然可能成为入侵入口。

对于每台设备，Rohit 记录了型号、硬件代次、完整的固件构建版本、SSL VPN 是否可从互联网访问以及设备负责人。表格显示共有六台设备，比预期的多出一台。多出的一台是位于容灾站点的虚拟防火墙，当初是为了测试而建，之后一直未被退役。

步骤 2：在进行任何更改前保存证据

安装修复后的固件可以修复有漏洞的软件，但它无法告诉你是否已经有人入侵。因此在更新之前，Rohit 保留了现有的防火墙、VPN、身份提供商和终端记录。

日志有保留期限，而在忙乱的事件响应期间，旧条目恰好很容易被覆盖轮替。先将它们导出可以为后续调查保留余地。Rohit 还记录了每个系统的时区，因为当时钟不一致时，跨系统比对日志就会失去意义。

步骤 3：按暴露程度的先后顺序打补丁

Rohit 从面向互联网的设备开始入手，按照正常变更流程执行，但将此项工作标记为紧急。参考厂商通告及对应型号的升级指南，将每台 Gen 7 设备升级至 7.3.4-7013 或更高版本，将每台 Gen 8 设备升级至 8.2.3-8015。

每次升级后，Rohit 都会从设备上读回实际运行的构建版本。计划变更或进度条走完都不算数，只有设备实际报告的构建版本才算数。

步骤 4：对今天无法打补丁的设备采取遏制措施

由于本地业务限制，某分支机构的防火墙要到周末才能处理。对于此类情况，应通过已建立的事件与变更管理流程来采取临时的暴露面削减措施。

根据业务需求，可选方案包括将访问限制在受信任的源网络、限制远程访问权限或暂停受影响的服务。Rohit 将该分支机构的 VPN 限制为已知的合作伙伴网络，并记录了该安排的到期日期。

这些步骤需要经过仔细测试，因为它们可能会影响正常用户，并且可能无法覆盖每条访问路径。它们只是临时遏制手段，不能替代修复固件。

有一个选项绝不能考虑，那就是在变更期间通过禁用 MFA 来减少登录问题。这会直接背离目标。当务之急是在减少未授权连接机会的同时，恢复可靠的强制执行机制。

步骤 5：审查每条登录路径

现在 Rohit 提出了“已启用 MFA”无法回答的问题：该服务接受哪些身份验证方式？哪些账户可以使用它们？是否每次成功的登录都遵循了预期的策略？

该审查涵盖了备用身份验证机制、旧有访问配置、应急账户和第三方访问权限。每一项都必须具备明确的业务目的和相应的限制条件。

Acme 发现了一项无人能解释的旧承包商访问配置，以及一个多年未更改密码的应急账户。Rohit 清理了前者，收紧了后者，并轮换了其凭据。公开发布的描述指出有效凭据是利用的前提条件，因此未受管的账户理应受到重点关注。

基于同样的逻辑也有一个警示：这种审查只是辅助打补丁，但不能取代它。仅靠配置检查无法证明存在漏洞的实现能正确执行其预期规则。

步骤 6：将 VPN 会话与身份提供商登录记录进行比对

这是调查中最有价值的部分。如果某个 VPN 会话按要求应该经过 SAML，那么此前在身份提供商处就应该有与之对应的登录记录。因此，Rohit 将这两份日志导出为 CSV，并查找没有匹配记录的会话。

下面是实现该思路的一个简短 Python 示例。文件名和列名均为占位符，请根据你自己的导出数据进行调整。先将所有时间转换为 UTC，例如使用 ISO 格式 2026-11-03T09:14:00+00:00.

import csv
from datetime import datetime, timedelta

# How long before a VPN session a matching sign-in may appear.
WINDOW = timedelta(minutes=10)

def load(path):
    rows = []
    with open(path, newline="") as f:
        for row in csv.DictReader(f):
            row["time"] = datetime.fromisoformat(row["time_utc"])
            row["user"] = row["user"].strip().lower()
            rows.append(row)
    return rows

vpn_sessions = load("vpn_sessions.csv")
idp_signins = load("idp_signins.csv")

for session in vpn_sessions:
    matched = any(
        signin["user"] == session["user"]
        and timedelta(0) <= session["time"] - signin["time"] <= WINDOW
        for signin in idp_signins
    )
    if not matched:
        print("REVIEW", session["time_utc"], session["user"], session["source_ip"])

脚本会输出需要人工审查的会话。假设 Rohit 运行后输出了几行类似这样的内容，其中用文档示例地址替代了真实源地址：

REVIEW 2026-11-03T02:41:00+00:00 finance.user 203.0.113.10

这时需要冷静下来。 缺少匹配记录只是线索，并非被利用的证据。 会话复用、日志保留间隙、时钟差异以及正常的身份验证行为都可能导致误报。输出结果只是指明了排查方向，并不代表实际发生的情况。

步骤 7：追踪线索

对于每个被标记的会话，Rohit 会从更全面的角度进行核查。这些属于常规调查要点，并非专门针对 CVE-2026-19868 发布的指标：

• 来自陌生地址或异常地理位置的成功连接。
• 休眠账户在无明显业务原因的情况下恢复使用。
• 既有账户使用的身份验证方式发生变更。
• VPN 连接后对内部系统的异常访问。
• 非预期的账户、访问策略或防火墙配置变更。

Rohit 的大部分线索最终都被证实属于正常情况，例如会话复用或时钟出现偏差的笔记本电脑。其中一条仍无法解释，因此 Rohit 将其视为可疑线索。如果有证据表明系统受损，应急响应人员应排查受影响的账户和系统范围，撤销相关访问权限并处理暴露的凭据。如果入侵者可能已经触及内部资源，调查就必须延伸至网关之外。

步骤 8：进行双向测试，然后收尾工作

Rohit 的最后一步是许多团队都会忽略的一步。完成更新后，应同时验证预期行为和受禁行为。

合法用户仍应能够连接。因此 Rohit 让一名测试用户登录，并确认身份提供商要求进行手机确认。然后 Rohit 使用经过授权的测试账户尝试应被拒绝的路由，并确认这些尝试均以失败告终。

只有当团队确认了正在运行的构建版本、测试了远程访问策略、验证了监控仍正常运作，并以书面形式记录了所有仍等待整改的设备时，工作才算完成。仅仅安装固件本身并未达到这一标准。Acme 周末分支机构的防火墙仍会以书面形式保留在清单上，直到处理完毕。

托管服务提供商注意事项

如果您为客户维护防火墙，这项工作在每个环境中都需要重复进行。不同的固件构建版本、身份验证配置和维护安排意味着您不能盲目假设一个客户的结果适用于另一个客户。请为每个客户单独保留一份记录，涵盖正在运行的构建版本、测试结果以及对过往访问情况的审查。

更深层的启示：落实强制执行胜于仅仅存在

“已启用 MFA”并不是衡量防护水平的完整指标。一个组织即便拥有严格的身份策略、谨慎的注册流程和可靠的验证因素，但只要应用程序接受了一条能够绕过这些控制措施的独立登录路径，就依然面临风险敞口。

进入受保护服务的每一条获准路径都必须强制执行 MFA。因此，当有人说“我们启用了 MFA”时，更好的追问是：“在哪些路径上？针对哪些账户？我们又是如何确认的？”

此时也是审视 VPN 登录实际赋予了哪些权限的好时机。收紧权限和内部网络分段可以限制远程会话失陷所造成的破坏。集中化日志使调查可疑活动变得容易得多。当本应被拦截的登录依然成功穿透的那一天，这些控制措施就会显现出价值。

结论

CVE-2026-19868 并不意味着 MFA 作为一种安全理念已经失效。它意味着在存在漏洞的防火墙上可能存在一条绕过 SAML 以及其背后 MFA 的路径，且该路径正被利用。对于运行受影响 SonicWall 防火墙的任何人来说，当务之急非常明确：应用修复后的固件，验证身份验证行为是否符合预期，并调查无法解释的远程访问。身份平台中启用了 MFA，并不能证明进入网络的每条路径都强制执行了它。

优势

• 适用于受影响 Gen 7 和 Gen 8 防火墙的修复固件现已发布。
• 全面的资产清点能发现常规补丁修复过程中遗漏的被遗忘网关。
• 将 VPN 会话与身份提供商的登录记录进行比对，提供了一种发现绕过预期路径登录的实用方法。
• 审查备选登录路径可以清除无人维护的陈旧账户和配置安排。
• 同时测试允许的和被阻止的路径可以提供策略得到有效执行的真实证据。

劣势

• 固件更新和临时限制措施可能会对合法的远程用户造成干扰。
• 日志比对可能会因会话复用、保留期断档和时钟偏差而产生误报。
• 较短的日志保留期可能会留下调查无法弥补的盲区。
• 公开信息有限，因此没有公开发布的针对该 CVE 的具体特征指标可供检索。
• 服务提供商必须针对每个客户环境重复整个流程。

注意事项

本文仅供学习参考，基于 2026 年 11 月 7 日获取的公开信息编写。文中的公司、人物、账户、地址和日志条目均为虚构占位符，请将其替换为您自己的实际值，并在使用数据副本前先测试相关脚本。在采取行动前，请根据适用于您具体型号的最新 SonicWall 安全通报核对受影响版本和修复构建版本，在采信任何结论前进行验证，在推向生产环境前进行测试，并自行承担操作风险。

常见问题解答

• 什么是 CVE-2026-19868？ — 这是 SonicOS SSL VPN 服务中的一个身份验证缺陷。持有备选身份验证方法有效凭据的人员，可能能够绕过 SAML 控制以及通过其强制执行的 MFA。
• CVE-2026-19868 是否正在被积极利用？ — 是的。Canadian Centre for Cyber Security 于 11 月 6 日表示该漏洞正被利用，CISA 也在当天将其添加至 Known Exploited Vulnerabilities catalogue。
• 哪些 SonicOS 版本修复了 SonicWall SSL VPN MFA 绕过漏洞？ — Gen 7 需要 7.3.4-7013 或更高版本，Gen 8 需要 8.2.3-8015。请在厂商最新的安全通报中确认适合您具体型号的正确固件。
• 这个缺陷是否意味着 MFA 或 SAML 已被攻破？ — 并非如此。这并不意味着任何 MFA 技术都可以被攻破，也不意味着身份提供商已被入侵。该弱点在于存在一条绕过强制要求额外验证因素流程的路径。
• 攻击者可以在没有任何凭据的情况下利用该缺陷吗？ — 公开的描述将另一种身份验证方法的有效凭据列为先决条件，这也是为什么在此处账户安全与打补丁同样重要的原因。
• 安装固件能否证明我们没有遭到入侵？ — 不能。更新修复了软件，但无法表明此前是否有人侵入，因此请妥善保留日志并审查以往的远程访问记录。
• 我该如何排查可能存在的利用行为？ — 将 VPN 会话与您预期中每个账户应有的身份提供商登录记录进行比对。缺少匹配项是需要调查的线索，而非确凿证据。
• 如果我们无法立即更新 SonicWall 防火墙该怎么办？ — 考虑限制仅允许受信任的网络访问、收紧远程访问权限，或通过变更管理流程暂停该服务。请将这些措施视为权宜之计，绝不要将禁用 MFA 作为变通方案。

标签

#SonicWall #CVE202619868 #SSLVPN #MFABypass #SAML #CyberSecurity #VulnerabilityManagement #IncidentResponse #NetworkSecurity #ZeroTrust