On September 3, 2024, the PenPie project, which provides yield and veTokenomics boosting services for Pendle Finance, was exploited, resulting in a loss of approximately $27 million. Let's examine the details of how this attack took place.
Overview
Attacker address:
https://etherscan.io/address/0x7a2f4d625fb21f5e51562ce8dc2e722e12a61d1b
Attack transactions:
https://etherscan.io/tx/0x7e7f9548f301d3dd863eac94e6190cb742ab6aa9d7730549ff743bf84cbd21d1
https://etherscan.io/tx/0x42b2ec27c732100dd9037c76da415e10329ea41598de453bb0c0c9ea7ce0d8e5
Background
Pendle Finance allows users to trade future yield by splitting yield-bearing assets into two components, PT and YT:
PT (Principal Token): Represents ownership of the underlying asset (principal), which no longer generates yield after separation.
YT (Yield Token): Represents the right to receive future yield from the asset until maturity.
To create a new pair of PT and YT tokens, the creator needs to provide the SY contract address when calling the PendleYieldContractFactory.createYieldContract() function.
SY (Standardized Yield) is a token standard (EIP-5115) created by the Pendle team. It wraps any yield-bearing token and provides a standardized interface for interacting with the yield-generating mechanisms of those tokens.
If a user wants to deposit their tokens into the Pendle protocol, using stETH as an example, they would deposit their stETH into Pendle and receive SY-stETH (the Standardized Yield version of stETH). Pendle then splits this SY-stETH into PT-stETH and YT-stETH.
To enable trading between PT and SY tokens, Pendle markets (PendleMarketV3) are created between the PT and its corresponding SY token. The incentive tokens paid to liquidity providers are PENDLE tokens. By locking PENDLE, users can receive vePENDLE governance tokens, with their value being proportional to the amount and duration of the stake (up to a maximum of 2 years).
PenPie is a protocol built on top of Pendle Finance, designed to provide users with yield and veTokenomics boosting services. Integrated with Pendle Finance, PenPie focuses on locking PENDLE tokens to obtain governance rights and enhanced yield benefits within Pendle Finance.
PenPie allows market contracts created by Pendle to be registered in its PendleStaking contract, which is the main contract that holds vePENDLE positions on behalf of users to boost yield and voting power.
Exploit analysis
The attack can be divided into two steps, which can be analyzed through the two transactions below:
The first transaction
In the first transaction, the attacker attempted to inject a malicious SY contract to create a new pair of (PT, YT) using the PendleYieldContractFactory.createYieldContract() call, and then create a fake market using PendleMarketFactoryV3.createNewMarket(). This malicious SY contract would later be called by the PenPie contract to claim rewards.
With the newly created Pendle market, the attacker invoked the registerPenpiePool function of the PendleMarketRegisterHelper contract from PenPie to register this market for a corresponding PenPie reward pool. Any market created by PendleMarketFactoryV3 would be trusted by PenPie.
After registering, a new token, PRT (PenpieReceiptToken), corresponding to a Pendle market LP token, will be created. Additionally, a new rewarder contract (BaseRewardPoolV2) will be created to manage rewards (PENDLE tokens) for this Pendle market LP. The information about the stakingToken, receiptToken, and rewarder will then be added to the MasterPenpie contract.
Next, the attacker called the mintPY function of the PendleYieldToken contract. This function is used to tokenize the SY into PT and YT. Since the SY contract is controlled by the attacker, they can mint a large amount of PT and YT tokens.
Subsequently, the attacker provided the PT and SY tokens (with the SY tokens being minted arbitrarily by the attacker) to the Pendle market to mint LP tokens (fake_0x5b6c_PENDLE-LPT).
Then, the attacker called the depositMarket function of the PendleMarketDepositHelper from PenPie to deposit the Pendle market LP tokens and mint the corresponding PRTs (PenpieReceiptToken).
The second transaction
After setting up the fake market and pool in Pendle and PenPie, the attacker executed the second transaction to steal the funds. First, they needed to borrow a large amount of agETH and rswETH tokens using a flash loan from the BalancerVault.
By calling the batchHarvestMarketRewards function of the PendleStaking contract from PenPie, this triggered the redeemRewards function of the fake Pendle market and the claimRewards function of the attacker’s SY contract. When calling the claimRewards function, the attacker used the borrowed agETH and rswETH to add liquidity to the corresponding Pendle markets and then deposited these LP tokens into the PenPie pools, retaining the PRT tokens for later withdrawal. The actual goal was to trick the PenPie staking contract into recognizing these Pendle market LP tokens as reward tokens.
To trick the PenPie staking contract into recognizing the newly added market tokens (agETH and rswETH) as rewards, the attacker crafted their own getRewardTokens() function in the SY contract. This function was designed to include these two market tokens as rewards and would be called by the getRewardTokens() function from the market.
Since these two tokens (0x6010_PENDLE-LPT-agETH, 0x038c_PENDLE-LPT-rswETH) are added to the list of bonusTokens, they are sent as rewards to users via the rewarder contract in the queueNewRewards function.
Finally, the attacker called the multiclaim function of the MasterPenpie contract to withdraw all the rewards from the rewarder contract. With the PRT tokens (acquired while adding liquidity to PenPie in the claimRewards callback), the attacker can convert them back to market tokens by calling withdrawMarket from the PenPie contract and repay the loan.
Conclusion
The attacks, carried out on Ethereum and Arbitrum, targeted multiple PenPie pools, resulting in a loss of approximately $27 million. The root cause of the attack was the assumption that all markets created by the Pendle Factory contract were legitimate. This incident underscores the need for stringent security measures and thorough contract audits to protect against such vulnerabilities. Ensuring robust verification processes will be crucial in preventing future attacks.
