CVE-2026-29000: How a Public Key Breaks Authentication in pac4j-jwt

A critical authentication bypass in the Java security library pac4j-jwt allows attackers to impersonate any user, including administrators, using nothing more than a server's RSA public key. The vulnerability, tracked as CVE-2026-29000, carries a CVSS 10.0 score and affects all versions of org.pac4j:pac4j-jwt prior to 4.5.9, 5.7.9, and 6.3.3.

The flaw is straightforward to exploit. A public proof-of-concept exists, and patched versions are available now. If your Java application uses pac4j for JWT-based authentication, keep reading.

TL;DR

What is pac4j?

pac4j is a security framework for Java that provides authentication and authorization across multiple protocols: OAuth, SAML, CAS, OpenID Connect, and JWT. The pac4j-jwt module specifically handles JSON Web Token creation and validation through its JwtAuthenticator class.

pac4j can be used as the underlying authentication engine in frameworks like Spring Security, JEE, Play, Vert.x, and others. It is also widely deployed in CAS (Central Authentication Service) environments, which are common in universities and government institutions. If your application uses any pac4j-based authentication with JWTs, it may be affected.

How the vulnerability works

To understand this vulnerability, you need to know the difference between two types of JWTs:

• JWS (JSON Web Signature): A signed token. The signature proves the token hasn't been tampered with and was created by someone with the signing key.

• JWE (JSON Web Encryption): An encrypted token. The encryption protects the token's contents from being read in transit. JWE can wrap a JWS inside it for both confidentiality and integrity.

When pac4j's JwtAuthenticator receives an encrypted JWT (JWE), it follows this process:

1. Decrypt the outer JWE envelope

2. Parse the inner payload

3. Verify the signature on the inner token

The vulnerability is in step 3. After decrypting the JWE, the library calls com.nimbusds:nimbus-jose-jwt function toSignedJWT() on the inner payload to extract the signed token for verification. If the inner token is a PlainJWT (a JWT with alg: none, meaning no signature at all), this method returns null.

In the vulnerable code, this null value caused the entire signature verification block to be skipped. The library effectively said: "I can't find a signature to verify, so I'll just move on."

Here's a simplified view of the vulnerable logic:

// (after JWE decryption succeeds above)
SignedJWT signedJWT = encryptedJWT.getPayload().toSignedJWT();

// If inner token is PlainJWT, signedJWT is null
if (signedJWT != null) {
    jwt = signedJWT;
}

// Signature verification only runs if signedJWT is not null
if (signedJWT != null && !signatureConfigurations.isEmpty()) {
    // Verify signature... but this block is NEVER entered
    // for a PlainJWT wrapped in JWE
}

// Claims are extracted regardless — attacker is now "authenticated"
createJwtProfile(ctx, credentials, jwt);

The fix adds an explicit rejection when a non-signed token is found inside an encrypted envelope:

if (!signatureConfigurations.isEmpty()) {
    if (signedJWT == null) {
        throw new CredentialsException(
            "A non-signed JWT cannot be accepted...");
    }
    // Proceed with normal signature verification
}

The attack in practice

An attacker needs only one thing: the server's RSA public key. By definition, public keys are... public. They're often embedded in JWKS endpoints, certificates, or configuration files.

The attack steps:

1. Obtain the server's RSA public key (from a JWKS endpoint, TLS certificate, or any public source)

2. Create a PlainJWT with arbitrary claims:

{
  "sub": "admin",
  "role": "ADMIN",
  "exp": 1772611200
}

1. Wrap it in a JWE encrypted with the server's RSA public key

2. Send the forged token to the application

3. The application decrypts the JWE (the public key encryption is valid), finds no signature to verify, skips verification, and accepts the forged claims as authentic

The attacker never needs the private key, a shared secret, or any credentials. The public key that was supposed to protect the system is the only ingredient required.

Who is affected

You are potentially affected if:

• You are using RSA encryption. This is detectable by RSAEncryptionConfiguration in the project.

• Your application uses org.pac4j:pac4j-jwt for JWT authentication

• You use both encryption (JWE) and signature verification (JWS) configurations in your JwtAuthenticator

• You are running any version prior to 4.5.9, 5.7.9, or 6.3.3

Applications that only use signed JWTs (JWS) without encryption are not vulnerable to this specific attack, as the PlainJWT-inside-JWE trick requires encryption to be configured.

Check with Snyk

You can check whether your project is affected using the Snyk CLI:

# For Maven projects
snyk test --maven

# For Gradle projects
snyk test --gradle

Snyk tracks this vulnerability as SNYK-JAVA-ORGPAC4J-15428218. If the vulnerable package is in your dependency tree, Snyk will flag it and recommend the upgrade path.

If you use Maven, the Snyk Maven plugin can also catch this as part of your build cycle without requiring a separate CLI step. For Gradle projects, the Snyk Gradle plugin provides the same integrated scanning capability.

You can also search your dependencies directly:

# Check if pac4j-jwt is in your dependency tree
mvn dependency:tree | grep pac4j-jwt

# Or with Gradle
gradle dependencies | grep pac4j-jwt

Remediation

Upgrade org.pac4j:pac4j-jwt to the patched version for your major version line:

For Maven, update your pom.xml:

<!-- For pac4j 6.x -->
<dependency>
    <groupId>org.pac4j</groupId>
    <artifactId>pac4j-jwt</artifactId>
    <version>6.3.3</version>
</dependency>

For Gradle:

// For pac4j 6.x
implementation 'org.pac4j:pac4j-jwt:6.3.3'

If you can't upgrade immediately

While upgrading is strongly recommended, you can reduce your exposure by:

1. Reviewing your JWT configuration: If your application only uses signed JWTs (JWS) without encryption, you're not vulnerable to this specific attack path. However, upgrading is still the safest course of action.

2. Auditing JWT-handling code: Ensure your application explicitly requires signed tokens and rejects unsigned ones at the application layer.

There is no configuration-level workaround within pac4j itself for the vulnerable versions.

Why this matters beyond pac4j

This vulnerability is a textbook example of a broader class of JWT implementation flaws. The core issue, treating the absence of a security property (a signature) as something to skip rather than something to reject, has appeared in JWT libraries across languages for years.

The lesson is consistent: cryptographic verification must be required, not optional. When a library encounters an unsigned token where a signed one is expected, the only safe response is rejection. Silent fallthrough is a vulnerability waiting to happen. For a deeper dive into how authentication flaws like this manifest, explore the Broken Authentication lesson on Snyk Learn.

For Java teams, this is a reminder to:

• Explicitly configure accepted algorithms in your JWT validation. Never allow none.

• Treat encryption and signing as independent concerns. Decryption proves confidentiality, not authenticity. A JWE-wrapped token still needs its signature verified.

• Regularly audit transitive dependencies. pac4j-jwt might be pulled in by a framework integration you don't directly manage. See Best Practices for Managing Java Dependencies for guidance on auditing your dependency tree.

For more on secure JWT handling practices, see Top 3 Security Best Practices for Handling JWTs and Can Snyk Detect JWT Security Issues? on the Snyk blog.

Timeline