Back to Blog
OpsecForge Security TeamAPI SecuritySources reviewed 2026-07-30

CVE-2026-29000: pac4j-jwt Authentication Bypass and Fix

CVE-2026-29000 affects encrypted JWT processing in pac4j-jwt. Check the affected versions, upgrade paths, exposure conditions, and safe validation steps.

Primary source: authoritative reference

What is CVE-2026-29000?

CVE-2026-29000 is an authentication bypass in the JwtAuthenticator component of pac4j-jwt when it processes encrypted JSON Web Tokens (JWEs). In an affected configuration, an attacker who has the server's RSA public key can create a JWE containing an unsigned PlainJWT with attacker-controlled claims. The vulnerable code may accept those claims without the signature verification required to establish authenticity.

The pac4j maintainer advisory says the issue is fixed in:

  • pac4j-jwt 4.5.9 and newer on the 4.x line
  • pac4j-jwt 5.7.9 and newer on the 5.x line
  • pac4j-jwt 6.3.3 and newer on the 6.x line

If your application uses JwtAuthenticator, first identify the exact pac4j-jwt version and whether the application accepts encrypted JWTs. Then upgrade to a fixed release on the supported line you already use.

Severity and exploitation status

The NVD record for CVE-2026-29000 displays a CNA-provided CVSS v4.0 score of 9.3 (Critical) and a CVSS v3.1 score of 9.1 (Critical). NVD has not supplied its own score.

The same record's CISA SSVC data labels exploitation as proof of concept. That label supports prompt patching, but it does not establish real-world attacks or compromise of a particular deployment.

Who is affected?

Treat an application as potentially exposed when all of the following are true:

  1. It uses pac4j-jwt earlier than 4.5.9, 5.7.9, or 6.3.3 on the corresponding release line.
  2. It uses JwtAuthenticator to process encrypted JWTs.
  3. An attacker can submit a token to that authentication path.
  4. The relevant RSA public key is available to the attacker.

Public keys are commonly distributed through certificates or JWKS endpoints, so possession of the public key should not be considered a security boundary.

Applications that do not use pac4j-jwt, do not use JwtAuthenticator, or do not accept encrypted JWTs through the affected path are not described by this CVE. Confirm reachability from application configuration and code rather than assuming that every pac4j deployment is exploitable.

Why the bypass works

JWE provides confidentiality for a token's contents. It does not automatically prove who created those contents.

In the affected flow, an attacker can use the recipient's RSA public key to encrypt a PlainJWT carrying arbitrary subject or role claims. If the application accepts the decrypted claims without requiring a valid inner signature, decryption is mistaken for authentication.

That distinction is fundamental:

  • Decryption proves that a holder of the matching private key could read the ciphertext.
  • Signature verification proves that the token was signed by a trusted issuer using an expected algorithm and key.
  • Claims validation checks whether issuer, audience, time, and token-type constraints match the application's policy.
  • Authorization determines what the authenticated principal may actually do.

Secure JWT handling requires the applicable layers; successful decoding or decryption alone is not validation.

Remediation

1. Upgrade pac4j-jwt

Upgrade to a fixed version on your current supported line:

<dependency>
  <groupId>org.pac4j</groupId>
  <artifactId>pac4j-jwt</artifactId>
  <version>6.3.3</version>
</dependency>

Use a newer compatible release if one is available and supported by your application. Review pac4j's release and migration guidance before moving between major version lines.

2. Confirm that the fixed artifact is deployed

Checking only a source manifest is not enough. Inspect the resolved dependency graph and the artifact shipped in each running application. Look for:

  • transitive dependencies that keep an older pac4j-jwt version
  • container images or deployment bundles built before the upgrade
  • multiple services using different pac4j release lines
  • rollback images that still contain an affected version

3. Review the affected authentication path

Map where JwtAuthenticator is configured and which endpoints accept encrypted JWTs. Confirm that the application requires the intended signed-token structure after decryption and validates:

  • an allowlisted algorithm
  • the expected issuer
  • the intended audience
  • expiration and not-before constraints with a bounded clock skew
  • the expected token type where multiple JWT kinds share an issuer

RFC 8725 recommends explicit algorithm verification, mutually exclusive validation rules for different JWT kinds, and validation of issuer and audience.

4. Investigate with application-specific evidence

Do not search for bearer tokens by dumping them into logs or command pipelines. Tokens are credentials and may contain personal or sensitive claims.

Instead, use the telemetry your application already records safely:

  • resolved application and library version at deployment time
  • authentication outcome and rejection reason without raw tokens
  • issuer, audience, and token type after safe normalization
  • authorization decisions for high-impact actions
  • deployment, identity-provider, and administrative audit logs

Look for successful authentications through the affected JWE path that cannot be reconciled with identity-provider issuance or expected authorization activity. Finding an affected version does not prove exploitation; unexplained successful use of forged claims requires incident response.

5. Respond proportionately

If investigation shows credible unauthorized access:

  1. Contain the affected authentication path.
  2. Preserve relevant logs and deployment artifacts.
  3. Upgrade and redeploy the fixed dependency.
  4. Revoke sessions or credentials that may have been abused.
  5. Review actions taken by the affected principals.
  6. Follow the organization's incident-response and disclosure requirements.

Avoid destructive log cleanup or broad token logging during the investigation.

Can a JWT decoder detect CVE-2026-29000?

No. A decoder can help a developer inspect the structure of a compact JWT, but it cannot establish that pac4j validated a token correctly.

OpsecForge's browser-local JWT Decoder decodes supported JWT header and payload data for inspection. Signature verification, JWE decryption, claims validation, server configuration testing, and CVE exploitation assessment are outside its capabilities. Do not paste production bearer tokens into tools unless your organization's handling policy explicitly permits it.

For broader implementation guidance, see JWT Vulnerabilities: HS256, Algorithm Confusion, and Validation.

References

Share this: