HTB Write-Up: Kobold

Table of Contents

1. Reconnaissance
2. Enumeration — Subdomain Discovery & Version Fingerprinting
3. Initial Access — CVE-2026-23520 (Arcane Docker Management RCE)
4. Privilege Escalation — Docker Socket Abuse
5. Summary & Takeaways

1. Reconnaissance

Started with a targeted port scan:

Nothing surprising, and SSH is useless without creds, so the web server is where to start. Added kobold.htb to /etc/hosts and moved on.

2. Enumeration — Subdomain Discovery & Version Fingerprinting

2.1 — Virtual Host Enumeration

The main page didn't have much going on, so I ran a vhost bruteforce to check for anything hiding behind the same server:

Two subdomains. Added both to /etc/hosts and opened them up.

2.2 — Identifying the Services

bin.kobold.htb turned out to be a PrivateBin instance — noted, nothing immediately exploitable, parked it. mcp.kobold.htb was more interesting: a panel called "MCPJam" with an MCP Servers interface I hadn't seen before. Had to dig through the page source to figure out what it was actually built on — found a version string referencing Arcane Docker Management v1.13.0. Once I had that name and version, things moved fast.

2.3 — CVE Research

Searching "Arcane Docker Management CVE" turned up CVE-2026-23520 immediately — a critical unauthenticated RCE affecting v1.13.0 and below. Exact match.

3. Initial Access — CVE-2026-23520 (Arcane Docker Management RCE)

3.1 — How the Vulnerability Works

The /api/mcp/connect endpoint takes a JSON body with a serverConfig object specifying a command and args to run server-side. No auth, no input validation — hand it a shell command and it runs. About as straightforward as RCE gets.

3.2 — Triggering the Exploit

Set up a listener, grabbed the standard bash TCP one-liner, and dropped it straight into the args field:

In as ben. Grabbed the user flag before doing anything else. The shell itself was rough — no tab completion, no arrow keys, Ctrl+C would kill the whole session — and my internet gave up around here too, so I called it for the night and came back the next morning.

3.3 — Stabilizing the Shell

First order of business the next day was upgrading to a proper TTY before touching anything else:

Proper interactive shell now. Time to look for a privesc path.

4. Privilege Escalation — Docker Socket Abuse

4.1 — Poking Around

Docker was running on the box:

Almost moved on at that point, but checked id properly first — ben was already in the docker group, the active group just wasn't set yet. newgrp fixed that for the current session:

4.2 — Mounting the Host Filesystem

Docker socket access is root on the host, full stop. Spun up a container as root with the entire host filesystem mounted inside:

4.3 — chroot Into the Host

Root on the actual machine. Root flag at /root/root.txt.

5. Summary & Takeaways

Attack Chain

What I Took Away From This Box

I almost gave up on the docker angle the moment the first docker ps came back with permission denied. It's an easy thing to skip when you're moving fast, but checking group membership properly instead of trusting the first error saved the box for me here.

The MCPJam panel didn't tell me anything about what it was running underneath at a glance — that only came from actually reading the page source. One version string in there led straight to the CVE, which is a good reminder that the boring recon step is usually the one that matters.

The bigger point though is that docker group membership is effectively root, full stop. No SUID, no sudo, no kernel exploit — just mount the host filesystem into a privileged container and chroot in. On a real system I'd treat docker group access exactly like sudo, and I'd never want an unauthenticated command-execution endpoint sitting on a network-reachable panel regardless of how "internal" it felt.