Incident Summary

On 25 January 2025, an attacker exploited a vulnerability in XPEPE’s TokenStaker contract which led to a 99% drop of the token price. The root cause was due to an un-revoked spend allowance when withdrawing staked tokens enabling the attacker to use the transferFrom() method to gain 100% extra tokens after each withdrawal from staking.

Key Transactions

Exploit Transaction: https://etherscan.io/tx/0xbdec39a74e620fc624f90483aff067b17044f81138e6c30038daf7f873159db4

Attack Flow

Addresses

Attack wallet: 0x269ff4d056252A30CAd249a4CD75cb9Bcfb1F46c

Attack contract: 0x64dc84faa300B5f27c7eBaE8D867d039337e5999

Vulnerable contract: 0x444156f2440D4CD7Ab84b4D0679476c6BDc61423

Step by Step

1. UniswapV3Pool.flash() → In order to maximise the amount of tokens gained the attacker used a flash loan to borrow all 49B XPEPE tokens available in the XPEPE 5 pool, which they then staked via TokenStaker contract 0x444156f2440D4CD7Ab84b4D0679476c6BDc61423.

2. TokenStaker.withdrawAll() → Immediately after staking, the attacker called the withdrawAll() function to remove their staked tokens. The totalAmount of tokens to return was then approved and transferred.

3. After withdrawing, the attacker called the transferFrom() function of the XPEPE contract. As the approval from step 2 was still in place the attacker could transfer tokens directly from the TokenStaker contract.

4. The attacker repeatedly cycled through steps 2 to 4: staking their balance, withdrawing it, and then calling transferFrom() to gain an additional 100% each time. Once all available XPEPE tokens had been drained, they sold them for 0.6805 ETH ($2,109.10).

Vulnerability

In the withdrawAll() function, tokens were approved to a user which allows them to retrieve their stake and rewards. The approval should have then been revoked once the user has claimed their tokens. The contract did contain a _spendAllowance() function which is used to update a user’s spend allowance but it was only called during transferFrom() and not the withdrawAll() function.

Fund Flow

The attacker’s wallet, 0x269ff4d056252A30CAd249a4CD75cb9Bcfb1F46c, was funded on 4 January 2025 via Tornado Cash on the Binance Smart Chain (BSC), 0.2 ETH was later bridged to Ethereum via Orbiter Bridge on 22 January.

Analysis of 0x269 shows that is also linked to several incidents:

• 6 December 2024: a linked address, 0xB1E2aFDb2c5854df5ba1Ff447Dfa5F5d1BEb0405, was involved in the ee_BAYC exploit which led to a $19.4K loss. (https://etherscan.io/tx/0x398275fab4a60c8af8e73c36c4e102918534ee66d3bf3e4b768f93a9565c31d0).

• 12 January 2025: an exploit on UniLend resulted in a $196K loss (https://bscscan.com/address/0x269ff4d056252a30cad249a4cd75cb9bcfb1f46c).
• 21 January 2025: The attacker attempted to exploit AST but failed (https://bscscan.com/tx/0x790ad0fddecaae5a27a2f1cc805d33925239f482b1fa73a42ca5571d20861987).
• 25 January 2025, 0x269f drained XPEPE tokens from 0x58e2.

On 2 February 2025, the attacker transferred 12ETH to Tornado Cash.

Conclusion

In 2024, exploits related to code vulnerabilities accounted for a total loss of ~$173M with an average loss of $795,080 per incident, highlighting the risks of deploying unaudited code.

To keep up to date on the latest incident alerts and statistics follow @certikalert on X, or read our latest analysis on certik.com.