A gift-card service checks that a code still holds $50, then redeems it. An attacker fires forty redemption requests in the same instant. Each one reads the $50 balance before any of them finishes writing the new balance, so the service honors the card forty times. No password was broken and no input was injected. The bug was in the timing.
That is a race condition, one of the coding weaknesses the CompTIA Security+ SY0-801 exam lists under objective 2.4, which asks you to explain types of vulnerabilities and attack surfaces. This lesson covers four application and code weaknesses the objective names: race conditions, malicious updates, hardcoded secrets, and unsafe exception handling. These are not attacks you watch arrive in a log so much as flaws that invite the attacks in the rest of this section. Knowing why each one is dangerous, and the development practice that removes it, is what the exam expects.
A race condition exploits the gap between check and use
A race condition is a flaw where the outcome depends on the timing of events that are supposed to happen in order, and an attacker who controls the timing gets a result the developer never intended. The best-known form has its own name: time-of-check to time-of-use, abbreviated TOCTOU. The program checks a condition at one moment (time of check) and acts on it a moment later (time of use), and in the gap between them something changes.
The gift-card example is a clean TOCTOU. The check "does this card have $50?" and the use "subtract $50 and deliver the goods" are two separate steps. When many requests run at once, they all pass the check against the same starting balance before any of them completes the use, so one $50 balance is spent many times. The same pattern causes double-spending in payment systems, duplicate withdrawals, and coupons that apply more times than allowed.
TOCTOU also shows up in filesystem operations with elevated privileges. A privileged program verifies that a file is safe to open, then opens it a moment later, and in that window an attacker swaps the file for a symbolic link pointing at a protected file. The program's check passed on the safe file, but the use lands on the attacker's target. This is a classic local privilege-escalation route, which ties back to the privilege escalation lesson earlier in this section.
The defense is to close the gap so the check and the use cannot be separated. In practice that means making the operation atomic: use a single database transaction with the right isolation or a conditional update that checks and changes the balance in one indivisible step, use locking so only one request can act at a time, and have the database enforce the rule rather than trusting application-level checks. On the exam, wording about concurrent requests, "at the same time," double-spending, or a check that is no longer true by the time it is used points at a race condition, and atomic operations or locking is the fix.