pac4j-jwt JwtAuthenticator Authentication Bypass (CVE-2026-29000)

A critical vulnerability (CVE-2026-29000) has been disclosed in pac4j-jwt, a widely used Java authentication library. Under impacted conditions, an attacker may be able to bypass authentication entirely and impersonate any user—including administrators.

This is an identity-layer vulnerability: if a vulnerable service is exposed (directly or indirectly) to untrusted tokens, the attacker’s forged identity can cascade into broader privilege and data access across downstream applications.

At a glance

• What it is: Authentication bypass in JwtAuthenticator while processing encrypted JWTs (JWE)
• Why it’s dangerous: An attacker who has the server’s RSA public key may be able to craft tokens with arbitrary subject/roles and be treated as authenticated
• What to do now: Upgrade immediately to patched releases for your major line

Affected versions and fixed releases

The pac4j maintainer has published a security advisory requiring immediate upgrades:

If you operate multiple services, prioritize upgrades for:

• Internet-facing authentication endpoints
• API gateways and shared auth middleware
• SSO entry points and services that mint/validate JWTs for other systems

Technical summary (what attackers can do)

According to the CVE description, vulnerable versions allow remote attackers to forge authentication tokens when JwtAuthenticator processes encrypted JWTs (JWE). An attacker who possesses the server’s RSA public key can create a JWE-wrapped “PlainJWT” with arbitrary subject and role claims, resulting in signature verification being bypassed and enabling login as any user (including admins).

Independent technical analysis aligns with this: certain configurations that combine JWE decryption with additional signature configuration can lead to a logic path where attacker-controlled claims are treated as trusted identity data.

Why “public key only” matters

In many JWT ecosystems, public keys are intentionally distributed (for example via JWKS endpoints or published certificates). This vulnerability’s impact is amplified because the attacker may not need to steal a secret—only obtain a key that is often meant to be accessible.

Who is most at risk

You are more likely to be exposed if all of the following are true:

1. You use org.pac4j:pac4j-jwt and JwtAuthenticator for authentication, and
2. Your services accept encrypted JWTs (JWE) (not only signed JWS), and
3. You use RSA-based encryption and rely on JwtAuthenticator to validate identity/roles from token claims

Even if you’re unsure whether you accept JWE today, treat this as urgent—many stacks inherit token handling behavior through shared auth components, framework defaults, or transitive dependencies.

How to check if you use pac4j-jwt

Maven

mvn -q dependency:tree | grep -i pac4j-jwt

Gradle

./gradlew dependencies | grep -i pac4j-jwt

Also search your codebase for:

• JwtAuthenticator
• pac4j-jwt
• JWE / “encrypted JWT”

How to remediate (recommended path)

1) Upgrade to a fixed version (best option)

Update pac4j-jwt to a patched release in your major line: 4.5.9+, 5.7.9+, or 6.3.3+.

Maven example

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

Gradle example

implementation "org.pac4j:pac4j-jwt:6.3.3"

If you manage versions centrally (BOM/dependencyManagement), ensure you’re not pinning an older pac4j-jwt transitively.

2) Validate the fix in your environment

After upgrading:

• Run authentication tests for both normal users and privileged roles
• Confirm token validation paths behave as expected for JWE/JWS inputs
• Regression-test any SSO integrations or gateways that share token validation logic

Short-term mitigations (if you cannot upgrade today)

Upgrading is the vendor-recommended action. If you need temporary risk reduction while scheduling an emergency patch window, consider:

• Disable acceptance of encrypted JWTs (JWE) where feasible and use signed JWTs (JWS) only
• Add compensating controls for privileged actions (step-up auth, stricter authorization checks, session binding)
• Restrict exposure of token-validation endpoints (network-level protections, gateway rules), especially if any endpoints accept tokens directly from untrusted clients

These mitigations are environment-specific and may not fully eliminate risk—patching remains the priority.

Detection and response guidance

Because this issue can present as a “valid” login (with attacker-chosen roles), detection often relies on behavioral signals rather than obvious errors.

Review logs for:

• Sudden elevation to admin roles without corresponding identity provider events
• Unusual spikes in successful auth events or token-based sessions
• Access patterns inconsistent with the user’s historical behavior (new geos, user agents, impossible travel)
• Privileged actions performed shortly after new sessions are established

If you suspect compromise:

• Rotate credentials/secrets associated with downstream services that trust JWT claims
• Invalidate sessions and re-issue tokens after patching
• Consider incident response scoping for administrative actions during the exposure window

Timeline

• March 2026: pac4j publishes a security advisory instructing users to upgrade to fixed versions
• March 4, 2026: NVD publishes the CVE record (awaiting NVD enrichment/analysis), showing CNA-provided CVSS 10.0 vectors

FAQ