Java 生态里又炸雷了。就在不久前CodeAnt AI 安全研究团队在例行审计中从一款被大量企业采用的认证库 pac4j-jwt 里挖出了一枚核弹级缺陷。漏洞编号CVE-2026-29000CVSS 直接打到满分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限制安全从来不是单点加固而是每一环都不掉链子。当签名校验选择睁一只眼闭一只眼的时候身份认证这扇大门其实就已经敞开了。