I just solved DevHub from Hack the Box
DevHub Machine Summary
DevHub is a medium difficulty Linux machine on Hack The Box that focuses on modern AI infrastructure security, insecure development tooling, exposed internal services, and abuse of privileged administrative APIs. The machine demonstrates how seemingly isolated developer components can be chained together to achieve complete system compromise, highlighting the risks associated with exposing AI management platforms and weak internal trust boundaries.
The attack chain begins with Nmap enumeration, which reveals SSH and an Nginx web server that redirects users to the devhub.htb virtual host. After performing host configuration, further web enumeration uncovers an externally accessible MCPJam Inspector service running on port 6274 and references to several internal development services.
During MCPJam enumeration, the application version is identified as MCPJam Inspector v1.4.2. Subsequent vulnerability research leads to the discovery of CVE-2026-23744, a public remote code execution vulnerability affecting versions 1.4.2 and earlier. After completing exploit preparation, the public proof-of-concept is weaponized, resulting in initial access as the mcp-dev user through a reverse shell.
With a foothold established, extensive internal service enumeration reveals an internal OPSMCP API listening on port 5000, while credential enumeration uncovers a hardcoded Jupyter authentication token embedded inside a systemd service file. Further Jupyter authentication, user enumeration, and internal port enumeration confirm the presence of a locally accessible Jupyter Lab instance running under the analyst account.
To establish a stable foothold, SSH key generation, SSH key preparation, SSH persistence, and SSH access are used to replace the temporary reverse shell with reliable key-based authentication. Using port forwarding, the internal Jupyter service is exposed locally, allowing successful Jupyter Lab authentication with the recovered token. Launching a built-in terminal grants Jupyter terminal access as the analyst user, leading to the capture of the user flag.
The final stage revolves around abusing the internal management API. By leveraging the recovered OPSMCP API key, OPSMCP API abuse is performed through a hidden administrative function that exposes emergency recovery credentials. Through SSH key recovery, a root private key is extracted, saved locally, and used to authenticate directly to the target. Successful root access is achieved via SSH, allowing retrieval of the root flag and full compromise of the machine.
Overall, DevHub is an excellent demonstration of how exposed developer tools, insecure internal APIs, leaked credentials, and poor trust separation between AI infrastructure components can be combined into a realistic and highly effective attack chain from initial access to root.
Protected Page
The first step in owning the DevHub machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:
Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the DevHub machine and I was assigned an IP address (10.129.16.165).
Nmap Enumeration
I started by performing an Nmap scan against the target to identify exposed services, service versions, and potential attack vectors. I used the -sCV and -A options to combine default script scanning, version detection, and OS fingerprinting in a single enumeration step.
The scan revealed that only two ports were accessible: SSH (22/tcp) running OpenSSH 8.9p1 and HTTP (80/tcp) served by Nginx 1.18.0. The web service automatically redirected requests to the hostname devhub.htb, indicating that virtual host configuration was in use, so I added the domain to my /etc/hosts file before proceeding with further web enumeration. OS detection also suggested that the target was running an Ubuntu-based Linux system.
Host Configuration
Before interacting further with the web service, I configured my local machine to resolve the target's virtual hostname. Since the Nmap scan showed that the website redirected requests to devhub.htb, I added the domain to my /etc/hosts file so that my browser and enumeration tools would correctly reach the application.
This mapped the target IP address to the devhub.htb hostname locally, allowing me to access the intended virtual host and continue with web application enumeration.
Web Enumeration
After configuring the hostname, I navigated to http://devhub.htb to begin enumerating the web application. The landing page appeared to be an internal development portal and immediately exposed several interesting pieces of information that could be useful for further exploitation.
The homepage revealed that the MCP Inspector service was active on external port 6274, while an Analytics Dashboard was running internally on localhost:8888. It also referenced an internal Git repository in maintenance mode, suggesting that additional services might be accessible through port forwarding or pivoting later in the attack chain. These findings provided valuable clues for my next enumeration steps.
MCPJam Enumeration
After discovering that port 6274 was externally accessible, I browsed to the service to investigate its functionality. I then navigated to the settings page to gather additional information about the application and identify its exact version.
The interface was revealed to be MCPJam Inspector, and the settings page disclosed that it was running MCPJam v1.4.2. Identifying the software version was an important step, as it allowed me to begin researching publicly known vulnerabilities and potential attack paths associated with that specific release.
Vulnerability Research
After identifying that the target was running MCPJam Inspector v1.4.2, I began researching publicly disclosed vulnerabilities for that specific version. During my investigation, I found a public proof-of-concept repository for CVE-2026-23744, which affected MCPJam versions 1.4.2 and earlier.
The advisory explained that the application listens on 0.0.0.0 by default, allowing a remote attacker to send a crafted HTTP request that installs and executes a malicious MCP server, ultimately leading to remote code execution (RCE). Since the target was running the vulnerable version and had the service exposed externally on port 6274, this vulnerability became my primary attack vector for obtaining initial access.
Exploit Preparation
After confirming that the target was vulnerable to CVE-2026-23744, I downloaded the public proof-of-concept repository so I could examine the exploit and prepare it for use against the MCPJam instance.
Next, I moved into the cloned repository and enumerated its contents to understand the available resources and exploit files.
The repository contained an exploit.py script, an Assets directory, and a README.md file, providing everything needed to analyze and weaponize the vulnerability against the target service.
Initial Access
After preparing the exploit, I started a Netcat listener on my attack machine to receive an incoming reverse shell connection from the target.
With the listener ready, I executed the public proof-of-concept exploit against the vulnerable MCPJam instance, supplying a reverse shell payload that would connect back to my host.
Although the HTTP request eventually timed out, the payload executed successfully, and a reverse shell was established in my Netcat listener.
This provided initial access to the target as the mcp-dev user, confirming successful exploitation of CVE-2026-23744.
Internal Service Enumeration
After gaining a foothold on the target, I began enumerating services that were only accessible from the local machine. I queried port 5000 to identify any internally exposed applications that could be leveraged for further privilege escalation.
To gather additional information, I retrieved the full HTTP response headers from the service.
The responses revealed an internal application named OPSMCP v2.1.0, exposing endpoints such as /tools/list, /tools/call, and /health. Although the API required authentication through an X-API-Key header, identifying these endpoints provided a promising direction for further post-exploitation enumeration.
Credential Enumeration
After discovering that the internal OPSMCP service required an API key, I attempted to inspect the application source code. When direct access to the server file was denied, I expanded my enumeration by searching common locations for hardcoded credentials, tokens, and authentication secrets.
Although I could not read the protected server.py file, the recursive search uncovered a Jupyter Lab token embedded within the jupyter.service systemd configuration. Since the service was configured to listen on the internal interface at port 8888, this credential presented a promising avenue for pivoting deeper into the target environment.
Jupyter Authentication
After recovering the Jupyter authentication token, I tested it against the internal Jupyter Lab instance running on port 8888. This allowed me to verify whether the leaked credential was valid and accessible from my current foothold.
The request returned an HTTP/1.1 200 OK response along with the full Jupyter Lab interface, confirming that the token was valid. The response also disclosed that the service was running JupyterLab 4.5.2 and that the notebook root directory was located at /home/analyst/notebooks, providing a clear path for further enumeration and potential privilege escalation.
User Enumeration
With access to the target, I enumerated the local user accounts to better understand the environment and identify potential lateral movement opportunities. Reading the /etc/passwd file is a quick way to discover valid users and their associated home directories.
The output revealed two interactive user accounts: mcp-dev, which I already controlled, and another user named analyst. Since I had previously discovered an internally accessible Jupyter Lab instance configured to use /home/analyst/notebooks, this finding strongly suggested that the analyst account would become my next target for privilege escalation.
Internal Port Enumeration
After identifying several interesting services, I enumerated the local listening ports to better understand the target's internal attack surface. This helped me verify which applications were only accessible from the host itself.
The output confirmed that both Jupyter Lab (127.0.0.1:8888) and the OPSMCP API (127.0.0.1:5000) were bound exclusively to the loopback interface, explaining why they were not visible during my initial Nmap scan. It also verified that the vulnerable MCPJam Inspector service was exposed externally on port 6274, reinforcing the attack path I had already used to gain initial access.
SSH Key Generation
To prepare for establishing persistent SSH access later in the attack chain, I generated a new RSA key pair on my attack machine. This would allow me to authenticate using my public key if I managed to write it to a user's authorized_keys file.
The command successfully created a 4096-bit RSA key pair and stored it in my local ~/.ssh directory. With the keys generated, I was ready to leverage any available file write primitive or command execution capability to gain stable SSH access to the target.
SSH Key Preparation
After generating my SSH key pair, I displayed the contents of the public key so it could be added to a target user's authorized_keys file if I obtained the necessary write permissions.
The command printed my RSA public key, which I planned to use for persistent access instead of relying on an unstable reverse shell. By authenticating with an SSH key, I would be able to establish a more reliable and interactive session once the key was deployed on the target.
SSH Persistence
To establish a more stable foothold, I configured SSH key-based authentication for the mcp-dev account. I created the required .ssh directory, set the appropriate permissions, and appended my public key to the authorized_keys file.
With the correct file permissions in place, my public key was successfully installed for the mcp-dev user. This provided a persistent and far more reliable method of accessing the target than maintaining the original reverse shell.
SSH Access
After installing my public key on the target, I authenticated to the machine over SSH using the corresponding private key. This provided a much more stable and interactive shell than the original reverse connection.
On the first connection, I accepted the host fingerprint and successfully logged in as the mcp-dev user. The SSH session confirmed that the target was running Ubuntu 22.04.5 LTS, giving me a persistent foothold for the remainder of my post-exploitation and privilege escalation activities.
Port Forwarding
After obtaining stable SSH access, I created a local port forward to reach the internal Jupyter Lab service that was bound to 127.0.0.1:8888. This allowed me to interact with the application directly from my browser without needing to rely on command-line requests.
The SSH connection successfully established a tunnel between my local machine and the target's internal service. With the port forwarding in place, I could simply browse to http://127.0.0.1:8888 on my attack host and access the Jupyter Lab instance using the authentication token I had previously recovered.
Jupyter Lab Authentication
After forwarding the internal service to my local machine, I browsed to http://127.0.0.1:8888 to access the Jupyter Lab instance. The application redirected me to the login page, where it requested a valid password or authentication token.
Using the Jupyter token I had previously recovered from the jupyter.service systemd configuration, I authenticated successfully and gained access to the Jupyter Lab interface.
The login confirmed that the leaked credential was valid and provided direct access to the analyst's notebook environment, opening the door for further enumeration and privilege escalation.
Jupyter Terminal Access
After successfully authenticating to Jupyter Lab, I launched the built-in terminal from the web interface. This provided me with an interactive shell running under the context of the analyst user, effectively allowing me to pivot to a higher-privileged account.
Obtaining the User Flag
Inside the terminal, I enumerated the contents of the analyst's home directory and discovered the user.txt file. Reading the file confirmed that I had successfully gained access to the analyst account and allowed me to capture the user flag, marking the completion of the initial access phase.
OPSMCP API Abuse
After gaining access to the internal environment, I leveraged the recovered OPSMCP API key to interact with the protected /tools/call endpoint. I invoked the hidden administrative function ops._admin_dump and requested the ssh_keys target.
The request was successful and returned an emergency recovery SSH private key embedded within the JSON response. Since the key belonged to the root account, this provided a direct path to privilege escalation by authenticating to the target over SSH with the recovered credentials.
SSH Key Recovery
After extracting the emergency recovery key from the OPSMCP API, I saved the returned private key to a local file on my attack machine. This allowed me to prepare the credential for SSH authentication in the next stage of the attack.
The command wrote the recovered OpenSSH private key to a file named root_key, preserving its original format. With the key safely stored locally, I was ready to adjust its permissions and attempt direct SSH authentication as the root user, completing the privilege escalation chain.
Root Access
After saving the recovered SSH private key, I adjusted its permissions to satisfy the SSH client requirements. I then used the key to authenticate directly to the target as the root user.
The authentication completed successfully, and I was presented with an interactive shell as root. This confirmed that the emergency recovery key obtained through the vulnerable OPSMCP administrative API provided direct root access, completing the machine's privilege escalation path.
Root Flag
With full administrative access established, I enumerated the contents of the root user's home directory to locate the final objective of the machine. As expected, the directory contained the root.txt file alongside the default snap directory.
Reading the file revealed the root flag, confirming complete compromise of the target. At this point, the attack chain was successfully concluded, having progressed from external web enumeration and MCPJam exploitation to full root access through abuse of the internal OPSMCP administrative API.
If you enjoy reading my write-ups, please consider subscribing to my YouTube channel and following me on LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee. Found this walkthrough helpful? Buying me a coffee helps power the late nights spent writing technical walkthroughs and keeping them free for everyone ☕
Keywords:
DevHub htb writeup
DevHub htb walkthrough
DevHub Hack the Box Write Up
DevHub Hack the Box Walkthrough
devhub.htb season 11 HackTheBox machine
DevHub HackTheBox Writeup
DevHub HackTheBox Walkthrough
HackTheBox devhub machine complete writeup solution
I just solved DevHub from Hack the Box
Pwned DevHub from Hack the Box
Rooted DevHub from Hack the Box
Owned DevHub from Hack the Box
devhub.htb
reactor.htb
Reactor HackTheBox
reactor htb walkthrough
reactor htb writeup
Reactor Hack the Box Writeup
Reactor Hack the Box Walkthrough
reactor HackTheBox machine Season 11 HTB write up
I just solved Reactor from Hack the Box
Rooted Reactor from Hack the Box
Owned Reactor from Hack the Box
Pwned Reactor from Hack the Box
helix.htb HackTheBox Season 11 HTB machines
helix htb writeup
helix htb walkthrough
helix hack the box writeup
Helix Hack the Box Walkthrough
I just solved Helix from Hack the Box
Rooted Helix from Hack the Box
Owned Helix from Hack the Box
0 Comments