SRC 挖洞：WSO2 JWT 算法混淆绕过深度复盘，CVE-2026-5430 不支持的算法怎么变成管理员

作者 akihi（白帽攻防录讲师），某甲方网络安全工程师，合集 SRC 年度第一、腾讯 SRC 连续三年前十，单漏洞赏金 4w+，擅长 Web/App/PC 客户端漏洞挖掘。专注 API 安全、JWT 认证、网关安全审计。本文基于公开 CVE 信息与技术原理深度复盘，供安全研究与防护参考。

一、漏洞时间线

2026 年 9 月，CISA 将 WSO2 API Manager 的 JWT 认证绕过漏洞 CVE-2026-5430 加入已知被利用漏洞目录（KEV）。这个 CVSS 评分高达 9.8-10.0 的漏洞，在补丁发布 5 个月后仍在被活跃利用。

时间	事件	影响版本
2026-04	WSO2 发布补丁	4.1.0 - 4.6.0
2026-05-03	WSO2 安全公告发布	------
2026-09-13	watchTowr 发现活跃利用	------
2026-09-16	多家安全厂商发布预警	------
2026-09-24	CISA 将漏洞加入 KEV 目录	------
2026-09-27	联邦机构修复截止日期	------

这个漏洞的可怕之处在于：补丁早在 4 月就发布了，但直到 9 月仍有大量企业未打补丁，导致活跃利用持续存在。

二、攻击链全景

让我们先用一张流程图还原完整的攻击路径：

攻击者发现暴露在公网的 WSO2 API Manager
        │
        ▼
第一步：分析 JWT 认证机制
        │  发送一个测试 JWT 令牌
        │  观察 WSO2 如何处理不同算法
        ▼
第二步：构造伪造的 JWT 令牌
        │  Header 中使用不支持的算法（如 RS256 变体）
        │  Payload 中设置 admin 权限
        │  用任意密钥或不签名
        ▼
第三步：发送伪造的 JWT
        │  Authorization: Bearer <伪造的JWT>
        │  WSO2 收到令牌
        ▼
第四步：fail-open 逻辑
        │  WSO2 发现算法不被支持
        │  但没有拒绝，而是跳过了签名验证
        │  直接信任令牌内容
        ▼
第五步：获得管理员权限
        │  读取 Payload 中的身份信息
        │  以 admin 身份登录管理控制台
        ▼
攻击者获得 API 管理员权限
        │
        ├─ 查看和修改所有 API 配置
        ├─ 窃取 API 中的敏感数据
        ├─ 横向渗透到后端服务
        └─ 植入后门持久化

**关键结论：**这个漏洞的核心是"fail-open"逻辑------当系统遇到不认识的算法时，不是拒绝请求，而是跳过验证直接放行。这种"出错了就放行"的设计在安全领域是致命的。

三、JWT 认证原理

3.1 什么是 JWT

JWT（JSON Web Token）是一种开放标准，用于在各方之间安全地传输信息。它由三部分组成：

1. Header：描述令牌的类型和签名算法（alg 字段）
2. Payload：包含声明（用户 ID、角色、权限等）
3. Signature：用于验证令牌的完整性和真实性

JWT 的安全基础是：只有知道密钥的人才能生成有效的签名。接收方验证签名后才信任令牌内容。

3.2 常见 JWT 算法

算法	类型	描述
HS256	对称加密	HMAC + SHA-256，使用共享密钥
RS256	非对称加密	RSA 签名 + SHA-256，使用公私钥对
ES256	非对称加密	ECDSA + SHA-256，椭圆曲线签名
none	无签名	不签名，只编码（不安全）

3.3 算法混淆攻击

JWT 算法混淆是一种经典攻击方式：

1. 系统配置为使用 RS256（非对称加密）
2. 攻击者将 alg 改为 HS256
3. 系统用 RSA 公钥作为 HMAC 密钥来验证
4. 攻击者知道公钥，可以用公钥作为 HMAC 密钥签名
5. 伪造的令牌通过验证

CVE-2026-5430 是一种类似但不同的算法混淆------不是 HS256/RS256 混淆，而是"不支持的算法被跳过验证"。

四、漏洞深度分析

4.1 漏洞根因

根据 WSO2 安全公告和技术分析，漏洞的根本原因是 JWT 验证逻辑中的 fail-open 行为：

// 有缺陷的验证逻辑（伪代码）
function verifyJwt(token) {
    // 1. 解析 JWT
    const header = decodeHeader(token);
    const payload = decodePayload(token);
    
    // 2. 检查算法是否被支持
    if (!supportedAlgorithms.includes(header.alg)) {
        // 问题在这里！
        // 不支持的算法没有拒绝，而是跳过验证
        log.warn("Unsupported algorithm: " + header.alg);
        // 直接返回 true，跳过签名验证
        return true;  // fail-open！
    }
    
    // 3. 如果算法被支持，才验证签名
    return verifySignature(token);
}

// 修复后的逻辑
function verifyJwt(token) {
    const header = decodeHeader(token);
    const payload = decodePayload(token);
    
    // 修复：不支持的算法直接拒绝
    if (!supportedAlgorithms.includes(header.alg)) {
        log.error("Unsupported algorithm: " + header.alg);
        throw new AuthError("Invalid algorithm");
        // return false;  // fail-closed！
    }
    
    return verifySignature(token);
}

4.2 为什么会这样设计

这种 fail-open 设计通常是为了兼容性考虑：

• 新版本支持新的 JWT 算法
• 旧版本遇到新算法时，不想直接报错
• 开发者认为"跳过验证比拒绝服务更好"
• 但在安全场景中，这是致命的错误

**安全原则：**在认证和授权场景中，永远应该 fail-closed（失败时拒绝），而不是 fail-open（失败时放行）。当验证逻辑出现异常时，默认行为应该是"拒绝访问"，而不是"放行"。

4.3 攻击利用

攻击者利用这个漏洞的步骤：

// 伪造的 JWT
// Header
{
    "alg": "RS512",  // WSO2 配置为只支持 RS256
    "typ": "JWT"
}

// Payload
{
    "sub": "admin",
    "iss": "wso2.org",
    "roles": ["admin"],
    "scopes": "apim:admin"
}

// Signature：任意内容或为空
// 因为 WSO2 发现 RS512 不被支持
// 会跳过签名验证

// 完整的请求：
GET /api/am/admin/apis HTTP/1.1
Host: api-manager.example.com
Authorization: Bearer eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCJ9...

// WSO2 处理：
// 1. 解析 JWT，发现 alg=RS512
// 2. RS512 不在支持列表中
// 3. fail-open：跳过签名验证
// 4. 直接信任 payload 中的 admin 身份
// 5. 返回管理员数据

4.4 影响范围

产品	影响版本	影响程度
WSO2 API Manager	4.1.0 - 4.6.0	完整账户接管
WSO2 Identity Server	多个版本	认证绕过
WSO2 Gateway	相关版本	API 访问控制绕过
多租户部署	------	CVSS 10.0

五、修复方案分析

WSO2 在 2026 年 4 月发布了补丁：

修复项	修复方式
算法验证	不支持的算法直接拒绝
错误处理	验证错误时拒绝访问（fail-closed）
签名强制	所有令牌必须有有效签名
日志记录	记录异常的 JWT 请求

5.1 JWT 安全最佳实践

// JWT 安全检查清单

// 1. 强制使用白名单算法
const allowedAlgs = ['RS256', 'ES256'];
if (!allowedAlgs.includes(header.alg)) {
    throw new Error('Algorithm not allowed');
}

// 2. 禁止 none 算法
if (header.alg === 'none') {
    throw new Error('none algorithm is not allowed');
}

// 3. 始终验证签名
// 不要因为"算法不支持"就跳过验证

// 4. 验证 issuer 和 audience
if (payload.iss !== trustedIssuer) {
    throw new Error('Invalid issuer');
}
if (payload.aud !== expectedAudience) {
    throw new Error('Invalid audience');
}

// 5. 验证过期时间
if (payload.exp < Date.now() / 1000) {
    throw new Error('Token expired');
}

// 6. fail-closed 原则
// 验证失败时，默认拒绝访问

5.2 临时缓解措施

// 1. 升级到最新版本
// 安装 WSO2 2026 年 4 月的累积更新

// 2. 网络隔离
// 不要将 API Manager 暴露在公网
// 放在 VPN 或内网中

// 3. WAF 规则
// 在 WAF 中拦截异常的 JWT 请求
// 检查 alg 字段是否在白名单中

// 4. 监控告警
// 监控异常的管理员登录
// 监控使用不常见算法的 JWT 请求

六、SRC 审计启示录

6.1 JWT 安全审计清单

在 SRC 挖洞过程中，针对 JWT 的审计清单：

#	检查项	检测方法
1	是否使用 JWT 认证	检查 Authorization 头
2	是否强制验证签名	测试 alg=none、空签名
3	是否使用算法白名单	测试各种算法组合
4	是否验证 issuer/audience	篡改这些字段测试
5	错误处理是否 fail-closed	触发各种错误场景测试

6.2 常见 JWT 攻击方式

// 常见 JWT 攻击

// 1. alg=none 攻击
// Header: {"alg": "none", "typ": "JWT"}
// 不签名，直接发送

// 2. 算法混淆攻击
// 从 RS256 改为 HS256
// 用公钥作为 HMAC 密钥

// 3. 弱密钥爆破
// 使用 hashcat 爆破弱 HMAC 密钥

// 4. 未验证签名
// 某些库默认不验证签名

// 5. 不支持算法绕过
// 发送不认识的算法，看是否被跳过验证

6.3 API 网关安全

风险点	常见问题	防护建议
认证机制	JWT 验证不严格	使用成熟的 JWT 库，正确配置
错误处理	fail-open 逻辑	所有验证错误都拒绝访问
暴露面	管理接口暴露在公网	管理接口放在内网
补丁更新	企业软件更新滞后	建立补丁管理流程

七、防护建议

1. 及时升级：安装 WSO2 2026 年 4 月的累积更新
2. 网络隔离：不要将 API Manager 暴露在公网
3. 算法白名单：只允许明确配置的算法
4. fail-closed：验证失败时默认拒绝
5. 监控告警：监控异常的 JWT 请求和管理员登录
6. 定期审计：审计 JWT 配置和日志

八、总结

CVE-2026-5430 是一个典型的"设计错误"导致的严重漏洞。它提醒我们：在安全系统中，错误处理的默认行为非常重要------验证失败时应该拒绝（fail-closed），而不是放行（fail-open）。在 SRC 挖洞实践中，JWT 认证是一个高价值攻击面，特别是"不支持的算法被跳过验证"这种隐蔽的逻辑错误，往往能造成严重后果。

---