HTB-Season10-Pterodactyl
Hola Amigos! I'm back with another write-up. If you have some spare time, feel free to check out my previous one, but without further delay, let's dive in...

This box introduces a new type of server management panel: Pterodactyl. As the name suggests, this lab is designed to teach us how to exploit a Pterodactyl server. Alongside grabbing the standard flags, I'll be discussing a few other off-topic concepts too, so bear with me—you'll definitely enjoy it.
The Attack Chain:
- Directory Enumeration
- Nuclei Template: Reveal the path traversal and key (you can skip this if you just want the shell).
- CVE-2025-49132: Exploit for a reverse shell to grab the
user.txtflag. - CVE-2025-6018 & CVE-2025-XXXX: Chain two LPEs to get root access and the
root.txtflag.
The Old Classic Recon
Just like every other lab, we start our initial recon using the holy grail of port scanning: Nmap. I know many professional hackers and bounty hunters like to throw a million arguments into Nmap, but I prefer keeping my scan simple and robust.

Port 80 is open. When accessing it in the browser, note that we have to decrease the MTU rate (sudo ifconfig tun0 mtu 1000) and add the IP to your /etc/hosts file.

We are shown a Minecraft community to join (play.pterodactyl.htb). If you try to access this, it redirects you to the initial website. However, if you perform directory enumeration or crawl the site, you will find a .txt file.

Accessing that file reveals this:

We get a chance to look at the server's PHP info via /phpinfo.php. If you look closely, you'll notice disable_functions() has no value. Normally, this means we could run commands like whoami or cat /etc/passwd. I tried executing commands using curl, but it failed, meaning this wasn't our main vulnerability.
Moving on, I searched Google for default Pterodactyl pages and learned that the login page is usually located at panel.pterodactyl.htb. After fuzzing the subdomains, I confirmed it was there:

KABOOM. We found the login page:

Initial Foothold
The first thing that comes to mind when seeing a login page is SQL injection. Well... that's not the approach here. :)
There is a specific vulnerability that affects this server: CVE-2025-49132. You can verify this using a Nuclei template (found here). Save it, use it to extract the APP_KEY value, and curl the URL to reveal the files location (/var/www/pterodactyl).

I tried writing my own Python script, but it kept failing, so I opted for a pre-written exploit from GitHub:
https://github.com/malw0re/CVE-2025-49132---Pterodactyl-RCE-HTB-Season-10-.git

I created a simple .sh reverse shell file on my Kali machine, triggered it with the Python script, and started an nc -lvnp listener to catch the shell.

Navigate to the home directory and into the phileasfogg3 folder for the user.txt file!

The Rabbit Hole
During enumeration, I found a .env file containing database credentials:






I thought we could use these to create an admin user. However, to add the /mnt/root path and make it work, the server requires a restart. Since the start/restart buttons are disabled on this machine, this was a dead end. Time to look for another path.
Privilege Escalation
I started researching CVEs related to this setup and found two that chain together perfectly: CVE-2025-6018 and CVE-2025-XXXX.
Step 1: CVE-2025-6018
A Local Privilege Escalation (LPE) in pam-config within Linux PAM. This allows an unprivileged local attacker to obtain "allow_active" Polkit actions, usually reserved for console users.
- Repo:
https://github.com/ibrahmsql/CVE-2025-6018
We use this to gain a partially privileged account. I call it "partial" because if we try to su root, it still asks for a password. What this actually does is remove some restrictions so we can run udisksctl loop-setup—which we desperately need for the next step.

Step 2: The Mystery CVE
If you are in a hurry, decode this: 51 31 5a 46 4c 54 49 77 4d 6a 55 74 4e 6a 41 78 4f 51 3d 3d (Hint: All you need is 16 and its multiple).
For the rest of us, the hidden vulnerability is CVE-2025-6019, an LPE found in libblockdev.
How it works: When a standard user mounts a drive, Linux applies a safety rule called nosuid. This prevents you from bringing your own root shell onto the system. However, this CVE exposes a Race Condition. When you resize a specially crafted XFS image, the system accidentally drops the nosuid rule for a split second. If we are fast enough, we can execute our SUID-root shell in that tiny window.
There are two ways to do this.
Method 1: The Manual Way (Painful)
- Create a blank 300MB file and format it as an XFS image:
fallocate -l 300M xfsexploit.img && mkfs.xfs xfsexploit.im - Mount it locally, copy bash, and set the SUID bit :
mkdir mnt
sudo mount xfs_exploit.img mnt
sudo cp /bin/bash mnt/rootshell
sudo chmod +s mnt/rootshell
- Unmount it, transfer it to the target shell via a Python server, and set up the loop device:
udisksctl loop-setup -f xfs_exploit.img
- Run a loop to aggressively catch the shell:
while true; do /tmp/blockdev-*/rootshell -p; done
- Open a new SSH instance, trigger the resize, and wait for the root shell to pop!
Method 2: The Automated Way (My Choice)
Using the script from: https://github.com/guinea-offensive-security/CVE-2025-6019
Execute the script on your local machine and select [L] (local) to generate the malicious xfs.image. Transfer this file to the /tmp directory on your target shell.
Note: The script might throw an error saying mkfs.xfs is missing on the target. It isn't actually needed for the remote execution, so bypass it with this quick fix:
sed -i 's/mkfs.xfs/ls/g' exploit.sh
Run the script, select [c] for remote host, and let the race condition do its magic. Type whoami, verify you are root, and claim your flag!



Return to Home