Reentrancy
What is a reentrancy attack?
The definition above describes the loop. The mechanism that permits it is that an external call hands control to the recipient: execution passes to code the calling smart contract does not control, and that code can call back into the original function before it has written its state changes. Balances still read as they did at entry, so the same withdrawal succeeds repeatedly.
The standard defense is ordering. Update state before making any external call, a convention known as checks, effects, interactions, and add a mutex that blocks reentry while a function is running. Both are well understood and are checked in any competent audit, which is why the naive version is now rare. Token standards that call a hook on the recipient during a transfer reintroduce the same control transfer into code that looks like a simple send.
The variant that still catches integrators is read-only reentrancy. A view function has no state to corrupt and is often left unguarded, but during a reentrant call it reports values from a contract that is midway through updating. A protocol reading that function for a price or a share value receives a number that is briefly wrong, and acts on it.
The decision for anyone integrating is therefore not whether a protocol carries a guard, but whether its view functions can be called during someone else's transaction.