How can a public key break JWT authentication in pac4j?

A public key can break pac4j-jwt authentication because, in affected versions, the library accepted an encrypted token whose inner payload was unsigned. Encryption with a public key proves nothing about who sent it. Upgrade to 4.5.9, 5.7.9 or 6.3.3 or newer, then review how your code validates tokens.

What is CVE-2026-29000?

CVE-2026-29000 is an authentication bypass in JwtAuthenticator, part of the pac4j-jwt module. The NVD entry says versions before 4.5.9, 5.7.9 and 6.3.3 mishandle encrypted JWTs, so a remote attacker can forge tokens with any subject and role claims, including an administrator's. The weakness is classed as CWE-347, improper verification of a cryptographic signature.

The project's own advisory is short. It says you must upgrade on the 4.x, 5.x and 6.x lines to the versions above, and it withholds further detail. The advisory credits an outside research team for the find.

One caution on scoring. At the time of writing, NVD lists the record's status as Deferred, and the only CVSS 4.0 score shown, 9.3 Critical, was supplied by the CNA, not by NVD itself. Treat the number as a hint to patch quickly, not as your risk rating.

Why does a public key matter here?

A JWT can be signed, encrypted, or both. They answer different questions. A signature says who made the token and that nobody changed it. Encryption says only the holder of a private key can read it.

In RSA based JWE, the sender encrypts the content key with the recipient's public key. That key is meant to be shared. So anyone who has it can produce a validly encrypted token. If the server then treats "decrypted successfully" as "authentic", the whole trust model collapses, because decryption success is available to every person on the internet.

The NVD description says the forged token wraps a plain, unsigned JWT inside the encryption layer, and that the library did not enforce signature verification on the inner token. The fix is not a new key. Rotating the RSA pair would not have helped, since the new public key is just as public.

RFC 8725, the JWT best current practice, states the rule that applies: all cryptographic operations in a JWT must be validated, and for nested JWTs both the outer and inner operations must be validated with keys and algorithms the application supplies. It also says libraries should not consume tokens using the "none" algorithm unless the caller explicitly asks for it.

How do you find out whether you are exposed?

Start with inventory. pac4j can arrive as a transitive dependency, so a search of your own build file can miss it. Check the resolved dependency tree, and check container images and fat JARs that were built months ago.

Then check how you use it. Applications that use pac4j only for session cookies or OAuth login without a JWT authenticator are in a different position from those that accept encrypted JWTs on an API. Do not rely on that reading alone. Upgrade everything that contains the module.

How to check or apply this

1. List every service that includes pac4j-jwt, directly or transitively, in source, built artifacts and running images.
2. Compare each version to the fixed releases: 4.5.9, 5.7.9 or 6.3.3, or newer on the same line.
3. Upgrade, rebuild and redeploy. A patched repository does not fix a stale image.
4. Review authentication logs from before the upgrade for administrator or privileged sessions you cannot tie to a real login. Tokens for forged users would carry whatever claims the attacker chose.
5. In your own token handling, require a signature on the inner token, pin accepted algorithms, reject "none", and validate issuer and audience as RFC 8725 describes.
6. Add a test that sends an unsigned token inside an encrypted wrapper and asserts that it is rejected.

Where does Safeguard fit?

Step 1 is the slow part for most teams. Safeguard builds an SBOM and scans dependencies across a repository, and reachability analysis helps separate services that actually call the vulnerable authenticator from those that only bundle it. You still need to patch both, but you can order the work.

Quick check

Sources

• NVD record for CVE-2026-29000
• pac4j security advisory for JwtAuthenticator
• GitHub advisory GHSA-pm7g-w2cf-q238
• RFC 8725, JSON Web Token Best Current Practices
• RFC 7516, JSON Web Encryption

Last reviewed: 18 October 2026.