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 的团队，请对照下表立即升级：
表格
| 当前分支 | 建议升级版本 |
|---|---|
| 4.x 系列 | 4.5.9 及以上 |
| 5.x 系列 | 5.7.9 及以上 |
| 6.x 系列 | 6.3.3 及以上 |
CodeAnt AI 团队已经在官方博客放出了完整的技术分析与可复现的 PoC。安全团队可以拿来做内部验证，确认自己的系统是否存在类似配置风险。
事后反思：加密≠可信，签名才是底线
这次事件给所有使用 JWT 的架构师提了个醒：JWE 解决的是"防偷窥"，JWS 解决的是"防篡改"。两者职责不同，绝不能互相替代。
很多开发者在配置 JWT 时，看到启用了加密就觉得"已经很安全了"，于是在签名校验上放松要求，甚至允许无签名令牌通过。CVE-2026-29000 用最极端的方式证明了这种配置的致命性。
补丁打上之后，建议再做一轮配置审计：
强制要求所有 JWT 必须携带有效签名，拒绝任何形式的 PlainJWT
检查
JwtAuthenticator或同类组件的校验逻辑，确认签名失败时直接抛异常而非降级处理梳理公钥暴露面，评估是否需要额外的令牌来源校验（如
iss、aud限制）
安全从来不是单点加固，而是每一环都不掉链子。当签名校验选择"睁一只眼闭一只眼"的时候，身份认证这扇大门，其实就已经敞开了。
