How a contract can be tricked into repeating itself
Reentrancy is one of the oldest and most instructive vulnerability classes in smart contract security, and it follows directly from a fact about the EVM that is easy to overlook: when one contract calls another, control genuinely transfers to that second contract, and it can do anything it wants before returning control back, including calling straight back into the original contract. If the original contract already updated its internal bookkeeping before making that external call, this is harmless. But if it makes the external call first and only updates its state afterward, the second contract can call back in while the first contract's records still reflect the old, pre-withdrawal state. From the contract's perspective, it looks like a fresh, legitimate request, so it happily repeats the action, whether that is releasing funds, minting a token, or unlocking a resource, against a balance that was never actually decremented.
The classic setting for this is a withdrawal function that sends funds to a caller and only afterward subtracts the withdrawn amount from that caller's recorded balance. A malicious caller can be a contract whose fallback function, triggered automatically on receiving funds, immediately calls the withdrawal function again. Because the balance hasn't been decremented yet, the check still passes, and the cycle repeats, each iteration reading the same stale balance, until the loop is stopped deliberately or the contract runs out of funds or gas. The core lesson generalizes past the single 'send money then subtract' example: any function that lets an external call happen before its own state fully reflects the consequences of that call has this shape, whether the resource in question is a token balance, a voting weight, or a lock flag.