Back to all stories
Incident Analysis
Stars Arena Incident Analysis
Stars Arena Incident Analysis


On 7 October, 2023 SocialFi project Stars Arena was exploited via a reentrancy vulnerability for 266,103 AVAX, approximately $2.88 million. The incident was the largest reentrancy exploit to occur on the Avalanche chain in 2023. Stars Arena was also exploited two days prior on 5 October for roughly $2k by the same exploiter. This earlier incident likely drew increased scrutiny over the Stars Arena contract.

For information on what a reentrancy attack is, read our blog here


On 7 October Stars Arena posted an announcement on social media platform X that there had been a major security breach in their smart contract. stemp

The exploit transaction that Stars Arena were referring to shows externally owned address 0xa2e transferring 1 AVAX to the Stars Arena contract and receiving 266,103 AVAX in return.


Although the vulnerable contract is unverified, analysis of the decompiled contract shows that the vulnerable contract allows the transfer of platform native coins (AVAX) to external contracts which can lead to reentrancy issues. The attacker was able to re-enter a function and change a variable used to calculate how much AVAX to return to a user when they call the sellShare function. As a result, the attacker was able to gain 266,103 AVAX with a deposit of 1 AVAX.

Most of the fund were dispersed to 266 new EOAs each holding 1,000 AVAX (~$10.2K).


The incident happened just two days after another exploited vulnerability was fixed by Stars Arena in which users could sell zero shares in return for AVAX. The exploit wallet from this incident (0xa2e) is also linked to the exploit on 5 October. At the time of this incident, Stars Arena stated they were at war and that they were “being targeted by malicious actors” as “the malicious actors were trying to spend $5 to drain $1 in TVL”.


Attack Flow

Exploiter: 0xa2Ebf3FCD757e9BE1E58B643b6B5077D11b4ad7A

Transaction: 0x4f37ffecdad598f53b8d5a2d9df98e3c00fbda4328585eb9947a412b5fe17ac5

Stars Arena: Shares (proxy): 0xA481B139a1A654cA19d2074F174f17D7534e8CeC

Stars Arena: 0x8aF92C23a169B58c2E5AC656D8D8a23FC725080f

As the vulnerable contract is unverified. the following analysis is based on the transaction flow and decompiled version of the vulnerable contract.

  1. The attacker called function 0xe9ccf3a3() and deposited 1 AVAX to Stars Arena 0xA48The method invoke call() to transfer native coin (AVAX) which enables arbitrary call to external contracts.

ecb59d02-b541-4bd5-8e54-d0dc47850d96 s5 s6

  1. During the deposit function a call back was made to the exploiter. A callback gives the user an opportunity to call another function in the contract before the initial function has completed, which allowed the attacker perform reentrancy. They used this to call function 0x5632b2e4() (see hi-lighted text below) and change variable ‘owner_a0’ which serves as a weighted multiplier in price acquisition.


 3. The attacker then called the sellShares() function. The sellShares() function refers back to the modified variable in step 2 to calculate how much AVAX to return, as a result the attacker gained 274,332 AVAX.

Reentrancy Statistics

So far in 2023 we have recorded ten reentrancy exploits, two more than the eight we recorded in 2022, with losses reaching $69.5 million this year. This figure is in large part due to the approximately $52 million in losses related to the Vyper reentrancy vulnerability in July 2023.

This incident makes Stars Arena is the 5th largest reentrancy exploit recorded this year.



Reentrancy isn’t a particularly common exploit but it is one that can be devastating, as seen with the Vyper incident at the end of July, which you can read more about that here.

Understanding reentrancy is important part of securing smart contracts. Reentrancy can occur whenever a function makes a callback to a user. Developers should try to ensure that the smart contracts they deploy follow the process of Checks → Effects → Interactions in order to protect against reentrancy. Functions can be further protected by also using a Reentrancy Guard which prevents a function from being reentered but should be in addition to, and not replace, the process outlined above.