A contract sends funds, then updates its balance. Between those two steps, the attacker calls back in — and withdraws again. That is reentrancy.
Reentrancy happens when a contract makes an external call before updating its own state. The called contract — which the attacker controls — calls back into the original function while the balance still shows the old value. The withdraw runs twice on one balance.
The classic case is a pool or vault with a naive withdraw. It is the bug behind several famous nine-figure exploits, and it is still shipped because the pattern looks correct on first read.
Update state before any external call, or guard the entry with a reentrancy lock, or use the checks-effects-interactions pattern. The key is one rule: internal state must be consistent before you hand control to an untrusted address.
One to two weeks for a single contract, three to five for a full protocol with tests and a re-audit of fixes.
Yes — every audit includes 30 days of support and a free re-scan of fixed items.