Author here. We're the CodeAnt AI security research team.

We've been auditing patch code in popular open-source packages - not scanning, not checking databases, but reading the actual fixes and asking: does this patch really close the vulnerability, or just the specific path that was reported?

pac4j-jwt was one of the first packages we looked at.

The bug: when JwtAuthenticator is configured with both JWE encryption and JWS signature verification, an attacker can wrap a PlainJWT (unsigned) inside a JWE encrypted with the server's RSA public key. After decryption, toSignedJWT() returns null for the PlainJWT. The entire signature verification block is gated on `if (signedJWT != null)` - so it's silently skipped. createJwtProfile() runs with the attacker's unverified claims.

The irony: every individual piece of code is correct. toSignedJWT() correctly returns null for non-JWS payloads. The null check is syntactically correct. The vulnerability is in the composition - the assumption that a decrypted JWE payload will always be a signed JWT. The JWT spec says otherwise. PlainJWT is a valid token type.

Full PoC in the post. It runs against pac4j-jwt 6.0.3 and authenticates as admin on the first try.

The maintainer, Jérôme Leleu, was exceptional. Two business days from private disclosure to patches shipped across three major version lines (4.5.9, 5.7.9, 6.3.3). Advisory published with credit. That's how responsible maintenance looks - worth calling out because it's rare.

Happy to answer technical questions.

Part of CodeAnt team - one thing we appreciated in this process was how quickly the maintainer responded.

In security disclosures, the technical bug is one thing. The responsiveness and clarity of communication are just as important. Shipping coordinated fixes across multiple major versions in two days is not trivial.

Regardless of the bug itself, the handling here is worth highlighting.