Researchers report a maximum‑severity flaw in a Java JWT library

Threat summary 

On March 5, 2026, security researchers disclosed a critical authentication bypass vulnerability in the pac4j-jwt library, rated with a maximum CVSS score of 10.0.

pac4j-jwt is part of the broader pac4j security framework, which many Java applications use (directly or indirectly) to handle login and user identity across platforms such as Spring, Java Enterprise Edition, Vert.x, Play, and Dropwizard.

The flaw, tracked as CVE-2026-29000, affects pac4j-jwt versions prior to 4.5.9, 5.7.9, and 6.3.3. It allows remote users to forge authentication tokens using only the server’s RSA public key, which is typically accessible by design.

Modern applications rely on JSON Web Tokens (JWTs) to keep track of user identity after they log in. JWTs come in two forms: signed tokens (JWS), which prove authenticity, and encrypted tokens (JWE), which hide the token’s contents. Most systems rely only on signed tokens, but pac4j also supports encrypted JWTs.

This distinction is significant because the vulnerability is triggered specifically when pac4j processes encrypted JWTs. A flaw in the JWE handling logic causes the library to accept a JWE-wrapped token that contains no valid signature, allowing an attacker to present an unsigned token that the application treats as legitimate.

The vulnerability originates in the JwtAuthenticator component, which fails to enforce signature validation on these JWE‑wrapped tokens. As a result, a threat actor could create a fake token that claims to be any user, including an administrator, and the application will trust it. This leads to full authentication bypass without requiring a password or valid credentials.

As of March 5, there are no confirmed reports of active exploitation, and vendor patches are available in pac4j-jwt versions 4.5.9, 5.7.9, and 6.3.3.

Field Effect has completed an internal review and confirmed that pac4j is not used within our portal and is not affected by this vulnerability.

Analysis

This vulnerability is unusual because it does not rely on breaking encryption or guessing secrets. Instead, it exploits how pac4j handles encrypted JWTs.

In a typical JWT-based system, an attacker would need the private key or would have to exploit a configuration mistake to forge a valid token. In this case, the attacker needs only the public key, which is normally exposed through certificates or JSON Web Key Set endpoints and is not considered sensitive.

The key factor is whether the application accepts encrypted JWTs and passes them to pac4j for processing. The flaw is triggered only during JWE handling, where pac4j incorrectly treats a JWE‑wrapped unsigned token as valid. If the application supports JWE, a crafted encrypted token can reach the vulnerable logic and be accepted as authentic.

Although pac4j itself is not directly exposed on the network, it's widely embedded inside Java apps. Shodan and other external scanning tools thus show limited visibility; the library is present in many deployments but not detectable from the outside. What matters from an attacker’s perspective is not whether pac4j is visible, but whether they can reach any public endpoint that uses JWTs. These endpoints are easy to identify through headers, redirects, or metadata.

If such an endpoint accepts encrypted tokens, a forged JWE can pass through upstream components and reach pac4j. Once processed, the attacker can impersonate any user, escalate to administrative roles, and take full control of the application. Depending on how much internal access the application has, this can also enable lateral movement or access to downstream systems that rely on the compromised application for identity or authorization.

The impact across the ecosystem depends on how each project incorporates pac4j-jwt. Frameworks that package the library within their own distributions will need to publish updated releases so that downstream users receive the fix. Most other projects can resolve the issue simply by updating the dependency in their build configuration.

This creates a mixed update path: some platforms will coordinate formal patch releases, but many deployments remain exposed because they continue running an outdated, bundled version of pac4j-jwt that cannot be upgraded automatically and requires a full application or platform update to remove the vulnerable code path.

Mitigations

Field Effect MDR clients would have received an ARO if the affected software had been identified within their environment. Our team continues to monitor for evidence of exploitation and deploy new network- and endpoint-based rules to detect malicious activity associated with this vulnerability.

Addressing CVE-2026-29000 requires both updating affected components and tightening how applications handle JWTs:

• Upgrade pac4j‑jwt to a fixed version (4.5.9, 5.7.9, or 6.3.3) across all services, including transitive dependencies.
• Ensure any platforms or frameworks that bundle pac4j-jwt, such as identity servers or SSO products, are updated to their patched releases.
• Disable or restrict JWE support unless encrypted JWTs are explicitly required, since most environments rely only on signed tokens.
• Enforce strict signature validation so unsigned, algorithm-mismatched, or unverifiable tokens are rejected at the application boundary.
• Harden upstream components (API gateways, reverse proxies, service meshes) to allow only properly signed JWTs to reach internal services.
• Rotate signing keys after patching to invalidate any previously issued or potentially forged tokens.
• Require reauthentication for active sessions to ensure no vulnerable tokens remain in circulation.
• Review authentication and administrative logs for activity that lacks corresponding identity provider events.

Stay on top of emerging threats like this.

Sign up to receive a weekly roundup of our security intelligence feed. You'll be the first to know of emerging attack vectors, threats, and vulnerabilities. 

Sign up