Hello Pals, Elizeu here! another day, another post! 🙈

Writing this blog post while on the bus during my 10-hour trip, and what better way to spend the time than writing about reentrancy attacks? 🤷🏽‍♂️

Did you know that reentrancy attacks are one of the biggest threats to smart contracts, causing millions in losses?

Reentrancy attacks are one of the most common vulnerabilities in Solidity, and if you’re developing smart contracts, you need to understand how they work.

In this post, I’ll give you a beginner friendly introduction to reentrancy attacks.

By the end, you’ll have a solid foundation to dive deeper into smart contract security.
We’ll also implement a vulnerable contract from scratch to see this exploit in action.

In the end, we will see the reentrancy attack in action using the Remix IDE and also create some tests to exploit reentrancy using Foundry.

So, having a basic knowledge of Remix IDE and Foundry might help you get the best when it comes to testing smart contracts.

So, buckle up, take a deep breath, grab your favorite coffee, because things are about to get wild! 🔥🔥🔥🔥🔥

Introduction

1. What is reentrancy?

 A reentrancy attack occurs when a contract allows a function to be executed repeatedly through an external smart contract, without properly updating its internal state.

One of the most common consequences of reentrancy is the drainage of funds, which can lead to massive financial losses.

This vulnerability can be exploited in several ways, but the most common method is when a malicious contract makes external calls to the target contract, repeatedly withdrawing unauthorized funds before the contract updates its balance.

This type of attack can be devastating, especially when the vulnerable contract holds locked funds worth millions or even billions of dollars in Ether.

And the worst part? These attacks can happen within seconds if the vulnerability is exposed.

2. The DAO Attack

"The DAO” was an autonomous decentralized investment fund where members could vote on proposals and investment decisions.

The DAO contained smart contracts that would handle the movements of the locked funds in a complex and efficient manner.

One day in 2016, hackers found a vulnerability in the smart contracts that allowed them to drain more than 150 million dollars worth of Ether.

That event shook the crypto community, and to this day, when people discuss smart contract security, the DAO attack almost always comes up in the conversation. So you can imagine how tragic it was.

This attack affected Ethereum’s credibility and caused its value to drop significantly.

That tragic event was the reason behind the first hard fork of Ethereum, which led to the creation of Ethereum (ETH) and Ethereum Classic (ETC). As a result, The DAO was able to recover its funds.

This fork was highly controversial because not everyone agreed with the decision, especially those who believed in the principle of “code is law”, arguing that smart contracts should remain immutable once deployed on the blockchain.

For further reading on the DAO attack, check out the links below:
https://bit.ly/439cpc5
https://bit.ly/3X92UWr

Types of reentrancy attacks

1. Single Reentrancy Attack

This is the most common type of reentrancy attack.
In this attack, a vulnerable function, often responsible for sending funds to an accoun, is repeatedly called or re-entered, draining the contract’s funds.
Usually, the vulnerable function sends Ether first and only updates the state afterward, creating an opportunity for an external smart contract to exploit the flaw. This allows the attacker to repeatedly withdraw funds before the balance is properly updated.

2. Cross Reentrancy Attack

This type of attack occurs when two or more functions in a smart contract share and modify the same state.
An external smart contract can then call one or more of these functions in a malicious way to manipulate the state, allowing the attacker to bypass restrictions and drain funds.

3. Cross Contract Attack

In this type of attack, the attacker exploits a vulnerability that can exist when a group of smart contracts interact with each other.
The attacker can find a flaw in these interactions, allowing reentrancy in a vulnerable function within one of the contracts.
This type of attack is difficult to detect due to its complexity.

Creating a vulnerable smart contract

1. Basic code of a contract that allows reentrancy.

Enough theory and let’s see reentrancy in action by analyzing the vulnerable contract below (code available on my GitHub).

Bank Contract

That’s a simple smart contract that allows accounts to deposit Ether and withdraw any desired amount, as long as it does not exceed the available balance.

2. Detailed explanation of the vulnerable part of the code.

The contract above does what it is meant to do very well, but one of its functions is highly vulnerable.
The vulnerable function we’re talking about is the withdraw() function.
Let’s first understand what the withdraw() function does.

At the beginning of its execution, it first verifies whether the total deposited Ether in the smart contract for the user is greater than or equal to the desired withdrawal amount.

If that’s not the case, a revert will occur, and no withdrawal will happen.

If it passes the check, the withdrawal will proceed, and after that, the balances will be updated.

Well, you might think there is no issue at all with updating the balance either at the beginning or at the end, given that the code executes synchronously and in order, even if the function is called multiple times.

Well, the statement above is true, but there’s a catch.

What if I told you that the balance might not update immediately after the withdrawal on line 20 because something else could interrupt the process, triggering the execution of another function in an external smart contract, which would then recursively re-execute the withdraw() function to keep withdrawing more Ether than the user originally deposited?

Sound gibberish? Don’t worry, I understand. Let’s see the code of a malicious contract that will be responsible for the attack, and things will become crystal clear.

Creating an attack contract.

1. Basic code of an attack contract.

Below is the code of a smart contract that will exploit the vulnerability in the withdraw() function of the vulnerable smart contract mentioned previously.

Attacker Contract

The smart contract above has one constructor that receives the address of the deployed Bank smart contract.

The attack() function receives a parameter that corresponds to the amount of Ether to deposit in the Bank smart contract.

We can see that in its implementation, the desired amount is deposited in the Bank, and right after, the same amount is withdrawn.

The receive() function is a native Solidity function that is called automatically every time the smart contract receives Ether from an EOA (Externally Owned Account) or another smart contract.

Understanding the reentrancy attack flow is where most developers struggle.

This is understandable because smart contract execution in Solidity does not follow the same logic as other programming languages in most environments—it has its own unique complexities.

Below, we’ll go through the step-by-step execution of the attack.

For this example, we assume that the Bank contract already contains a total locked value of 50 ETH.

1 - Attacker Contract (Line 14):

• The Attacker contract calls the deposit() function of the Bank contract, with msg.value set to the amount defined in the amount parameter.
• For this example, let’s assume the attacker deposits 10 ETH.
• The deposit() function executes, and 10 ETH is transferred to the Bank contract.
• After the deposit, the Bank contract balance increases to 60 ETH.

2 - Attacker Contract (Line 18):
• The Attacker contract calls the withdraw() function of the Bank contract, requesting 10 ETH.

3 - Bank Contract (Line 17):
• The withdrawal condition passes, since the attacker has 10 ETH deposited in the Bank contract.

4 - Bank Contract (Line 20):
• The Bank contract sends 10 ETH back to the Attacker contract using call{value: amount}("").

5 - Bank Contract (Line 21):
• The execution after Line 20 is paused because the transfer triggers the receive() function in the Attacker contract.
• Since the receive() function is triggered before the balance is updated, the attacker still appears to have 10 ETH deposited in the Bank contract.

6 - Attacker Contract (Line 22)
• At this point, the Bank contract’s balance is now 50 ETH.
• The if statement inside the Attacker contract’s receive() function passes because there are still enough funds in the Bank contract.

7 - Attacker Contract (Line 23)
• The Attacker contract calls withdraw() again, re-entering the Bank contract.
• Since the Bank contract still believes the attacker has 10 ETH, the withdrawal is processed again.

8 - Bank Contract (Line 17)
• The balance of msg.sender (the Attacker contract) is still 10 ETH, because it was never updated in the previous execution.
• Since the balance is still the same, the if condition passes again.

9 - Bank Contract (Line 20)
• The Attacker contract withdraws another 10 ETH.

10 - Steps 5 to 9 Repeat in a Loop
• This loop continues recursively, allowing the Attacker contract to drain the Bank contract.
• The process stops only when the Bank contract’s total balance is less than 10 ETH (or is completely drained).

11 - Attacker Contract (Line 22):
• When the Bank contract balance is less than 10 ETH, the if statement in the Attacker contract fails.
• As a result, the withdraw function in the Bank contract (Lines 21-26) is finally executed for each withdrawal that was in the Call Frame.

12 - Final Verdict
• In a single transaction, the Attacker contract successfully drained all 60 ETH from the Bank contract.
• The entire process happened in seconds.

In a nutshell, you may have noticed that the primary issue allowing this attack to happen is that, if for some reason, the withdraw() function in the Bank contract pauses its execution due to the receive() function being triggered in the external smart contract (Attacker contract), then the withdraw() function can be called recursively, repeatedly withdrawing funds as long as there is Ether available in the Bank contract.

Each of these recursive calls creates a new stack frame in the Call Stack, meaning that within that execution, the balance will remain unchanged, reflecting the old value that existed before the withdrawals started. This allows the attacker to keep making withdrawals without triggering any balance updates.

The balance is only updated once there are no more funds left to withdraw, at which point all the pending function calls in the Call Stack will start executing one by one, but still based on the outdated balance.
By that time, the contract will already be drained.

---

Wow! This is getting intense, isn’t it?
Before you continue, take a deep breath, grab some water, stretch your legs, or even take a quick walk in the park—because we’re just getting started!
There’s still more to come!

It’s incredible to see how function execution and transaction processing in a smart contract work under the hood.

The deeper we dive, the more we realize how small details, like the order of state updates, can have massive security implications.

Understanding these mechanics is key to writing secure Solidity code and avoiding costly vulnerabilities.

Now, let’s try to reproduce the reentrancy attack ourselves using the Remix IDE.

Demonstration in Remix:
How to manually exploit the vulnerability.

1. Deployment of smart contracts

I’m a strong believer that in a learning process, one retains better information when practice is added to the equation.

So, here’s what we’re going to do: we’ll use Remix IDE to deploy both the Bank and Attacker contracts, allowing us to see firsthand how the funds in the bank are drained.

To start, go to https://remix.ethereum.org/, and in the file explorer section create a file called Bank.sol and paste the code below

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;

contract Bank {
    mapping(address => uint256) public balances;
    uint256 public totalDeposits = 0;
    address public owner;

    error NotEnoughFunds(uint256 requested, uint256 available);

    function deposit() public payable {
        balances[msg.sender] += msg.value;
        totalDeposits += msg.value;
    }

    function withdraw(uint _amount) public {
        if (balances[msg.sender] < _amount) {
            revert NotEnoughFunds(_amount, balances[msg.sender]);
        }
        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success, "The transfer has failed.");

        //Condition to avoid underflow
        if (balances[msg.sender] >= _amount) {
            balances[msg.sender] -= _amount;
        }
    }
}

Create another file called Attacker.sol and paste the code below as well:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;
import {Bank} from "./Bank.sol";

contract Attacker {
    Bank public bank;

    constructor(address payable _bank) {
        bank = Bank(_bank);
    }

    function attack(uint256 amount) public {
        // The attacker first deposits into the bank to establish a legitimate balance
        bank.deposit{value: amount}();

        // The attacker initiates the attack by calling `withdraw()`
        // This triggers the attacker's `receive()` function, which recursively calls `withdraw()` again
        bank.withdraw(amount);
    }

    receive() external payable {
        if (address(bank).balance >= msg.value) {
            bank.withdraw(msg.value);
        }
    }
}

Still in the File Explorer, select each of the recently created smart contract files and compile them by clicking the compile button at the top (see image below).

Now you need to deploy both the Attacker and Bank smart contracts.
Let’s start with the Bank smart contract.

To compile the Bank contract, first make sure that the Bank.sol file is open in the IDE.

Then, go to the “Deploy & Run Transactions” tab, and under "CONTRACT", ensure that Bank.sol is selected as the contract to be deployed.

Press the Deploy button to deploy the contract.

If everything goes well, the contract will be listed in the Deployed Contracts section inside the "Deploy & Run Transactions" tab.

Time to deploy the Attacker.sol contract.

Make sure the Attacker.sol contract is open, then navigate to the "Deploy & Run Transactions" tab and ensure that the selected contract to be deployed is Attacker.sol (see image below).

You might notice that this time, the Deploy button is disabled by default and requires you to provide an input.

Remember that the Attacker contract has a constructor that receives one parameter of type address.

In this case, it should be the address of the Bank contract that was deployed.

So, in the Deployed Contracts section, select the copy address button of the recently deployed Bank contract.

In the image below, the button is highlighted in yellow.

After copying the address, paste it into the text field next to the Deploy button, and this time, the Deploy button will be enabled.

Press the Deploy button, and if everything goes well, you will see two deployed contracts in the "Deployed Contracts" section.

2. Add depoists to the Bank Contract

Now that both contracts are deployed, we need to simulate the deposit of funds from different accounts.

Remix provides us with test accounts that come with a sufficient amount of Ether for testing.

If you select the dropdown menu under "ACCOUNT" in the "Deploy & Run Transactions" tab, you will see a list of available accounts, with each account’s Ether balance displayed in parentheses.

What we’re going to do is deposit 50 Ether each using two different accounts from the list.

Assuming you are already inside the "Deploy & Run Transactions" tab, below "ACCOUNT", select the first account.

Below "VALUE", in the input field, type 50, and in the dropdown next to the input, select "Ether".

Below "Deployed Contracts", expand the deployed contract BANK and select the "deposit" button.
Behind the scenes, this will execute the payable deposit function, which will simultaneously send 50 Ether to the Bank contract.

Repeat the one more time the deposit process with a different account,, and once Repeat the deposit process one more time using a different account, and once done, the total balance of the deployed contract should be 100 ETH (see image below).

If you try to withdraw more than you deposited through Remix, you will get an error, which can be confirmed through the console logs.

As you see in the image above, it reverts with the error "NotEnoughFunds".

This shows that the smart contract is working as expected, even though we already know it is vulnerable for the obvious reasons we’ve previously discussed.

Well, we’ve finished the deposit part.
Now let’s move on to the most anticipated reentrancy attack!

3. Attack the Bank Contract

Aallll riiiiiight (à la Freddie Mercury 😆)
The contracts are deployed, and we’ve already made two deposits of 50 ETH each.

Now, we will interact with the Attacker contract to see if we can drain all the funds from the Bank contract by withdrawing more than we deposited.

So, let’s start with the attack!

Assuming you are already inside the “Deploy & Run Transactions” tab, below “ACCOUNT”, select an account that you haven’t used for any deposits before (usually a fresh test account with 100 ETH). Then, below “VALUE”, enter 50 ETH.

Below “Deployed Contracts”, expand the ATTACKER contract and press the “attack” button.

Once pressed, the Attacker contract will receive 50 ETH from the selected account. Once the funds are received, the Attacker contract will deposit 50 ETH to simulate a legitimate deposit and will immediately execute the withdraw method from the deployed Bank contract to withdraw the 50 ETH already deposited.

As we already saw before, the Bank.withdraw() method in its implementation contains a line that transfers the funds to the sender.
Once executed, this triggers the receive() function before updating the balances, which in turn allows the Bank.withdraw() function to be called again, recursively triggering receive() repeatedly until there are no more funds available in the Bank contract.

If the attack went as planned, the Attacker contract will have a total of 150 ETH in its balance.
That includes the initial 50 ETH from the attacker contract plus the total 100 ETH from the first two deposits made to the Bank contract by two different accounts.

Kudos to you! Now you can brag about hacking your first smart contract 🤣

Attack Tests in Foundry.

1. The exploit test

Besides Remix, you can test reentrancy using tests in Foundry.
In this tutorial, I won’t explain how to set up Foundry or how it works because it’s out of scope and would turn this post into a bible.
You can check the link below to learn how to set up Foundry on your machine:
https://book.getfoundry.sh/getting-started/installation*

d if you want to learn more about Foundry, you can check the links below first and then come back when you’re comfortable.
https://www.youtube.com/watch?v=de_fomBbLmM
https://book.getfoundry.sh/

Below is an excerpt from the exploit test that I created so you can give it a try in Foundry.
The full code is on my GitHub:
https://github.com/serialdatabus/foundry-reentrancy-test

This test does exactly what we did with Remix, but in an automated way.

Lines 98 to 103 simulate a deposit of funds from honest clients.

If you’re new to Foundry, you might not fully understand the purpose of vm.addr(), vm.deal(), and vm.prank() functions just by looking at the lines mentioned above.

These are special functions known as cheat codes, which allow us to modify the state of the blockchain in a “cheaty” way—that’s why they’re called cheat codes.

In a nutshell:

• vm.addr() - Creates a fake user account on the fly.
• vm.deal() - Sends any amount of Ether to an account.
• vm.prank() - Sets the account that will execute the next transaction.

The more you work with Foundry, the more you will understand the advantages of using cheat codes.

Now that you understand the deposit logic, we can look at line 115, where the attack really happens.

In the Remix demonstration, you saw that when we call the Attacker.attack() function, it should receive Ether from the account executing the method.
However, in the code, it looks like we haven’t explicitly set any sender account.

Well, that’s not an issue, because by default, in Foundry tests, all transactions are executed by the test account that Foundry provides.
This test account has a huge amount of Ether available (if you’re interested in details, something around 2²⁵⁶ - 1 wei).

Yeah, it’s fair to say that in Foundry, you can get a taste of what it feels like to be a crypto millionaire 💸💸💸💸.

To finalize, you can view logs in the code that record the before and after balances of both Bank and Attacker contracts, so you can see that the attack really happened.

How to prevent the reentrancy attack

1. The Checks-Effects-Interactions pattern explained.

The Checks-Effects-Interactions pattern is a way of writing smart contracts that helps prevent reentrancy attacks.

This pattern suggests that to write secure Solidity functions, we should follow these steps in order:

Checks:
Before starting any type of interaction or state change, the first thing to do is perform the most critical checks.
This could include verifying the account balance, checking if the caller has permission to execute the function, or performing any other necessary validation.

Effects:
If the checks pass, we can proceed to update any necessary state.
For example, this could mean updating an account’s balance before any funds are transferred.

Interactions:
Once the state has been securely updated, we can interact with other smart contracts or send Ether.

By following this approach, even if an external contract manages to re-enter a critical function, the attack will not succeed because the state would have already been updated.

As a result, any validations that would normally allow the attack to proceed will fail.

With this in mind, to ensure the withdraw function is not vulnerable, we should change the implementation so that all checks are performed before sending any Ether.

Below is a safe version of the withdraw function.

In this version, the balance is updated before sending Ether, which means that a reentrancy attack would be impossible.

2. Using reentrancyGuard from OpenZeppelin.

You can also use a modifier implemented by OpenZeppelin that prevents any type of reentrancy in your smart contract.

The implementation of the modifier can be found in the link below:
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol

To apply this modifier, you would need to install the OpenZeppelin Contracts in Foundry using, for example, the command: "forge install OpenZeppelin/openzeppelin-contracts" (There are other methods as well).

Alternatively, you can import the ReentrancyGuard.sol contract directly into your project.

If you’d like another post where I talk about setting up and installing OpenZeppelin Contracts, let me know in the comments or hit me up on LinkedIn.

Below is an implementation of the Bank smart contract using the nonReentrant() modifier from OpenZeppelin.

There are three changes in this smart contract:

1. In line 3, we import the ReentrancyGuard.sol contract.
2. In line 5, the Bank contract extends from the ReentrancyGuard contract.
3. In line 24, we apply the nonReentrant modifier.

Applying this modifier saves you a lot of work, but that doesn’t mean you should avoid taking other security measures.

Conclusion and Next Steps

By now, you should have a solid understanding of how the reentrancy attack works.

There are, of course, many other ways to secure smart contracts, but what you’ve learned here provides a strong foundation to explore additional security measures for your own projects.

By the way, all the code for the Attack, Bank, and Exploit test can be found on my GitHub:
https://github.com/serialdatabus/foundry-reentrancy-test

If you have any questions, feel free to reach out at elizeudev@thecodepal.com, I’m always happy to help!

Stay curious and keep building. See you in the next post pals 😉!