Parallel requests passed a verification limit
The race is the window between the check and the write. Prove it on a limit you are allowed to cross, with a small number of requests, and quote the severity the program settled on.
- Original severity
- High (7 ~ 8.9) source-reported; not rescored by vulns.co
- Public source
- hackerone disclosure
- Program / vendor
- Tools for Humanity
- Product / surface
- World ID verification limit
- Weakness
- Race condition
- Affected boundary
- A maximum-verification counter and concurrent requests
- Disclosure date
- 2024-04-04
- Public status checked
- 2026-09-28
- Public attribution
- toormund
What the evidence established
The program's summary says parallel requests could pass a verification limit because the check was not synchronized. They moved enforcement into the database and paid a bounty. The public severity is a high range, after they lowered it from critical.
Why the impact was credible
The source reported that a limit meant to cap verifications could be exceeded by concurrent requests.
Durable engineering lesson
The race is the window between the check and the write. Prove it on a limit you are allowed to cross, with a small number of requests, and quote the severity the program settled on.
Control pattern
Enforce the limit in the store that records the count, so two requests cannot both pass a check that has not been written yet.
Primary public disclosure
Upstream availability and wording can change. Public status was last checked 2026-09-28.