CodeAnt AI Security Research Mar 3, 2026 CEO, CodeAnt AI What if the key you're supposed to share with the world is the only thing an attacker needs to impersonate any user on your system - including admin? That's what we found in pac4j-jwt, a widely used Java authentication library. CVE-2026-29000 has been assigned to this vulnerability with a CVSS score of 10.0 Critical. A complete authentication bypass. An attacker with nothing more than your server's RSA public key - the key that'sdesignedto be public - can forge a JWT token with arbitrary claims and authenticate as any user, with any role, without knowing a single secret. The patch is now live. The maintainer, Jérôme Leleu, confirmed, patched, and published asecurity advisorycrediting our research. If you use pac4j-jwt, stop reading and update: 4.x line:upgrade to 4.5.9 or newer 5.x line:upgrade to 5.7.9 or newer 6.x line:upgrade to 6.3.3 or newer Now, here's how we found it - and how it works. We've been running an internal research project at CodeAnt AI. The premise is simple: when a CVE is patched in a popular open-source package, does the patch actually fix the vulnerability? Not whether the patch exists. Not whether the version number was bumped. Whether the code change actually addresses the problem. We started by running ourAI code revieweracross packages with prior CVEs, scanning patch diffs and the surrounding code paths. During that analysis, the AI reviewer flagged an anomaly: a null check onsignedJWTthat sat directly in front of the signature verification block, and appeared to create a condition where verification could be silently skipped. Our security engineer reviewed the flag, traced the execution path, and confirmed: this is a true positive. It was a complete authentication bypass. Before we get to what we found, let's walk through how pac4j-jwt is supposed to handle tokens. Understanding the intended flow makes the bypass obvious. Most production pac4j deployments use two layers of protection: Layer 1 - Encryption (JWE).The JWT is encrypted using the server's RSA public key. This ensures the token's contents can't be read in transit. Only the server, which holds the private key, can decrypt it. Layer 2 - Signature (JWS).Inside the encrypted wrapper, the JWT is signed. This ensures the token was created by someone who holds the signing key. The server verifies this signature after decryption. The flow looks like this: Both layers must pass. Encryption alone doesn't prove who created the token - it just proves the contents are private. Signature verification is what proves the token is legitimate.