It allows a malicious contract to repeatedly call back into the original contract before the first execution is complete, which can lead to unexpected behavior such as draining funds.
🧠 How Reentrancy Works (Simple Explanation):
1. A smart contract (e.g. a vault or bank) sends Ether to a user.
2. The user is actually a malicious contract.
3. When Ether is sent, the malicious contract’s fallback function is triggered.
4. Inside the fallback function, it calls back into the original contract before the balance has been updated.
5. This recursive call withdraws funds again and again, before the balance changes.
6. The attacker drains the contract.
📌 Real Example – The DAO Hack (2016):
- One of the biggest hacks in Ethereum history.
- ~$60 million worth of ETH was stolen.
- Root cause: reentrancy vulnerability.
Here's a more detailed explanation:
How it works:
A malicious contract can call back into the vulnerable contract while the initial function call is still in progress. This can happen if the vulnerable contract sends Ether or makes an external call before updating its own state.
Exploiting the vulnerability:
The attacker's contract can repeatedly call the vulnerable contract's functions, potentially draining its funds or manipulating its state before the original function call completes.
Example:
A contract with a withdraw function that sends funds to an address before updating the balance in the contract's storage can be vulnerable. An attacker could call this withdraw function, receive funds, and then call it again before the balance is updated, effectively draining the contract.
Consequences:
Reentrancy attacks can lead to significant financial losses for the vulnerable contract and can undermine trust in the smart contract system.
To prevent reentrancy attacks, developers should follow the "Checks-Effects-Interactions" pattern, where state changes are made before external calls. This ensures that the contract's internal state is updated before any external interactions can affect it.
