一、漏洞速览一场由“配置文件泄露”引发的核弹级危机2026年2月13日一个编号为CVE-2026-26333的严重漏洞被正式公开。该漏洞影响 Calero VeraSMART 2022 R1 之前的所有版本CVSS 3.1 评分为9.8严重CVSS 4.0 评分更是达到了10.0满分。这不是一个普通的漏洞。攻击者无需任何身份验证只需通过网络向目标发送几个精心构造的 HTTP 请求就能先读取服务器上的 web.config 文件提取其中的 machineKey再伪造 ViewState 载荷最终在 IIS 应用上下文中实现远程代码执行RCE。更令人警惕的是这并非孤例。就在同一时期另一个编号为CVE-2026-5426的漏洞被曝出影响 Digital Knowledge 公司的 KnowledgeDeliver 学习管理系统LMS同样是因为硬编码的 machineKey 导致 ViewState 反序列化 RCE。根据 Google Mandiant 和 Google 威胁情报小组的报告该漏洞已被在野利用攻击者借此部署了 Godzilla 网页后门和 Cobalt Strike Beacon。这是一个信号machineKey 泄露 ViewState 反序列化这条攻击链正在从理论走向现实从概念验证走向大规模在野利用。本文将完整还原 CVE-2026-26333 的攻击全链路从漏洞根源、利用手法、检测方法到修复方案逐层剖析。同时我们还将结合 CVE-2026-5426 的真实攻击案例探讨这类漏洞的行业影响与防御之道。二、漏洞根源CVE-2026-26333 的技术解剖2.1 什么是 Calero VeraSMARTCalero VeraSMART 是美国 Calero 公司的一款电话计费软件Telecom Expense Management广泛应用于企业通信成本管理场景。根据 CVE 数据该软件在 2022 R1 版本之前存在严重的安全设计缺陷。2.2 攻击链第一步未认证的 .NET Remoting 服务VeraSMART 在 TCP 端口8001上暴露了一个未经身份验证的 .NET Remoting HTTP 服务。该服务发布了多个默认的 ObjectURI其中包括EndeavorServer.remRemoteFileReceiver.rem更致命的是该服务同时支持SOAP 和二进制格式化器binary formatters且TypeFilterLevel被设置为Full。关键句加粗TypeFilterLevel Full意味着服务端会反序列化任意类型的对象这是反序列化漏洞的经典“温床”。2.3 攻击链第二步任意文件读取 → web.config 泄露由于服务未做身份验证攻击者可以调用暴露的 Remoting 端点通过WebClient类执行任意文件读写操作。最直接的攻击路径是读取WebRoot\web.config文件。该文件是 ASP.NET 应用程序的核心配置文件通常包含system.webmachineKeyvalidationKey[64位十六进制字符串]decryptionKey[32位十六进制字符串]validationSHA1decryptionAES//system.web一旦 machineKey 被获取攻击者就拿到了 ASP.NET 应用程序的“万能钥匙”——既能解密 ViewState也能伪造通过完整性校验的 ViewState。2.4 攻击链第三步ViewState 反序列化 → RCEASP.NET 的 ViewState 机制用于在页面回传postback时保持页面状态。ViewState 数据以__VIEWSTATE参数的形式存在于 HTML 表单中经过 Base64 编码和可选的加密/签名。machineKey中的两个关键参数决定了 ViewState 的安全性validationKey用于对 ViewState 进行 HMAC 签名防止篡改decryptionKey用于加密/解密 ViewState 内容当攻击者获取了 machineKey 后就可以使用ysoserial.net等工具生成恶意 ViewState 载荷将恶意载荷通过__VIEWSTATE参数发送给目标应用服务端使用泄露的 machineKey 验证并解密载荷反序列化过程中触发任意代码执行根据 CVE 描述攻击者最终可以在IIS 应用程序上下文中实现远程代码执行。2.5 附加攻击面NTLM 哈希泄露CVE-2026-26333 还有一个“附赠”的攻击向量攻击者可以提供UNC 路径如\\attacker.com\share\file触发服务账户发起出站 SMB 认证从而暴露 NTLMv2 哈希值可用于中继攻击或离线破解。三、同源漏洞CVE-2026-26335 与硬编码 machineKey值得特别关注的是Calero VeraSMART 还同时存在另一个相关漏洞CVE-2026-26335同样被评为9.8严重。3.1 漏洞描述根据 CVE-2026-26335 的描述VeraSMART 在C:\Program Files (x86)\Veramark\VeraSMART\WebRoot\web.config中使用了静态的、硬编码的 machineKey 值。3.2 两个漏洞的关系漏洞编号攻击路径CVSS关键差异CVE-2026-26333Remoting 文件读取 → 泄露 web.config → 提取 machineKey → ViewState RCE9.8需要先通过 Remoting 读取文件CVE-2026-26335直接利用硬编码 machineKey → ViewState RCE9.8无需文件读取直接利用已知密钥CVE-2026-26335 更加危险——因为 machineKey 是硬编码的所有未打补丁的 VeraSMART 实例共享相同的密钥。攻击者只需从一处获取密钥甚至直接从公开渠道获得就能攻击所有实例。关键句加粗硬编码 machineKey 意味着“一次泄露全局沦陷”。这不是单个系统的风险而是整个产品生态的安全灾难。四、现实威胁CVE-2026-5426 在野利用全记录如果说 CVE-2026-26333 还停留在漏洞公告阶段那么CVE-2026-5426则用血淋淋的现实告诉我们这类攻击已经不是“会不会发生”的问题而是“什么时候轮到你”的问题。4.1 漏洞概述CVE-2026-5426 影响 Digital Knowledge 公司的 KnowledgeDeliver 学习管理系统LMS该产品在日本市场尤其流行。漏洞根源与 CVE-2026-26335如出一辙厂商在标准化的web.config文件中硬编码了 machineKey 值所有部署实例共享相同的密钥。CVSS 评分为7.5高但根据 OpenCVE 的数据该漏洞的 CVSS 3.1 评分实际达到了9.1。4.2 攻击时间线根据 Google Mandiant 和 Google 威胁情报小组的报告时间节点事件2026年2月24日之前所有 KnowledgeDeliver 默认部署实例均使用硬编码 machineKey2026年2月24日厂商修复了该问题但未公开披露2026年具体时间未公开未知威胁行为者利用该零日漏洞发起攻击2026年5月26日CVE-2026-5426 被公开披露4.3 攻击手法还原攻击者的操作链路如下第一步获取硬编码 machineKey由于所有 KnowledgeDeliver 实例使用相同的 web.config 模板攻击者只需从一个可访问的实例或通过公开渠道获取 machineKey。第二步伪造 ViewState 载荷使用ysoserial.net等工具利用已知的 machineKey 生成恶意的__VIEWSTATE参数。第三步发送恶意请求将恶意__VIEWSTATE通过 HTTP 请求发送给目标服务器。第四步服务端反序列化 → RCE服务器使用硬编码的 machineKey 验证并反序列化载荷触发任意代码执行。4.4 攻击者的后续操作在获得服务器控制权后攻击者执行了以下操作部署 Godzilla 网页后门代号 BLUEBEAM获得持续访问能力提升权限通过命令将 Web 应用目录的访问权限授予 “Everyone”篡改 JavaScript 文件在应用 JS 文件中注入代码显示虚假安全警报钓鱼攻击诱导用户安装“安全认证插件”实际为恶意安装包部署 Cobalt Strike Beacon最终在用户机器上植入 Cobalt Strike关键句加粗从 ViewState 反序列化 RCE 到 Cobalt Strike 部署攻击者在短短几步之内完成了从“初始访问”到“持久化控制”的完整攻击链。Google 特别指出攻击者针对不同组织使用了不同的加密密钥来加密载荷说明攻击者在攻击前对目标进行了充分的情报收集。五、攻击工具链ysoserial.net 与 ViewState 载荷生成5.1 ysoserial.net 简介ysoserial.net是 .NET 生态中最著名的反序列化漏洞利用工具支持生成多种 .NET 反序列化攻击载荷。对于 ViewState 攻击ysoserial.net提供了专门的ViewState生成器需要以下参数--validationkey从 web.config 中提取的 validationKey--validationalg验证算法如 SHA1、HMACSHA256--decryptionkey解密密钥如使用加密--decryptionalg解密算法如 AES、3DES--payload要执行的 .NET 对象如ActivitySurrogateSelector--isdebug是否启用调试模式5.2 载荷生成示例# 使用 ysoserial.net 生成恶意 ViewStateysoserial.exe-pViewState-gActivitySurrogateSelectorFromFile-ccmd.exe /c calc.exe\--validationkey[从 web.config 提取的 validationKey]\--validationalgSHA1\--decryptionkey[从 web.config 提取的 decryptionKey]\--decryptionalgAES\--apppath/\--path/Default.aspx生成的载荷是一个经过 Base64 编码的字符串可直接替换 HTTP 请求中的__VIEWSTATE参数。5.3 为什么 ViewState 攻击如此有效根据 Microsoft 在 2025年2月发布的研究报告超过 3,000 个 ASP.NET machineKey 值已被公开暴露在 GitHub、Stack Overflow 乃至 Microsoft 自己的文档中。这意味着即使没有 CVE-2026-26333 这样的文件读取漏洞攻击者也可以通过公开的 machineKey 字典直接发起攻击大量企业仍在使用这些已泄露的密钥浑然不知Microsoft 警告称这些暴露的密钥可被用于攻击 Web 服务器包括导致远程代码执行的场景六、影响范围评估6.1 CVE-2026-26333 受影响版本厂商产品受影响版本安全版本CaleroVeraSMART 2022 R12022 R1 及以上根据阿里云漏洞库和绿盟科技安全漏洞系统的信息所有运行 Calero VeraSMART 2022 R1 之前版本的系统均受影响。6.2 更广泛的影响面CVE-2026-26333 和 CVE-2026-5426 揭示了一个系统性的行业问题ASP.NET 生态的普遍风险任何在 web.config 中硬编码或可被读取 machineKey 的 ASP.NET 应用都面临同样的 ViewState 反序列化 RCE 风险供应链安全问题厂商在标准部署模板中硬编码密钥导致“一次泄露全局沦陷”历史遗留问题许多企业部署后从未更新过 machineKey即使密钥已被公开多年七、检测与复现7.1 如何检测是否受影响步骤一检查 VeraSMART 版本# 检查 VeraSMART 安装版本Get-ItemPropertyHKLM:\SOFTWARE\Wow6432Node\Veramark\VeraSMART|Select-ObjectVersion如果版本号低于 2022 R1则存在风险。步骤二检查 web.config 中的 machineKey!-- 检查 C:\Program Files (x86)\Veramark\VeraSMART\WebRoot\web.config --system.webmachineKeyvalidationKey[检查是否为静态/硬编码值]decryptionKey[检查是否为静态/硬编码值]//system.web步骤三检查 .NET Remoting 服务暴露情况# 从外部检测端口 8001 是否可访问nmap-p8001target-ip如果端口 8001 对外开放且未做访问控制则攻击者可能通过 CVE-2026-26333 读取 web.config。7.2 漏洞复现授权测试环境下⚠️ 警告以下内容仅供安全研究和授权渗透测试使用未经授权攻击他人系统属于违法行为。环境准备目标VeraSMART 2022 R1工具ysoserial.net、Burp Suite 或自定义 Python 脚本复现步骤通过 .NET Remoting 读取 web.config调用RemoteFileReceiver.rem端点使用WebClient.DownloadFile方法读取WebRoot\web.config提取 machineKey从 web.config 中解析validationKey和decryptionKey生成恶意 ViewState使用ysoserial.net生成包含 RCE 载荷的 ViewState发送攻击请求将生成的__VIEWSTATE参数注入到任意 ASP.NET 页面的 POST 请求中验证 RCE观察目标服务器是否执行了预期命令如 calc.exe 弹出、DNS 回连等八、修复方案与防御措施8.1 官方修复方案CVE-2026-26333 修复升级到 Calero VeraSMART2022 R1 或更高版本厂商尚未提供独立补丁需通过版本升级完成修复CVE-2026-26335 修复升级到 VeraSMART 2022 R1 或更高版本其中静态 machineKey 已被替换为动态生成的密钥CVE-2026-5426 修复升级到 2026年2月24日之后发布的 KnowledgeDeliver 版本或手动生成唯一的 machineKey 并替换 web.config 中的硬编码值8.2 临时缓解措施如果无法立即升级建议采取以下临时措施1. 网络层隔离在防火墙上限制对 TCP 8001 端口的访问仅允许可信 IP将 VeraSMART 服务器置于内部网络避免暴露在公网2. 更换 machineKey立即生成新的、唯一的、密码学强度足够的 machineKey使用aspnet_regiis工具生成# 生成新的 machineKey在 IIS 服务器上执行aspnet_regiis-pcNetFrameworkConfigurationKey-exp# 或使用 PowerShell 生成$validationKey[System.Convert]::ToBase64String([System.Security.Cryptography.RNGCryptoServiceProvider]::GetBytes(64))$decryptionKey[System.Convert]::ToBase64String([System.Security.Cryptography.RNGCryptoServiceProvider]::GetBytes(32))3. 禁用不必要的 .NET Remoting 服务如果不需要 .NET Remoting 功能考虑禁用该服务4. 启用 ViewState 加密和 MAC确保 web.config 中正确配置了ViewStateEncryptionMode和EnableViewStateMAC8.3 长期安全实践根据 G5 Cyber Security 2026年1月的安全指南将 machineKey 存储在 Windows 加密存储中而非直接写在 web.config 中使用 SHA2 系列加密算法如 HMACSHA256避免使用已不安全的 SHA1每个部署实例使用唯一密钥绝不共享或复用定期轮换 machineKey建议每季度或半年一次监控异常的 ViewState 流量如过大的__VIEWSTATE参数、异常的 Base64 特征等九、竞品与生态对比9.1 ASP.NET vs 其他 Web 框架的安全性对比框架ViewState 等效机制默认安全配置密钥管理ASP.NET WebFormsViewState含 MAC默认启用 MAC但密钥需手动管理web.config 明文存储存在泄露风险ASP.NET Core无 ViewStateRazor Pages/MVC不涉及反序列化风险更低使用 Data Protection API密钥可存储在 Azure Key Vault 等Spring (Java)无内置 ViewState使用 Session 或 Token无类似 machineKey 的全局密钥PHP无内置 ViewState使用 Session无类似机制ASP.NET WebForms 的 ViewState 机制在设计时就引入了反序列化风险而现代框架如 ASP.NET Core、Spring Boot已不再使用此类机制。9.2 为什么 ASP.NET 生态的 machineKey 问题持续存在根据 Microsoft 2026年5月的安全警告超过3,000 个 machineKey已被公开暴露。主要原因是历史包袱大量遗留 ASP.NET WebForms 应用仍在运行配置复杂性machineKey 的生成和配置对非安全专业人员来说门槛较高缺乏自动轮换许多企业“配置即遗忘”从未更新过密钥供应链问题厂商在模板中硬编码密钥客户直接使用十、总结与趋势判断10.1 核心结论CVE-2026-26333 是一条完整的、可武器化的攻击链路未认证 .NET Remoting → 任意文件读取 → web.config 泄露 → machineKey 提取 → 伪造 ViewState → 反序列化 RCE这条链路之所以危险是因为它将一个配置管理问题machineKey 可被读取和一个设计缺陷ViewState 反序列化串联起来形成了一条从网络访问到系统控制的完整攻击路径。10.2 行业趋势判断趋势一ViewState 反序列化攻击将更加普遍CVE-2026-26333、CVE-2026-26335、CVE-2026-5426 的接连曝光表明machineKey 泄露导致的 ViewState RCE 正在成为 ASP.NET 生态的头号威胁。随着 Microsoft 公开 3,000 泄露密钥攻击者的“弹药库”已经相当充足。趋势二供应链安全危机升级KnowledgeDeliver 事件证明厂商在部署模板中硬编码密钥已经成为供应链安全的重大隐患。一个厂商的错误配置可能导致数千个客户同时暴露。趋势三从“概念验证”到“在野利用”加速CVE-2026-5426 已被证实存在在野利用攻击者不仅实现了 RCE还完成了后门部署、权限提升、横向移动和钓鱼攻击的全链条。这标志着 ViewState 反序列化攻击已经进入实战化阶段。趋势四监管与合规压力增大随着这类漏洞的频繁曝光预计会有更多监管机构如 CISA将 machineKey 管理纳入合规检查范围。10.3 给企业的行动建议立即行动24小时内盘点所有 ASP.NET WebForms 应用检查 web.config 中的 machineKey 配置确认 VeraSMART 版本是否低于 2022 R1检查 TCP 8001 端口是否对外开放短期行动1周内升级受影响的 VeraSMART 到 2022 R1 或更高版本更换所有已知或疑似泄露的 machineKey在网络层限制对 .NET Remoting 端口的访问长期行动1个月内建立 machineKey 定期轮换机制将 machineKey 迁移到 Windows 加密存储或 Azure Key Vault考虑将遗留 ASP.NET WebForms 应用迁移到 ASP.NET Core彻底消除 ViewState 风险部署 WAF 规则检测异常的__VIEWSTATE参数附录关键资源与参考资源链接/描述CVE-2026-26333 官方页面vulnerability.circl.lu/vuln/cve-2026-26333CVE-2026-26335 官方页面vuldb.com/cve/CVE-2026-26335CVE-2026-5426 官方页面app.opencve.io/cve/CVE-2026-5426Google 威胁分析报告cloud.google.com/blog/topics/threat-intelligence/knowledgedeliver-viewstate-deserialization-vulnerabilityysoserial.netGitHub - pwntester/ysoserial.netMicrosoft machineKey 安全警告techbloat.com/microsoft-1000s-of-asp-net-keys-allow-web-server-rce最后一句忠告如果你的企业还在运行任何 ASP.NET WebForms 应用请立即检查 web.config 中的 machineKey。那个被你遗忘在配置文件里的 64 位字符串可能就是攻击者打开你系统大门的钥匙。