This report provides a technical analysis and mitigation strategies for CVE-2026-29000, a signature verification bypass vulnerability identified in the JWT (JSON Web Token) module, pac4j-jwt, of the Java-based open-source security engine pac4j.
The vulnerability affects versions prior to 4.5.9, 5.7.9, and 6.3.3 of pac4j-jwt, and originates from a flaw in the JwtAuthenticator logic when processing encrypted JWTs (JWE). A remote attacker who obtains the server’s RSA public key can craft a PlainJWT (an unsigned token) containing arbitrary subject and role claims, encapsulate it within a JWE (JSON Web Encryption) structure, and send it to the server. Due to improper validation, the server may accept the token and bypass the signature verification process, allowing the attacker to successfully pass the authentication mechanism.
This report provides a technical analysis and mitigation strategies for CVE-2026-29000, a Signature Verification Bypass vulnerability discovered in the JWT (JSON Web Token) module pac4j-jwt of the Java-based open-source security engine pac4j.
The vulnerability occurs in pac4j-jwt versions prior to 4.5.9, 5.7.9, and 6.3.3, due to a flaw in the JwtAuthenticator logic when processing encrypted JWTs (JWEs). A remote attacker who obtains the server’s RSA public key can craft a PlainJWT (unsigned token) containing arbitrary subject and role claims, wrap it in a JWE (JSON Web Encryption) structure, and send it to the server. Because of improper validation, the server may accept the token without performing proper signature verification, allowing the attacker to bypass authentication.
This vulnerability is rated Critical (CVSS 10.0) due to its severe impact. If the attack succeeds, an adversary could forge tokens and compromise any user account—including administrative ones—resulting in unauthorized access to the system. Accordingly, this report analyzes the root cause of the vulnerability and provides the latest patch information and configuration recommendations to mitigate the risk.
- Role of pac4j-jwt
The pac4j-jwt library is a core component of the Java-based security framework pac4j, responsible for generating and validating JSON Web Tokens (JWTs). It is primarily used in OAuth 2.0 and OpenID Connect (OIDC) environments to handle user authentication and authorization.
- Core Issue: JWT Verification Logic
In the normal JWT verification process, the integrity of all three token components—the Header, Payload, and Signature—must be verified. For encrypted tokens (JWEs, JSON Web Encryption), the verification process should include
one additional step: after decrypting the outer encryption layer, the inner JWT must also be verified for a valid signature. This vulnerability arises because, under certain conditions, the signature verification step for the inner JWT is skipped.
3-2. Root Cause
This vulnerability originates from a structural flaw in the JwtAuthenticator class of pac4j-jwt, which fails to enforce signature verification on the inner payload when processing encrypted tokens (JWEs).
- Missing Signature Verification after JWE Decryption
When handling a JWE, the JwtAuthenticator decrypts the token using the server’s private key. Under normal security procedures, it should perform an additional signature check on the decrypted JWT. However, in vulnerable versions, if the inner JWT is an unsigned PlainJWT, the library erroneously accepts it as a valid token without performing any signature validation.
- Acceptance of PlainJWT in Vulnerable Configurations
In some configuration scenarios, JwtAuthenticator does not strictly enforce algorithm validation. When an attacker sets the token’s algorithm (alg) field to none or wraps an unsigned PlainJWT inside a JWE, the system may trust the decrypted data and skip the signature verification step entirely.
- Structural Flaw: Lack of Algorithm Enforcement
Even if the server is configured to expect a specific signing algorithm (e.g., RS256), the library does not restrict the algorithms of internal JWTs using a whitelist mechanism. As a result, an attacker possessing only the server’s RSA public key can bypass signature verification and generate forged tokens containing arbitrary privilege claims.
3-3. Attack Scenario
The attacker assumes a situation in which the server’s RSA public key has been exposed or is otherwise obtainable, and proceeds with the attack using the following steps:
Step 1. Create a tampered PlainJWT
The attacker generates an unsigned JWT (PlainJWT).
- Header: set to {"alg": "none"}
- Payload: configure sub (subject) as a specific administrator account and arbitrarily assign admin privileges to the role claim.
Step 2. Wrap the token in JWE encryption
Even if the server directly rejects tokens using alg: none, it still processes JWE tokens after decryption. The attacker exploits this by encrypting the previously created PlainJWT into a JWE structure using the server’s RSA public key, making the token appear to be a legitimate encrypted JWT.
Step 3. Send the tampered token and initiate authentication
The attacker sends the forged JWE token within the HTTP request’s authentication header:
- Authorization: Bearer
Step 4. Bypass verification and escalate privileges
The server’s JwtAuthenticator decrypts the JWE using its private key, extracting the internal PlainJWT.
[Vulnerability trigger] Once decryption succeeds, the server implicitly trusts the internal data without verifying the signature or the alg: none setting. As a result, the attacker successfully authenticates as an administrator.
3-4. Affected Versions
All versions of pac4j-jwt earlier than v4.5.9, v5.7.9, and v6.3.3.
3-5. Mitigation Measures
Apply the latest security patches (strongly recommended)
Immediately update the pac4j-jwt library to a version that includes the security fix:
- v4.x series: update to v4.5.9 or later
- v5.x series: update to v5.7.9 or later
- v6.x series: update to v6.3.3 or later
Configure an algorithm whitelist
When configuring JwtAuthenticator, explicitly specify allowed signature algorithms (e.g., RS256, ES256, etc.).
This prevents the processing of tokens that use alg: none or any unauthorized algorithm.
Since external security devices do not possess the decryption keys, they cannot inspect or identify the forged PlainJWT contained within the encrypted data. As a result, the malicious traffic may appear as legitimate encrypted communication and pass through security layers undetected.
In conclusion, this issue originates from a validation logic flaw within the pac4j-jwt library itself, making network-based defenses insufficient on their own. Therefore, mitigation must be implemented at the application level through prompt library updates and reinforcement of security configuration settings.
The vulnerability affects versions prior to 4.5.9, 5.7.9, and 6.3.3 of pac4j-jwt, and originates from a flaw in the JwtAuthenticator logic when processing encrypted JWTs (JWE). A remote attacker who obtains the server’s RSA public key can craft a PlainJWT (an unsigned token) containing arbitrary subject and role claims, encapsulate it within a JWE (JSON Web Encryption) structure, and send it to the server. Due to improper validation, the server may accept the token and bypass the signature verification process, allowing the attacker to successfully pass the authentication mechanism.
1. Overview
Missing PlainJWT Validation Vulnerability in JWE Processing of pac4j-jwt (CVE-2026-29000)This report provides a technical analysis and mitigation strategies for CVE-2026-29000, a Signature Verification Bypass vulnerability discovered in the JWT (JSON Web Token) module pac4j-jwt of the Java-based open-source security engine pac4j.
The vulnerability occurs in pac4j-jwt versions prior to 4.5.9, 5.7.9, and 6.3.3, due to a flaw in the JwtAuthenticator logic when processing encrypted JWTs (JWEs). A remote attacker who obtains the server’s RSA public key can craft a PlainJWT (unsigned token) containing arbitrary subject and role claims, wrap it in a JWE (JSON Web Encryption) structure, and send it to the server. Because of improper validation, the server may accept the token without performing proper signature verification, allowing the attacker to bypass authentication.
This vulnerability is rated Critical (CVSS 10.0) due to its severe impact. If the attack succeeds, an adversary could forge tokens and compromise any user account—including administrative ones—resulting in unauthorized access to the system. Accordingly, this report analyzes the root cause of the vulnerability and provides the latest patch information and configuration recommendations to mitigate the risk.
2. Vulnerability
- CVE ID: CVE-2026-29000
- Vulnerability Title: Signature Verification and Authentication Bypass in pac4j-jwt JWE/PlainJWT Processing
- Vulnerability Type: Improper Authentication (CWE-287), Insufficient Cryptographic Signature Verification (CWE-347)
- Severity Level: Critical
- CVSS 3.1 Score: 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) (initially rated 10.0, downgraded as of 2026-03-10)
- Affected Product: org.pac4j:pac4j-jwt (versions prior to 4.5.9, 5.7.9, and 6.3.3)
- Primary Impacts: Privilege escalation, signature verification bypass, unauthorized access
- Privilege escalation: An attacker can use the server’s RSA public key to craft forged JWTs containing arbitrary subject and role claims.
- Signature verification bypass: When a PlainJWT (unsigned token) is embedded within a JWE structure, the JwtAuthenticator fails to perform signature verification on the inner token.
- Unauthorized access: An attacker may authenticate as any user, including administrators.
- Privilege escalation: An attacker can use the server’s RSA public key to craft forged JWTs containing arbitrary subject and role claims.
- Mitigation: It is strongly recommended to immediately update the pac4j-jwt library to the latest patched versions (v4.5.9, v5.7.9, or v6.3.3 or later).
3. Analysis
3-1. Background Knowledge- Role of pac4j-jwt
The pac4j-jwt library is a core component of the Java-based security framework pac4j, responsible for generating and validating JSON Web Tokens (JWTs). It is primarily used in OAuth 2.0 and OpenID Connect (OIDC) environments to handle user authentication and authorization.
- Core Issue: JWT Verification Logic
In the normal JWT verification process, the integrity of all three token components—the Header, Payload, and Signature—must be verified. For encrypted tokens (JWEs, JSON Web Encryption), the verification process should include
one additional step: after decrypting the outer encryption layer, the inner JWT must also be verified for a valid signature. This vulnerability arises because, under certain conditions, the signature verification step for the inner JWT is skipped.
3-2. Root Cause
This vulnerability originates from a structural flaw in the JwtAuthenticator class of pac4j-jwt, which fails to enforce signature verification on the inner payload when processing encrypted tokens (JWEs).
- Missing Signature Verification after JWE Decryption
When handling a JWE, the JwtAuthenticator decrypts the token using the server’s private key. Under normal security procedures, it should perform an additional signature check on the decrypted JWT. However, in vulnerable versions, if the inner JWT is an unsigned PlainJWT, the library erroneously accepts it as a valid token without performing any signature validation.
- Acceptance of PlainJWT in Vulnerable Configurations
In some configuration scenarios, JwtAuthenticator does not strictly enforce algorithm validation. When an attacker sets the token’s algorithm (alg) field to none or wraps an unsigned PlainJWT inside a JWE, the system may trust the decrypted data and skip the signature verification step entirely.
- Structural Flaw: Lack of Algorithm Enforcement
Even if the server is configured to expect a specific signing algorithm (e.g., RS256), the library does not restrict the algorithms of internal JWTs using a whitelist mechanism. As a result, an attacker possessing only the server’s RSA public key can bypass signature verification and generate forged tokens containing arbitrary privilege claims.
3-3. Attack Scenario
The attacker assumes a situation in which the server’s RSA public key has been exposed or is otherwise obtainable, and proceeds with the attack using the following steps:
Step 1. Create a tampered PlainJWT
The attacker generates an unsigned JWT (PlainJWT).
- Header: set to {"alg": "none"}
- Payload: configure sub (subject) as a specific administrator account and arbitrarily assign admin privileges to the role claim.
Step 2. Wrap the token in JWE encryption
Even if the server directly rejects tokens using alg: none, it still processes JWE tokens after decryption. The attacker exploits this by encrypting the previously created PlainJWT into a JWE structure using the server’s RSA public key, making the token appear to be a legitimate encrypted JWT.
Step 3. Send the tampered token and initiate authentication
The attacker sends the forged JWE token within the HTTP request’s authentication header:
- Authorization: Bearer
Step 4. Bypass verification and escalate privileges
The server’s JwtAuthenticator decrypts the JWE using its private key, extracting the internal PlainJWT.
[Vulnerability trigger] Once decryption succeeds, the server implicitly trusts the internal data without verifying the signature or the alg: none setting. As a result, the attacker successfully authenticates as an administrator.
3-4. Affected Versions
All versions of pac4j-jwt earlier than v4.5.9, v5.7.9, and v6.3.3.
3-5. Mitigation Measures
Apply the latest security patches (strongly recommended)
Immediately update the pac4j-jwt library to a version that includes the security fix:
- v4.x series: update to v4.5.9 or later
- v5.x series: update to v5.7.9 or later
- v6.x series: update to v6.3.3 or later
Configure an algorithm whitelist
When configuring JwtAuthenticator, explicitly specify allowed signature algorithms (e.g., RS256, ES256, etc.).
This prevents the processing of tokens that use alg: none or any unauthorized algorithm.
4. Conclusion
This vulnerability cannot be effectively detected or blocked by signature-based security devices such as web firewalls or intrusion prevention systems. This is because the attack payload is transmitted in a standard JWE (JSON Web Encryption) format.Since external security devices do not possess the decryption keys, they cannot inspect or identify the forged PlainJWT contained within the encrypted data. As a result, the malicious traffic may appear as legitimate encrypted communication and pass through security layers undetected.
In conclusion, this issue originates from a validation logic flaw within the pac4j-jwt library itself, making network-based defenses insufficient on their own. Therefore, mitigation must be implemented at the application level through prompt library updates and reinforcement of security configuration settings.
5. References
- https://nvd.nist.gov/vuln/detail/CVE-2026-29000
- https://www.codeant.ai/security-research/pac4j-jwt-authentication-bypass-public-key
- https://www.vulncheck.com/advisories/pac4j-jwt-jwtauthenticator-authentication-bypass
- https://www.sonatype.com/blog/pac4j-cve-2026-29000-sonatype-finds-19-additional-packages
- https://m.boannews.com/html/detail.html?tab_type=1&idx=142485
- https://github.com/advisories/GHSA-pm7g-w2cf-q238
- https://sslc.kr/board/news/1315
