pac4j-jwt 曝致命漏洞：RSA公钥竟成伪造管理员身份的“通行证“，数万 Java 应用面临全面沦陷

Java 生态里又炸雷了。

就在不久前，CodeAnt AI 安全研究团队在例行审计中，从一款被大量企业采用的认证库 pac4j-jwt 里挖出了一枚"核弹级"缺陷。漏洞编号CVE-2026-29000，CVSS 直接打到满分10.0。这意味着攻击者不需要偷私钥、不需要内网跳板，手里只要有服务器那张公开的 RSA 公钥，就能凭空造出一张管理员通行证，长驱直入。

目前该库支撑着成千上万套系统的身份认证与权限管控。消息一出，社区瞬间紧张起来。

漏洞核心：JWE 解密后，签名校验"睡着了"

很多开发团队对 JWT 的使用存在一个惯性认知：令牌只要加密了（JWE），内容就是可信的。签名（JWS）那套东西，似乎只是"锦上添花"的完整性校验。

pac4j-jwt 的JwtAuthenticator组件恰恰栽在这个思维盲区里。

正常的安全逻辑应该是这样的：服务器收到令牌 → 解密 JWE 外壳 → 取出内部 JWT → 校验签名是否合法 → 提取用户身份。这四步环环相扣，缺一步都得报警。

但问题就出在那个toSignedJWT()函数上。当攻击者往 JWE 壳子里塞的是一个未签名的 PlainJWT时，这个函数解密后会老老实实返回一个null——因为它确实找不到签名。按理说，这时候校验模块应该立刻阻断请求。

然而代码里的签名校验环节只做了一个简单的null判断。看到null，它没有报错，而是直接跳过，仿佛在说："哦，没签名啊，那算了，继续走吧。"

于是，库直接拿令牌里那些未经任何验证的声明字段（subject、role 等）去创建用户档案。攻击者在 PlainJWT 里填什么身份，系统就认什么身份。

攻击链路：三步拿到管理员权限

这个漏洞的利用门槛低到令人不安。

第一步，构造恶意令牌。攻击者随便写一个 PlainJWT，把sub改成admin，把role改成ROLE_ADMIN。不需要知道服务器私钥，因为这一步根本不涉及签名。

第二步，套壳加密。用服务器公开暴露的 RSA 公钥（很多系统为了方便客户端验证，公钥就挂在.well-known接口或配置中心）把刚才的 PlainJWT 包进 JWE 容器。从外面看，这是一段标准的加密令牌，毫无破绽。

第三步，投递利用。把这段 JWE 发往目标系统的登录或认证接口。服务器解密后，内部 PlainJWT 因无签名被toSignedJWT()返回null，签名校验静默跳过，系统直接读取 claims 并生成管理员会话。

整个过程不需要爆破、不需要社工、不需要任何前置权限。一张公钥，一行脚本，就能让企业的身份认证体系形同虚设。

危害不止于"进后台"

表面上看，这是一个认证绕过漏洞。但结合企业实际架构来看，它的破坏力会迅速放大。

系统完全沦陷只是起点。一旦拿到管理员凭证，攻击者可以下载数据库、篡改配置、创建高权限账号，甚至植入持久化后门。更棘手的是横向渗透——很多企业内网的微服务之间采用 JWT 进行服务间信任传递。伪造的管理员令牌很可能成为在内网"漫游"的万能钥匙，把单点突破变成全面失陷。

由于 pac4j-jwt 在 Java 安全领域应用极广，金融、政务、电商等重度依赖 Java 技术栈的行业都需要紧急排查。

修复方案：立刻升级，别犹豫

pac4j 维护者 Jérôme Leleu 已经确认漏洞存在，并在所有活跃分支中发布了补丁。修复逻辑并不复杂：在签名校验环节补上严格的非空检查，确保null结果直接触发异常，而不是被默默放行。

还在用 pac4j-jwt 的团队，请对照下表立即升级：

表格

CodeAnt AI 团队已经在官方博客放出了完整的技术分析与可复现的 PoC。安全团队可以拿来做内部验证，确认自己的系统是否存在类似配置风险。

事后反思：加密≠可信，签名才是底线

这次事件给所有使用 JWT 的架构师提了个醒：JWE 解决的是"防偷窥"，JWS 解决的是"防篡改"。两者职责不同，绝不能互相替代。

很多开发者在配置 JWT 时，看到启用了加密就觉得"已经很安全了"，于是在签名校验上放松要求，甚至允许无签名令牌通过。CVE-2026-29000 用最极端的方式证明了这种配置的致命性。

补丁打上之后，建议再做一轮配置审计：

• 强制要求所有 JWT 必须携带有效签名，拒绝任何形式的 PlainJWT

• 检查JwtAuthenticator或同类组件的校验逻辑，确认签名失败时直接抛异常而非降级处理

• 梳理公钥暴露面，评估是否需要额外的令牌来源校验（如iss、aud限制）

安全从来不是单点加固，而是每一环都不掉链子。当签名校验选择"睁一只眼闭一只眼"的时候，身份认证这扇大门，其实就已经敞开了。