The Null-Signature Trap: Unmasking the 10.0 CVSS Authentication Bypass in pac4j-jwt

A critical vulnerability has been unearthed within the widely utilized Java authentication library, pac4j-jwt, empowering a malicious actor to masquerade as any system user, administrators included. This severe flaw has been designated the identifier CVE-2026-29000, garnering the maximum peril rating of 10.0 on the CVSS scale.

The defect was brought to light by the CodeAnt AI vanguard whilst scrutinizing alterations within open-source repositories. Their rigorous audit revealed that a remote assailant possesses the capability to forge a spurious JSON Web Token laden with arbitrary data, thereby circumventing authentication protocols entirely bereft of access to private keys, passwords, or clandestine secrets.

Under conventional operational paradigms, pac4j-jwt fortifies tokens utilizing a dual-layered defense matrix. Initially, encryption is deployed to obfuscate the payload; subsequently, a cryptographic signature validates the data’s immutable authenticity. Upon the server’s receipt of the token, the architecture first decrypts the exterior carapace before rigorously verifying the signature.

The forensic analysis laid bare a fundamental flaw in the handling of unsigned tokens. Should an adversary forge a so-called PlainJWT—a token entirely devoid of a digital signature—and cryptographically seal it utilizing the server’s public RSA key, the library catastrophically fails to recognize the artifact as signed. Consequently, an anomalous null value manifests during the processing phase.

Owing to the calamitous misplacement of the validation logic for this specific value within the application’s source code, the signature verification apparatus is bypassed in its entirety. Rather than summarily discarding the invalid token, the system proceeds unabated, ingesting the unverified telemetry. Consequently, an assailant is granted the latitude to inject any desired privilege tier into the token—such as the “admin” role—encrypt the payload with the server’s public key, and usurp absolute dominion over the system. The server tragically embraces the contents as unimpeachably trusted, utterly neglecting to authenticate their provenance.

This affliction specifically imperils architectures wherein RSA-encrypted tokens are deployed in tandem with the JwtAuthenticator component. Following a clandestine disclosure, the library’s architect, Jérôme Leleu, swiftly corroborated the anomaly and promulgated remediations across multiple developmental branches. The orchestration of these vital updates required a mere two business days.

Software engineers leveraging pac4j-jwt are vehemently exhorted to upgrade their dependencies with the utmost urgency. Within the 4.x lineage, versions 4.5.9 and subsequent iterations are deemed secure; for the 5.x lineage, safety is assured from 5.7.9 onwards; and for the 6.x lineage, version 6.3.3 and above are fortified. Auditing for this vulnerability can be executed via package managers and through the meticulous parsing of application configurations that concurrently invoke both the encryption and cryptographic signing of tokens.