This exploit typically allows the attacker to drain the victim contract of its funds or manipulate its state in an unintended way.

How a Reentrancy Attack Works

1. The vulnerability occurs when a contract makes an external call (such as sending funds to an external address) before updating its own internal state, like the user's balance. The sequence of an attack generally unfolds as follows:

1. Attacker Initiates: An attacker deposits a small amount of cryptocurrency into a vulnerable contract and calls its withdrawal function.
2. External Call: The vulnerable function checks the attacker's balance and then initiates an external call to send the funds to the attacker's wallet address.
3. Malicious Callback: Because the recipient is a malicious smart contract, the act of receiving the funds automatically triggers the attacker's fallback or receive function.
4. Re-entry: Inside the malicious fallback function, code is included to immediately call the vulnerable withdrawal function again.
5. The Loop: Since the victim contract's balance or state hasn't been updated yet (that step was supposed to happen after the external call finished), the check for sufficient funds passes again, and more funds are sent. This recursive process continues until the victim contract's balance is drained.
6. The infamous DAO hack of 2016, which resulted in the theft of over $60 million worth of Ether and led to a hard fork of the Ethereum blockchain, is the most well-known example of a reentrancy attack.

Prevention and Mitigation

Developers can prevent reentrancy attacks by adhering to secure coding practices:

1. Checks-Effects-Interactions Pattern: The primary defense is to ensure that all state changes (effects) happen before any external calls (interactions). This way, any recursive call will see the updated state, making the re-entry attempt fail.
2. Reentrancy Guards: A special modifier can be added to functions to lock the contract during execution. The most common implementation uses OpenZeppelin's ReentrancyGuard contract, which prevents a function from being re-entered until the initial call is complete.
3. Pull over Push Payments: Instead of a contract automatically pushing funds to a user, the pull payment pattern requires users to withdraw funds themselves, often through an intermediary escrow contract.
4. Minimize External Calls: Critical functions that handle funds or alter contract state should minimize interactions with external contracts to reduce the attack surface.