CVE-2026-29000: pac4j-jwt Authentication Bypass Vulnerability

CVE-2026-29000 Overview

CVE-2026-29000 is a critical authentication bypass vulnerability affecting pac4j-jwt, a popular Java security library used for JWT (JSON Web Token) authentication. The vulnerability exists in the JwtAuthenticator component when processing encrypted JWTs, allowing remote attackers to forge authentication tokens and bypass security controls entirely.

Attackers who possess the server's RSA public key—which is often publicly accessible or easily obtainable—can craft a JWE-wrapped PlainJWT containing arbitrary subject and role claims. This allows complete bypass of signature verification, enabling authentication as any user including administrators without valid credentials.

Critical Impact

Remote attackers can forge authentication tokens to impersonate any user, including administrators, by exploiting improper verification of cryptographic signatures in encrypted JWTs. This vulnerability allows complete authentication bypass with network access only.

Affected Products

• pac4j-jwt versions prior to 4.5.9
• pac4j-jwt versions prior to 5.7.9
• pac4j-jwt versions prior to 6.3.3

Discovery Timeline

• 2026-03-04 - CVE-2026-29000 published to NVD
• 2026-03-05 - Last updated in NVD database

Technical Details for CVE-2026-29000

Vulnerability Analysis

This vulnerability is classified under CWE-347 (Improper Verification of Cryptographic Signature), representing a fundamental flaw in how the pac4j-jwt library validates encrypted JWT tokens. The JwtAuthenticator fails to properly verify the cryptographic signature when processing JWE (JSON Web Encryption) tokens that wrap PlainJWT payloads.

The attack exploits the library's trust model around encrypted tokens. When a JWT is encrypted with the server's RSA public key, the library assumes the token content is trustworthy after successful decryption. However, this assumption is flawed because RSA public keys are designed to be publicly available—any party can encrypt data with a public key.

An attacker can construct a malicious token by creating a PlainJWT (an unsigned JWT) with arbitrary claims such as elevated roles or admin privileges, then encrypting this unsigned token using the target server's public key. When the server decrypts this JWE, it processes the PlainJWT payload without verifying a cryptographic signature, accepting the forged claims as legitimate.

Root Cause

The root cause lies in the JwtAuthenticator component's failure to enforce signature verification on the inner JWT payload after decryption of JWE tokens. The library incorrectly treats successful JWE decryption as sufficient proof of token authenticity, ignoring the critical distinction between encryption (confidentiality) and signing (authenticity/integrity).

Proper JWT security requires that tokens be cryptographically signed to prove they originated from a trusted issuer. By accepting PlainJWT payloads inside encrypted containers, the library allows attackers to bypass this fundamental security control.

Attack Vector

The attack is network-based and requires no user interaction or prior authentication. An attacker needs only to obtain the server's RSA public key, which is typically:

1. Published in JWKS (JSON Web Key Set) endpoints
2. Embedded in application configurations
3. Derivable from TLS certificates
4. Available through other public channels

Once the public key is obtained, the attacker constructs a JWE token containing a PlainJWT with desired claims (e.g., "role": "admin", "sub": "administrator"), encrypts it using the server's public key, and submits it as their authentication token. The server decrypts the JWE successfully and processes the PlainJWT claims without signature verification, granting the attacker unauthorized access.

The vulnerability mechanism involves three key steps: First, the attacker creates an unsigned JWT (PlainJWT) with arbitrary identity claims. Second, this PlainJWT is wrapped in a JWE envelope using the target's RSA public key. Third, upon receiving the token, the vulnerable JwtAuthenticator decrypts the JWE and processes the PlainJWT without validating any cryptographic signature, accepting the forged claims as authentic. For detailed technical analysis, see the Codeant AI Security Research and Pac4j Security Advisory.

Detection Methods for CVE-2026-29000

Indicators of Compromise

• Presence of JWT tokens with alg: none in the header after JWE decryption
• Authentication logs showing successful logins for privileged accounts from unusual IP addresses or locations
• Anomalous JWT tokens that decrypt successfully but contain no valid signature components
• Unexpected administrative actions performed by accounts that should not have elevated privileges

Detection Strategies

• Implement logging that captures JWT algorithm types and flag any tokens using alg: none or PlainJWT structures
• Monitor authentication systems for sudden privilege escalation patterns or lateral movement
• Deploy Web Application Firewall (WAF) rules to inspect JWT token structures before processing
• Review application logs for authentication events that bypass normal signature verification paths

Monitoring Recommendations

• Enable verbose logging on JWT authentication components to capture full token processing details
• Set up alerts for authentication attempts using encrypted tokens from external or untrusted sources
• Monitor for bulk authentication attempts that may indicate automated exploitation
• Track RSA public key access patterns and downloads from JWKS endpoints

How to Mitigate CVE-2026-29000

Immediate Actions Required

• Upgrade pac4j-jwt to version 4.5.9, 5.7.9, or 6.3.3 or later immediately
• Audit existing authentication logs for signs of exploitation
• Review all user sessions and invalidate tokens that may have been forged
• Implement additional authorization checks at the application layer as defense in depth

Patch Information

Security patches are available for all affected version branches. Organizations should upgrade to the following minimum versions:

For detailed patch information and upgrade guidance, refer to the Pac4j Security Advisory and Vulncheck Advisory.

Workarounds

• If immediate patching is not possible, configure JwtAuthenticator to explicitly reject tokens with alg: none
• Implement a pre-validation filter that rejects PlainJWT structures before they reach the authenticator
• Add network-level controls to restrict authentication endpoints to trusted sources only
• Consider temporarily disabling JWE token support if only signed JWTs are required for your use case

# Example: Check current pac4j-jwt version in Maven projects
mvn dependency:tree | grep pac4j-jwt

# Update dependency in pom.xml to patched version (example for 6.x branch)
# <dependency>
#     <groupId>org.pac4j</groupId>
#     <artifactId>pac4j-jwt</artifactId>
#     <version>6.3.3</version>
# </dependency>