The MesaNet Portal hosts a "Rail Broadcasts" application accessible through a JSON gateway API. A low-privilege operator account can interact with several broadcast endpoints, but a confidential note owned by a privileged automated user sits just out of reach. The challenge requires chaining the broadcast creation pipeline with the automated oversight system to escalate access without ever touching the privileged session directly.
Objective: Determine what the `/api/rail/review` endpoint does, which user triggers it, and how that user interacts with the broadcast viewer.
Context: You now know there is a note you can't read and an endpoint called `/api/rail/review` that you haven't tested yet. Send a review request and observe the response carefully — it describes an 'Automated Oversight System'. Think about what that system does and whose session it uses.
Only reveal the ones you need. Claude tracks how many you used to calibrate the feedback.
Send a POST to `/api/rail/review` via the gateway with `data: {"view": "current"}`. Read the response message. Then look at what URL pattern the bot would visit based on that `view` parameter.
The response confirms that a headless browser bot queues up to visit `/apps/rail?view=<value>`. This bot runs with its own privileged session (user `sysbot`, user id `4`). Whatever page it renders, it does so as `sysbot` — the same user who owns note 6.
The bot opens `/apps/rail?view=display` (or `view=current`). The page JS then calls `fetch('/api/rail/' + view)`, gets `{html: ...}`, and writes `data.html` directly into `document.getElementById('broadcast-content').innerHTML`. If you control what's in `data.html`, you control what runs in the bot's browser.