Rapid7技术分析复盘：四个JWT校验缺陷如何串成一次远程认证绕过

Ots安全

2026年8月13日 20:42
广东

在小说阅读器读本章

去阅读

威胁简报

恶意软件

漏洞攻击

一、这不是“又一个SharePoint漏洞”

2026年8月11日，Rapid7发布了对CVE-2026-55040的技术分析。该漏洞影响Microsoft SharePoint的JWT令牌验证流程，远程未认证攻击者可以绕过认证，在目标站点中冒充用户或管理员执行操作。

微软此前已在2026年7月的安全更新中修复该漏洞，并指出漏洞可能导致身份冒充、文件披露和数据修改，但不会直接影响系统可用性。2换句话说，攻击者未必能够通过这个漏洞立刻让服务器宕机，却可能在不具备合法凭据的情况下进入SharePoint的授权边界，读取敏感文档、篡改业务数据，或者将该漏洞作为后续攻击的跳板。

更值得关注的是公开时间差。Rapid7公开详细技术分析和PoC后，威胁情报公司Defused称已在其SharePoint蜜罐中观察到Rapid7 PoC被用于攻击。这不等同于微软已经确认全球范围内存在大规模在野利用，但已经足以说明：公开PoC会迅速改变漏洞风险等级，补丁状态必须从“计划修复”转为“立即核验”。

二、漏洞画像：一张表看清风险边界

项目	内容
漏洞编号	CVE-2026-55040
漏洞类型	JWT令牌验证链认证绕过、身份冒充
攻击位置	Microsoft SharePoint S2S Bearer令牌认证流程
远程利用	Rapid7分析称可由远程未认证攻击者触发
所需权限	不需要有效SharePoint账号
可能身份	SharePoint站点用户、管理员或特定服务身份
主要影响	文件披露、数据修改、身份冒充；微软称不影响系统可用性
公开状态	Rapid7已公开技术分析和PoC；Defused报告蜜罐中出现武器化使用
修复状态	微软已在2026年7月安全更新中修复，具体适用版本应以官方更新指南为准

这里有一个容易被忽略的判断：认证绕过与远程代码执行不是同一个概念。CVE-2026-55040本身的核心影响是“攻击者被当成了别人”，而不是漏洞直接执行任意系统命令。但在真实攻击链中，攻击者一旦能够以管理员身份访问SharePoint，就可能进一步利用站点功能、服务账户、文件内容或其他漏洞完成更严重的入侵。

三、SharePoint为什么使用嵌套JWT？

Rapid7的分析对象是SharePoint的服务到服务认证，也就是S2S认证。它使用一种嵌套的JWT结构：外层令牌携带用户身份声明，内层的actor token代表调用应用，并且理论上应当由受信任证书进行加密签名。

正常情况下，验证过程至少要回答四个问题：令牌是否被可信密钥签名；签名是否确实对应令牌内容；签发者是否属于允许的身份提供方；令牌声明的用户、受众和用途是否与当前请求匹配。

CVE-2026-55040的问题在于，这些检查并非全部由同一套严格的密码学逻辑完成，而是由SharePoint自定义代码、JWT库和证书解析流程共同承担。多个看似分散的校验缺口叠加后，攻击者可以构造一个“格式正确、身份声明可控、但没有真实签名”的令牌。

这类问题的危险性在于：单独看某一个检查，可能只是配置宽松或兼容性设计；但在完整认证链中，任何一个“默认信任”都可能成为下一步绕过的支点。

四、四个弱点如何串成一条绕过链

1. 外层令牌没有强制要求签名

Rapid7在反编译SharePoint代码后指出，令牌验证参数中将RequireSignedTokens设置为false。其直接后果是，外层JWT不再强制要求有效的密码学签名，验证库可能继续解析令牌并填充其中的声明。

从安全设计角度看，JWT的载荷内容是可读的，真正提供完整性和真实性的是签名。关闭“必须签名”检查，相当于允许攻击者先把用户身份、受众和其他声明写入令牌，再期待后续代码自行补救。只要后续补救不严密，攻击者就有机会将伪造身份送入授权流程。

2. actor token只解析证书指纹，不验证签名

在内层actor token中，SharePoint从JWT头部读取x5t证书指纹，并据此寻找签名证书。Rapid7指出，代码能够解析并绑定一个证书对象，却没有在这一阶段对actor token的签名执行真正的密码学验证。

这形成了一个典型的“密钥定位不等于签名验证”问题。系统知道攻击者声称使用哪张证书，却没有证明攻击者真的拥有对应私钥。若验证链只完成“找到证书”，没有完成“用证书验证签名”，证书就从安全凭据变成了一个可被引用的标签。

3. 未注册证书路径反而被接受

Rapid7进一步指出，issuer校验在查询不到匹配的已注册安全令牌服务时，可能直接接受该令牌，而不是拒绝请求。

这类逻辑在代码中往往表现为“找不到对象就返回”，但在安全认证场景中，找不到可信关系通常应当意味着拒绝，而不是放行。当攻击者能够让令牌引用SharePoint自身的服务证书，同时又进入“该证书不属于已注册服务”的分支时，issuer校验就失去了应有的约束作用。

4. GetTokenSignature只检查非空，不检查真假

最后，Rapid7分析称，GetTokenSignature方法只要求令牌存在非空签名字符串，却没有验证该字符串是否是由可信私钥生成的有效签名。

这一步把“存在签名字段”与“签名经过验证”混为一谈。对于安全令牌而言，字符串非空只能证明攻击者填写了内容，不能证明内容具备任何真实性。前面三个弱点已经为伪造令牌打开了通道，第四个弱点则让一个形式上存在的签名材料顺利通过后续处理。

五、攻击链的高层复盘：攻击者到底做了什么？

在不复述可直接利用的PoC代码和请求细节的前提下，公开分析可以抽象为以下流程：

阶段	攻击者动作	验证链缺口
第一步	访问SharePoint可公开访问的元数据接口，收集服务端令牌信息	关键认证元数据可被未认证获取
第二步	构造外层身份令牌，并取消对外层签名的强制要求	`RequireSignedTokens` 配置过于宽松
第三步	在actor token中引用目标SharePoint的服务证书	`x5t` 解析后没有完成签名验证
第四步	使用可控issuer和非空伪造签名通过后续检查	issuer和签名校验逻辑放行
第五步	将可控SID或UPN映射为SharePoint身份	身份声明进入授权上下文
第六步	以站点用户或管理员身份执行请求	认证边界被突破

这条链条的核心并不是“JWT容易伪造”，而是系统把多个本应相互独立的安全条件拆开后，却没有在最后形成强制性的密码学闭环。证书解析、issuer判断、签名字段存在性和用户身份映射分别看似合理，组合起来却没有回答最关键的问题：这个令牌是否由可信私钥对当前内容签发？

六、为什么公开PoC后风险迅速升级？

CVE-2026-55040在微软发布补丁后才出现完整公开分析，这种时间顺序很常见：厂商先修复，研究者再公开根因和验证工具。风险变化发生在PoC公开的瞬间，因为防守方和攻击者都获得了更清晰的漏洞触发条件。

Rapid7公开PoC后，Defused报告称其蜜罐已经观察到相关代码被用于攻击。2从情报研判角度，这至少说明攻击者正在关注该漏洞和公开工具；但蜜罐命中不能直接推导出所有真实生产环境都已遭受入侵，也不能替代组织内部日志和主机证据。

企业需要重点区分三个状态：一是“漏洞已修复”；二是“漏洞已被公开利用”；三是“本组织是否已经被攻击”。完成补丁安装只能解决第一问，不能自动回答第三问。尤其对互联网暴露的SharePoint，必须同时开展补丁验证、访问日志回溯、异常身份审计和关键文件完整性检查。

七、管理员现在应做什么？

先确认补丁真正落地

根据微软安全更新指南确认SharePoint产品线、累计更新和安全更新的适用关系，逐台核对版本与补丁状态。不要只依赖集中式软件清单，因为SharePoint场中的服务器、反向代理、Central Administration和数据库连接角色可能存在版本或配置差异。

补丁完成后应进行独立验证，包括重新扫描、确认组件版本、检查服务状态和验证外部暴露面。对于无法立即升级的系统，应记录业务负责人、临时隔离措施和最终修复期限，而不是简单标记为“风险接受”。

缩小互联网暴露面

CISA建议避免在没有必要时直接将SharePoint服务器暴露在互联网；应限制SharePoint Central Administration的外部访问，并只允许场与数据库之间进行必要通信。确实需要外部访问时，应将SharePoint置于Layer 7反向代理或具备应用层安全能力的控制设备之后。

这类措施并不能修复CVE-2026-55040，但可以减少攻击者直接接触认证入口的机会，降低自动化扫描、PoC批量尝试和后续身份冒充的成功率。