Race condition
In application security, a race condition is a flaw where the result depends on the order in which concurrent requests are processed, because a check and the action it authorises are not atomic. Sending the same request many times in parallel makes the application act on state it has already invalidated.
The classic shape is limit overrun: a voucher marked single use, a withdrawal checked against a balance, an invitation that grants one seat. The code reads the state, decides the action is allowed, and writes the result, and between the read and the write another request has already passed the same check. The window is often a few milliseconds, which is why it survives functional testing and turns up as a business logic flaw in an audit.
Exploiting it is a timing problem, not a volume problem, so it is not the same thing as defeating rate limiting. What works is sending the requests so they arrive together rather than quickly: grouping them so the final bytes of each go out at once removes most of the network jitter that otherwise spreads them apart. If a target is reachable and a limit is enforced in application code rather than by the database, it is worth testing.
In a report the finding is written against the transaction, not against the endpoint, and the evidence is the resulting state: two accepted uses of a single use token, a balance below zero, two accounts holding one seat. The fix is a database level constraint or lock, and this is part of the web application testing where concurrency is part of the logic review.