Re-entrancy Attack: Technical Know-how and Real Use Case

by ImmuneBytes

Here we are with the Part II of the All About Smart Contract Bugs & Security series, discussing the most commonly overlooked bug in smart contracts, the Re-entrancy bug. Make sure to check out Part-I, where we spotlight the notorious Flash loan attacks.

You have possibly heard of the DAO Hack that happened in 2016. Why did it happen? What caused the organization to lose $50M?

In the context of Blockchains and Ethereum smart contracts, re-entrancy can lead to some serious vulnerabilities. According to the computer world, when a process is re-entrant, its execution can be interrupted and initiated again and both executions can complete without any errors.

One of the significant dangers of calling external contracts is that they may take over the control flow, and make changes to the data that the calling function wasn’t expecting. The re-entrancy vulnerability had functions calling themselves repeatedly before the first call was ended. Take a look at the code below:

mapping (address => uint) private userBalances;


function withdrawBalance() public {

    uint amountToWithdraw = userBalances[msg.sender];

    (bool success, ) =“”);

// At this point, the caller’s code is executed, and can call withdrawBalance again


    userBalances[msg.sender] = 0;


Since the sender’s balance is not set to 0 by the very end of the function, the recursive calls made will succeed, allowing the hacker to withdraw over and over again

Real-life example: The DAO Hack

The most popular example of a re-entrancy exploit is the infamous DAO Hack, back in 2016. Let’s see what went wrong.

The Decentralized Autonomous Organization (known as The DAO) was supposed to function as a venture capital fund for the crypto and DeFi space. During its creation period, anyone was allowed to send Ether to a unique wallet in exchange for DAO tokens. This creation period was an unforeseen success as it gathered 12.7M Ether (approximately $150M at the time), making DAO the biggest crowdfund ever.

However, on June 17, 2016, a hacker found a vulnerability that allowed him to drain DAO’s funds. In the first few hours of the attack, 3.6M ETH was stolen, $70 million at the time.

Let’s consider a simplified version of the DAO smart contract with a re-entrancy vulnerability in the withdrawBalance() function :

Contract BasicDAO {

   Mapping (address => uint ) public balances;

   //transfer the entire balance of the caller of this function to the caller

    Function withdrawBalance() public {

Book result =[msg.sender])();




//update balance of the withdrawer




Additonal Resource: Most Popular Smart Contract Vulnerabilities

What is wrong in the code is the fact that the developers did not take into consideration the possibility of a recursive call and the fact that the contract first sent the ETH funds and then updated the internal balance.

Had the code been written correctly, this attack could have been avoided. As the world edges more and more towards the Crypto world, safeguarding it becomes essential and the need to get an Audit for smart contracts stands paramount. We, at ImmuneBytes, test your Smart Contract against these and many other bugs and vulnerabilities, helping you stay ahead and secure your project. Contact us to get an Audit for your smart contract.

Keep an eye out for the next article of this series this Thursday to know how a Time Dependency in your smart contract can induce the downfall of your mainnet.

Spread the love

You may also like