The challenge
Reconstruct the unsigned fetch-to-worker incident from the request log. Follow the exposed service routes to reproduce it, inspect the resulting evidence, then submit a detector and repair that block the attack while preserving signed status checks.
There was no downloadable artifact. Each mode assigned one or more live targets.
| Mode | Answer ID | Question | Format |
|---|---|---|---|
| Single Solve | proof- |
Recover the proof from Target 1. | exact_; submit the exact recovered text, trimming surrounding whitespace. |
| Time Trial | proof- |
Recover the proof from Target 1. | exact_; submit the exact recovered text, trimming surrounding whitespace. |
| Mastery | proof-–proof- |
Recover the proof from Targets 1–8, one answer per target. | exact_; submit each exact recovered text, trimming surrounding whitespace. |
Reading the prompt: what it said we'd need
| Clue | What it pointed to | What I did about it |
|---|---|---|
| “Reconstruct the … incident from the request log” | A sequence of events had to be correlated across the request, audit, and worker views. | Followed the logged request identifier through the exposed service routes. |
| “unsigned fetch-to-worker” | An internal fetch could create an event that reached an asynchronous worker without a valid signature. | Reproduced the logged event, then used the disclosed audit and worker interfaces to establish the full chain. |
| “inspect the resulting evidence” | The worker’s action and its proof had to be observed after dispatch. | Used the worker commands and objective resource disclosed by the target response. |
| “block the attack while preserving signed status checks” | A repair needed to reject the unsigned internal dispatch while keeping legitimate signed status requests working. | Submitted the detector and repair contract, then checked all reported regressions and made a follow-up status request. |
Safety
Only Game Master assigned targets were used. The investigation followed routes and request identifiers disclosed by the challenge. Target URLs and exact proofs are omitted. The web service behavior was tested through the assigned challenge; no local executable was run.
What the target showed
The request log contained an unsigned fetch event. Dispatching the logged target created a fetch event, but the first audit check did not establish that the incident had reached the worker. The audit route accepted the target value as its token and returned worker_dispatched; that response disclosed the status and cat <resource> worker commands and the objective resource.
Reading the objective reproduced the unsigned worker dispatch and exposed the detector and repair contract. The accepted detector matched kind="worker.dispatch" with signed=false. The repair blocked internal fetches, required signed events, and allowed the status worker command. The target reported that all five regression checks passed, including that benign signed status checks remained available.
Single Solve
The request log exposed an unsigned fetch record. Following its target value through the disclosed audit route dispatched the worker; reading the objective then reproduced the incident. I submitted the detector and repair returned by the evidence flow, verified the five regression results, and confirmed a follow-up signed status request still returned HTTP 200. The proof was submitted under proof-1.
result CORRECT
completion flag (short): `e33bfa49…5f1b`
answer ID: proof-1
proof value: omitted
Time Trial
The fresh target disclosed the same fetch, audit, evidence, response, and worker workflow with target-specific route names and values. Following that target’s own clues reproduced the incident. The repair passed all five regression checks, and a follow-up status request remained signed and allowed.
result CORRECT
completion flag (short): `44fa65a4…020f`
answer ID: proof-1
proof value: omitted
Mastery
The eight-target bundle combined four web workflows with four related authorization and worker cases: backup exposure, session-scoped case history, SQL injection, a PHP document viewer, Django authorization, a Fastify callback, FastAPI moderator review, and the Actix fetch-to-worker incident. Each proof was recovered from its assigned target and submitted under the matching proof-N answer ID.
result CORRECT
completion flag (short): `7ac57460…7389`
answer IDs: proof-1 through proof-8
proof values: omitted
Time to solve
The Single Solve started at 09:09:07 ET on 2026-10-31 and returned CORRECT at 09:23:25, after 14 min 18 s; the Time Trial took 50 s and the Mastery 2 min 19 s, finishing at 09:28:35.8 ET, 19 min 28 s after the first start. The Game Master returned no deadlines for these runs, so all three are unranked.
Takeaways
- Trace the whole chain. A fetch response did not prove worker execution; the audit and worker views supplied the missing evidence.
- Use the request log as a pivot. The logged target value connected the fetch event to the audit dispatch.
- Keep the repair narrow. Reject unsigned internal dispatches while preserving signed status operations.
- Verify the fix. The target’s regression checks and follow-up status request confirmed both blocking and continued availability.