CVE-2026-29000 in pac4j-jwt, an identity bypass hiding behind encryption

CVE-2026-29000 is a critical authentication bypass in pac4j-jwt’s JwtAuthenticator when processing encrypted JWTs. In affected versions, a remote attacker who has the server’s RSA public key can craft an encrypted token that causes signature verification to be bypassed, letting the attacker authenticate as any user, including administrators, with arbitrary roles. (NVD)

If you use pac4j-jwt in production, the only durable fix is to upgrade to patched versions:

• 4.x line: 4.5.9+
• 5.x line: 5.7.9+
• 6.x line: 6.3.3+ (Pac4j)

Everything else is triage.

Fast facts you can act on today

What is affected

NVD’s description is explicit: pac4j-jwt versions prior to 4.5.9, 5.7.9, and 6.3.3 contain the authentication bypass. It also spells out the token shape involved: a JWE-wrapped PlainJWT with arbitrary subject and role claims. (NVD)

Why it is maximum severity

NVD lists CVSS vectors for both v3.1 and v4.0 on the record, and the CNA-provided score is the maximum severity. (NVD)

Operationally, this is a “root-of-trust” failure: if your system uses JWTs as identity, then bypassing verification can collapse authorization across multiple services.

Who should treat this as urgent

If your environment meets either of these conditions, you should assume urgency until proven otherwise:

• You authenticate requests with pac4j-jwt’s JwtAuthenticator in a production path.
• You accept encrypted tokens, or you configured encryption support in the authenticator.

CIS’s advisory frames the impact plainly: an unauthenticated remote attacker can authenticate as any user, with any role, without knowing a secret. (CIS)

Where pac4j-jwt shows up and why one bug can spread across services

pac4j is a security engine used across Java web stacks, and pac4j-jwt is the module that handles JWT creation and validation. This often places it in one of the most sensitive positions in a system:

• API gateway authentication filters
• backend services that trust Authorization headers directly
• SSO integration components
• edge services that mint internal identity for downstream microservices

When an authenticator fails open, downstream services often have no second line of defense because they treat the JWT as an already-vetted identity envelope. The blast radius is frequently wider than the service where the vulnerable library is first discovered.

That is why “authentication bypass” CVEs behave differently than many other issues. They are rarely contained.

What engineers are searching for and what it reveals about intent

You asked for “highest CTR keywords,” but CTR is not publicly exposed by search engines and can’t be measured reliably from outside the site owner’s analytics. What we kann do is infer dominant search intent by analyzing what the top surfaced sources emphasize and which phrases repeat across authoritative advisories and widely linked technical analyses.

Across NVD, pac4j’s advisory, CIS’s alert, VulnCheck’s summary, GitHub’s advisory page, and the most-cited technical write-up, the repeated high-intent phrases are:

• “pac4j-jwt authentication bypass”
• “JwtAuthenticator”
• “encrypted JWT” / “JWE”
• “PlainJWT”
• “bypass signature verification”
• “RSA public key”
• “forge tokens” / “impersonate any user” (NVD)

That vocabulary matches what defenders need: identify exposure, patch quickly, and validate that verification is not skipped.

JWT, JWS, and JWE, the mistake this CVE weaponizes

To understand CVE-2026-29000, you don’t need a cryptography degree. You need one conceptual boundary.

JWT is a claims container. According to RFC 7519, those claims are carried either as the payload of a JWS or as the plaintext of a JWE, enabling signing and/or encryption. (IETF Datatracker)

That distinction is the heart of the incident:

• JWS provides integrity, and often authenticity, via a signature or MAC. (IETF Datatracker)
• JWE provides confidentiality, by encrypting content, and its own integrity for the ciphertext, but that does not automatically mean the decrypted claims are authorized to be trusted as identity unless your system verifies what you intend to verify. (IETF Datatracker)

Nested tokens and the “must be signed after decryption” rule

Many real deployments use a nested structure: a signed JWT inside an encrypted envelope. This is common when you want both confidentiality and integrity.

pac4j’s JWT authenticator documentation states a critical behavior note:

If a token is encrypted and signature configurations are defined, the decrypted payload must be a signed JWT; a JWE decrypting to a plain unsigned JWT is rejected. (Pac4j)

CVE-2026-29000 is, in practical terms, a bug that violated that rule in certain paths.

The vulnerability in plain English, type confusion that collapses signature verification

NVD describes the vulnerability outcome and the token type: a JWE-wrapped PlainJWT can bypass signature verification when processed by JwtAuthenticator. (NVD)

The weakness classification is also directly called out: CWE-347, Improper Verification of Cryptographic Signature. (NVD)

Those two details are enough to define the engineering failure mode:

• The system decrypts an encrypted token successfully.
• It then treats the decrypted content as usable identity claims even when it is not signed, or when a signature verification step is skipped.

What the patched code enforces

In pac4j’s current JwtAuthenticator code path:

• It decrypts an encrypted JWT and tries to parse the payload as a signed JWT.
• If signature configurations exist and the signed JWT object is null, it throws a credentials exception rather than proceeding. (GitHub)

This is the security invariant you want:

If you configured signature verification, the library must never create an authenticated profile from an unsigned token, even if it was inside an encrypted envelope.

pac4j’s own documentation says the same thing in words: if at least one SignatureConfiguration is defined, a non-signed JWT PlainJWT is rejected. (Pac4j)

What CodeAnt’s analysis highlights

The most prominent technical analysis attributes the bypass to a logic gap around handling decrypted payloads and a signature verification gate that could be skipped when a “signed JWT” object was not present. (codeant.ai)

This matches how this class of bugs tends to happen: cryptographic verification exists in the codebase, but it’s conditional in a way that attackers can influence.

Affected versions and patched versions, the matrix you should paste into a ticket

pac4j’s official advisory is unambiguous:

• 4.x line: upgrade to 4.5.9+
• 5.x line: upgrade to 5.7.9+
• 6.x line: upgrade to 6.3.3+ (Pac4j)

pac4j’s release notes also mark these versions as a security fix in the pac4j-jwt module. (Pac4j)

Version table

pac4j-jwt major line	Betroffene Versionen	Minimum safe version	Vendor signal
4.x	4.0 to < 4.5.9	4.5.9	“Security fix on the pac4j-jwt module” (Pac4j)
5.x	5.0 to < 5.7.9	5.7.9	“Security fix on the pac4j-jwt module” (Pac4j)
6.x	6.0 to < 6.3.3	6.3.3	“Security fix on the pac4j-jwt module” (Pac4j)

If you need a supply-chain timestamp, MvnRepository shows pac4j-jwt 6.3.3 dated Mar 02, 2026. (Maven Repository)

Exposure conditions that matter in practice

You can waste days arguing whether your environment “really uses JWE.” Don’t.

Instead, answer these questions:

1. Is org.pac4j:pac4j-jwt present in runtime dependencies?
2. Is JwtAuthenticator used in the request authentication flow?
3. Do you accept encrypted tokens, or is encryption configured? pac4j docs say encrypted JWT handling requires adding one or more EncryptionConfiguration objects. (Pac4j)
4. Are signature configurations defined? pac4j docs state that plain tokens are accepted only when no signature configuration exists, otherwise they are rejected. (Pac4j)

NVD’s description names “processing encrypted JWTs” as the affected path and explicitly references a JWE-wrapped PlainJWT. (NVD)

So, if you use JWE and signatures together in pac4j-jwt, treat that as especially high priority until patched.

How to locate pac4j-jwt quickly, dependency graph, artifacts, containers

Maven, find direct and transitive dependencies

mvn -q -DskipTests dependency:tree | grep -E "org\\.pac4j:pac4j-jwt"

To see where it came from:

mvn -DskipTests dependency:tree -Dverbose | grep -E "org\\.pac4j:pac4j-jwt|omitted for conflict"

Gradle, runtime classpath is what ships

./gradlew -q dependencies --configuration runtimeClasspath | grep -E "pac4j-jwt|org\\.pac4j"

Inspect built artifacts

For Spring Boot fat jars:

jar tf app.jar | grep -i "pac4j-jwt"

For container images, consider SBOM-driven detection. This is usually the fastest way to catch “forgotten” inclusions:

syft packages <your-image>:<tag> | grep -i pac4j-jwt

Remediation that actually works

Upgrade immediately, pick the version line you are on

Maven

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

If your platform requires older majors:

<!-- 5.x -->
<dependency>
  <groupId>org.pac4j</groupId>
  <artifactId>pac4j-jwt</artifactId>
  <version>5.7.9</version>
</dependency>

<!-- 4.x -->
<dependency>
  <groupId>org.pac4j</groupId>
  <artifactId>pac4j-jwt</artifactId>
  <version>4.5.9</version>
</dependency>

Gradle

dependencies {
  implementation "org.pac4j:pac4j-jwt:6.3.3"
}

These versions are taken directly from pac4j’s security advisory. (Pac4j)

If you cannot upgrade in hours, do triage controls that reduce exposure

This is not “mitigation” in the cryptographic sense. It is operational risk reduction while you patch.

Options that are defensible in real environments:

• Temporarily reject encrypted tokens at the edge, accept only the token format you can validate deterministically in your stack, typically signed JWS, while you patch pac4j-jwt.
• If you front the service with an API gateway that can validate tokens independently, enforce signature verification there and reduce reliance on downstream verification during the patch window.

Be honest in incident notes: these are containment measures. The fix is upgrading.

Proving the patch is real, a validation approach that avoids offensive detail

When a vulnerability is “signature verification can be bypassed,” validation must be about one invariant:

Under no circumstances should an authenticated profile be created unless the token’s signature verification path has succeeded.

pac4j’s JWT authenticator documentation gives you clear behavioral expectations:

• If at least one SignatureConfiguration exists, PlainJWT is rejected. (Pac4j)
• If a token is encrypted and signature configurations are defined, the decrypted payload must be a signed JWT; otherwise it is rejected. (Pac4j)

Those are perfect acceptance criteria for tests.

A safe test strategy

1. Set up an integration test environment that matches production configuration: same key types, same signature configs, same token issuer, same authenticator options.
2. Positive path test: authenticate with a known-good signed token and verify claims mapping behaves as expected.
3. Negative path test: attempt authentication with tokens that should fail:
   • wrong issuer
   • wrong audience
   • expired tokens
   • malformed tokens
   • encrypted tokens that do not satisfy your policy requirements

The important detail is that you should validate “rejects” across the boundary, not reproduce the exploit shape in text.

What to look for in runtime behavior

• The service returns 401 or equivalent unauthorized.
• No user session is created.
• No roles are granted.
• Logs show signature validation failure or credentials exceptions, not a successful authentication flow.

If your team needs a controlled PoC to validate before and after patching, use the vendor-linked references as your source of truth, and run them only in isolated environments. NVD lists the CodeAnt analysis as a reference for this CVE. (NVD)

Detection and monitoring, what exploitation would look like in telemetry

Because this is a token/claim-level bypass, you should expect identity anomalies, not necessarily crashes.

CIS highlights the attacker can authenticate as any user, including administrator, with any role. (CIS)

That translates into detection heuristics:

Signals that often correlate with forged claims

• Admin access granted without corresponding MFA or IdP events
• Sudden appearance of rarely used roles
• Successful admin session after a burst of authentication failures
• Unusual geography or device fingerprints for privileged users
• High-privilege actions performed immediately after first authentication

Practical SIEM query templates

These are intentionally generic, because log formats vary. Replace fields with your platform equivalents.

Splunk, privilege elevation anomalies

index=prod_auth earliest=-7d
(action="login_success" OR eventType="auth_success")
| stats earliest(_time) as firstSeen latest(_time) as lastSeen values(role) as roles values(src_ip) as ips count by user
| where mvfind(roles, "admin")>=0 AND count=1

Elastic KQL, new admin sessions

event.category:authentication and event.outcome:success and user.roles:admin

Then pivot by user and time window, and correlate with your IdP logs.

Gateway-level heuristics

If your edge logs include the Authorization header shape, you can flag unexpected token formats. As a general JOSE convention, compact JWS has three dot-separated segments, and compact JWE has five. Use that as a rough heuristic to detect “encrypted token suddenly appearing” in a service that previously received only JWS. Tie that to change windows and deployments.

Hardening, preventing the next signature-boundary failure

Patching closes CVE-2026-29000. Hardening reduces your odds of being hit by the next sibling bug.

Make verification policy explicit

Avoid any situation where “signature verification depends on the token type the attacker can influence.”

pac4j’s own docs already state the safer posture:

• plain text tokens accepted only when no signature configuration exists (Pac4j)
• nested encrypted tokens must decrypt to a signed JWT if signature configs exist (Pac4j)

Your job is to ensure your configuration and your surrounding architecture reflect those expectations.

Treat encryption and signing as separate concerns

RFC 7519’s framing is a useful litmus test: claims can be the payload of JWS or the plaintext of JWE, enabling signing and/or encryption. (IETF Datatracker)

That “and/or” matters. “Encrypted” is not a synonym for “trusted issuer.”

Follow modern JWT operational guidance

The IETF OAuth working group published an updated JWT Best Current Practices draft in March 2026, explicitly describing the goal of providing actionable guidance for secure implementation and deployment, and noting it updates RFC 7519 and replaces RFC 8725 to cover threats discovered since 2020. (IETF Datatracker)

Even if you don’t read it end-to-end, align on the principle: verification rules must be deterministic and not attacker-controlled.

Related CVEs that map to the same failure family

CVE-2026-29000 is a modern example of a recurring theme: systems that “use crypto” but fail at verification boundaries.

CVE-2022-21449, Psychic Signatures in Java

NVD describes CVE-2022-21449 as an easily exploitable vulnerability affecting Oracle Java SE / GraalVM libraries, enabling compromise via network access in certain contexts. (NVD)

The security lesson is identical: if signature verification can be bypassed, every higher-level protocol that relies on it can be undermined.

CVE-2019-17195, Nimbus JOSE+JWT parsing exceptions and potential bypass

NVD states Nimbus JOSE+JWT before 7.9 could throw uncaught exceptions while parsing a JWT, potentially resulting in a crash or a potential authentication bypass depending on integration. (NVD)

This is relevant because pac4j’s JWT support is built on Nimbus JOSE+JWT, and it shows how “edge case parsing + integration assumptions” can become security outcomes. (Pac4j)

CVE-2026-23993, recent JWT algorithm handling leading to bypass

PentesterLab’s write-up on CVE-2026-23993 describes a JWT authentication bypass scenario where unexpected algorithm handling can cause signature verification to be bypassed. (Pentesterlab)

Different library, same category error: token header or type influences the verification path.

The point of listing these is not fear. It’s pattern recognition: identity bugs are often “one missing if-statement away” from a complete bypass.

When teams respond to identity-layer CVEs, the slow part is rarely “apply a patch.” The slow part is producing evidence that:

• you found every runtime instance of the vulnerable dependency
• you updated the effective dependency, not just a build file
• your authentication behavior now rejects unsafe token shapes

If your engineers need a refresher on why “decoding a JWT” is not “validating a JWT,” Penligent’s JWT decoding tutorial is a good baseline reference to align terminology before you design tests and detection.

And if your team is working with signed token verification pitfalls, Penligent’s JWS verification failures deep dive is useful context for the broader class of “verification boundary” bugs that CVE-2026-29000 belongs to.

Note: the two Penligent links are included at the end in a copyable list so you can attach them to internal tickets.

Referenzen

Primary CVE and vendor sources

• https://nvd.nist.gov/vuln/detail/CVE-2026-29000
• https://www.pac4j.org/blog/security-advisory-pac4j-jwt-jwtauthenticator.html
• https://www.pac4j.org/docs/authenticators/jwt.html
• https://www.pac4j.org/docs/release-notes.html
• https://www.vulncheck.com/advisories/pac4j-jwt-jwtauthenticator-authentication-bypass
• https://www.cisecurity.org/advisory/a-vulnerability-in-pac4j-jwt-jwtauthenticator-could-allow-for-authentication-bypass_2026-019
• https://github.com/advisories/GHSA-pm7g-w2cf-q238
• https://cwe.mitre.org/data/definitions/347.html
• https://datatracker.ietf.org/doc/html/rfc7519
• https://datatracker.ietf.org/doc/html/rfc7515
• https://datatracker.ietf.org/doc/html/rfc7516
• https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rfc8725bis-04
• https://nvd.nist.gov/vuln/detail/cve-2022-21449
• https://nvd.nist.gov/vuln/detail/cve-2019-17195
• https://pentesterlab.com/blog/cve-2026-23993-harbourjwt-unknown-alg-jwt-bypass
• https://www.penligent.ai/hackinglabs/de/jwt-token-decode-tutorial-tools-steps-and-best-practices/
• https://www.penligent.ai/hackinglabs/hi/json-web-signature-decode-from-base64url-parsing-to-real-world-jws-verification-failures-rfc-7515-cve-2022-21449/
• https://www.penligent.ai/hackinglabs/how-spring-security-works-architecture-authentication-best-practices/
• https://www.penligent.ai/hackinglabs/the-2026-ultimate-guide-to-ai-penetration-testing-the-era-of-agentic-red-teaming/