The Analysis of the Popsicle Finance Security Incident

The Analysis of the Popsicle Finance Security Incident

On Aug 4th, 2021, Popsicle Finance suffered a huge financial loss (over $20M) from an attack [1]. After manual analysis, we confirm that it is a double-claiming attack, i.e., a loophole of its reward system allows the attacker to claim rewards repeatedly. In the following, we will use an attack transaction to illustrate the attack process and the root cause of the vulnerability.

Background

Popsicle Finance is a yield optimization platform which supports multiple vaults for different chains (e.g., Ethereum and BSC).

Specifically, a user first invokes the deposit function to provide liquidity, and gets Popsicle LP token (PLP for short). After that, Popsicle Finance will manage the liquidity (interacting with platforms like Uniswap) for the user to make profits. The user can invoke the withdraw function to fetch back the liquidity from Popsicle Finance, which will calculate the amount based on the PLP tokens. The incentive reward comes from the liquidity, which will be accumulated as the time goes by. The user can invoke the collectFees function to claim the rewards, which is the key of this attack.

Vulnerability Analysis

In the collectFees function, token0Reward and token1Reward (rewards of the corresponding LP token pair) are calculated for the user. The whole calculation logic is straightforward. However, the function uses a modifier named updateVault, which is used to update the rewards accordingly.

In short, updateVault will:

  1. first invokes the _earnFees function to get accumated fee from the pool;
  2. then invokes the _tokenPerShare function to update token0PerShareStored and token1PerShareStored, which represent the amounts of token0 and token1 in the pool for each share;
  3. finally invokes _fee0Earned and _fee1Earned functions to update the rewards for the user (i.e., token0Rewards and token1Rewards respectively).

Functions _fee0Earned and _fee1Earned share the same logic, i.e., implementing the following fomula (use token0 as an example):

user.token0Rewards += PLP.balanceOf(account) * (fee0PerShare - user.token0PerSharePaid) / 1e18

Note that the calculation is incremental, which means even the user does NOT hold PLP token, the calculated reward remains the value stored in token0Rewards.

Hence, we can conclude the following two observations:

  1. user's rewards are stored in token0Rewards and token1Rewards, which are not associated with any PLP token;
  2. the collectFees function only relies on the status of token0Rewards and token1Rewards, which means that rewards can be withdrawn without holding PLP token.

In the real world scenario, it means a user deposits money to a bank and the bank gives her a certificate of the deposit. Unfortunately, this certificate is neither anti-counterfeiting, nor associated with the user. In such a case, it is possible to make duplicates and spread them to others to gain profits from the bank.

Attack Flow

Briefly, the attacker took the following steps to launch the attack:

  1. created three contracts. One of them was used to launch the attack, while other two were used to invoke the collectFees function to fetch the rewards;
  2. utilized the Flash Loan, i.e., borrowing a large amount of liquidity from AAVE;
  3. launched the Deposit-Withdraw-CollectFees cycle to perform the attack (there are 8 cycles in total, and lots of liquidity has been withdrawn from multiple valuts of Popsicle Finance);
  4. returned the Flash Loan back to AAVE, and laundered the profits through Tornado.Cash.

Specifically, the Deposit-Withdraw-CollectFees cycle consists of several steps, which can be easily labelled and clearly summarized by using our online tool [2]:

Profit Analysis

In total, the attacker harvested $20M from Popsicle Finance, including 2.56K WETH, 96.2 WBTC, 160K DAI, 5.39M USDC, 4.98M USDT, 10.5K UNI. After that explotiation, the attacker first exchanged all the other tokens to ETH through Uniswap and WETH, and then performed money laundering by using Tornado.Cash.

Credits

Yufeng Hu, Ziling Lin, Junjie Fei, Lei Wu, Yajin Zhou @BlockSec

(In alphabetical order by the last name)

https://www.blocksecteam.com

Medium: https://blocksecteam.medium.com/

Twitter: https://twitter.com/BlockSecTeam

Contact: [email protected]

Reference

[1] https://twitter.com/defiprime/status/1422708265423556611

[2] https://tx.blocksecteam.com/

Sign up for the latest updates
Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

During the week of February 9 to February 15, 2026, three blockchain security incidents were reported with total losses of ~$657K. All incidents occurred on the BNB Smart Chain and involved flawed business logic in DeFi token contracts. The primary causes included an unchecked balance withdrawal from an intermediary contract that allowed donation-based inflation of a liquidity addition targeted by a sandwich attack, a post-swap deflationary clawback that returned sold tokens to the caller while draining pool reserves to create a repeatable price-manipulation primitive, and a token transfer override that burned tokens directly from a Uniswap V2 pair's balance and force-synced reserves within the same transaction to artificially inflate the token price.

Top 10 "Awesome" Security Incidents in 2025

Top 10 "Awesome" Security Incidents in 2025

To help the community learn from what happened, BlockSec selected ten incidents that stood out most this year. These cases were chosen not only for the scale of loss, but also for the distinct techniques involved, the unexpected twists in execution, and the new or underexplored attack surfaces they revealed.

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

On August 29, 2025, Panoptic disclosed a Cantina bounty finding and confirmed that, with support from Cantina and Seal911, it executed a rescue operation on August 25 to secure roughly $400K in funds. The issue stemmed from a flaw in Panoptic’s position fingerprint calculation algorithm, which could have enabled incorrect position identification and downstream fund risk.