Timing
The Window Between Two Heartbeats
Echo catches signals with the wrong rhythm — a request replayed a beat too late, a voice that loops instead of landing once. What she's never had to think about is two real signals arriving in the exact same beat.
You have 100 reward points. Each redemption costs 100. One request at a time will only ever get you one redemption — and you need five. If nothing checks the gap between "can I?" and "doing it," does it matter how many showed up at once?
Find the flag, in the format SPAM{this_is_an_example}.
Your wallet is tied to this browser's wallet cookie. This container resets every 24 hours.
What's the vulnerability?
- A race condition happens when correctness depends on the timing of events the system doesn't control.
- Time-of-check to time-of-use (TOCTOU): code checks whether an action is allowed, then performs it later — and if requests arrive in that gap, the check no longer reflects reality.
- Each concurrent request is valid at the moment it's checked, even though together they never should have all been allowed.
Why does it matter?
Anywhere a balance, a limit, or a one-time action is enforced by "check, then act" instead of one atomic operation, concurrent requests can slip through together. In financial systems, this is the classic shape of a double-spend.
How to fix it
Make check-and-act a single atomic operation — a database transaction with proper isolation, an atomic conditional decrement, or a lock held for the whole operation — never two separate steps that anything else can slip between.