Penpie Exploit: A Technical Post-Mortem Analysis

4 min readSep 6, 2024

Incident Overview

On September 3, 2024, at 18:23 UTC, the Penpie platform fell victim to a sophisticated exploit, resulting in the theft of 11,113.6 ETH (approximately $27,348,259) on Ethereum and Arbitrum. The attack leveraged a re-entrancy vulnerability in the platform’s smart contracts, explicitly targeting the reward distribution mechanism.

Key Details

Date: September 3, 2024.
Affected Networks: Arbitrum and Ethereum.
Affected Liquidity Pools: agETH, rswETH, stETH, sUSDe and gUSDC.
Stolen Assets: 11,113.6 ETH (~$27,348,259).
Mitigation: Deposits and withdrawals paused; front-end restored.

Attacker on-chain wallet addresses:

Key transactions

Malicious market deployments:

Example of fund draining:

Technical Root Cause Analysis

As Solidity developers, it’s crucial to understand the intricacies of this exploit. The root cause was a re-entrancy protection vulnerability in the PendleStakingBaseUpg::batchHarvestMarketRewards() function. This vulnerability and Penpie’s permissionless registration of new Pendle markets created the perfect storm for an attacker to exploit.

The attacker’s modus operandi was as follows:

1. Deploy a malicious Pendle Market contract with a specially crafted SY (Synthetic Yield) contract.

2. Register this malicious market on Penpie, exploiting the platform’s open system for permissionless registration.

3. During the reward harvesting, the malicious SY contract re-entered the PendleStakingBaseUpg::depositMarket() function.

4. This re-entrancy allowed the attacker to add new deposits from a flash loan repeatedly.

5. Consequently, the attacker manipulated the reward token and amounts sent to the fake Pendle market depositor (the attacker(s) themselves).

From a smart contract security perspective, this exploit highlights the critical importance of implementing robust re-entrancy protection, especially in functions handling reward distribution and token transfers.

Detailed Attack Flow

1. The attacker created a malicious Pendle Market with a crafted SY contract for re-entrancy.

2. A pool was created on Penpie using this malicious Pendle Market.

3. Multiple malicious Pendle Markets were created by minting many fake YT and SY tokens.

4. These malicious Pendle Markets were deposited on Penpie in large numbers.

5. The attacker then flash-loaned substantial amounts of wstETH, sUSDe, egETH, and rswETH from Balancer, storing them in the attack SY contract.

6. The PendleStaking.batchHarvestMarketRewards function was called on the malicious Pendle Market.

7. During this call, the malicious SY contract returned Pendle Market tokens of the flash-loaned assets as reward tokens.

8. The claimReward function on the malicious SY contract was invoked, depositing the flash-loaned Pendle Market tokens into PendleStaking to manipulate the reward amount (this step involved the re-entrancy attack).

9. PendleStaking then sent the manipulated reward tokens and amounts to the RewardDistributor, attributing them to the fake Pendle Market depositor.

10. The attacker, the sole depositor in the fake Pendle Market, claimed all rewards.

11. Finally, the attacker withdrew from the fake Pendle Market and converted the Pendle Market tokens back to their original asset forms.

Smart Contract Vulnerabilities and Audit History

The `PendleStakingbaseUpg.batchHarvest` function was not initially flagged as a concern in Zokyo’s June 2023 audit report. WatchPug’s audit did note potential issues with incorrect distribution but didn’t highlight re-entrancy vulnerabilities.

A critical change occurred in May 2024 when Penpie introduced permissionless pool registration. AstraSec audited this feature, but the PendleStakingBaseUpg contract wasn’t included in the audit scope as it hadn’t undergone significant changes.

This sequence of events underscores the importance of comprehensive, regular audits, especially when introducing new features that can interact with existing contract logic in unforeseen ways.

Lessons for Solidity Developers

1. Holistic Auditing

When introducing new features, consider their potential interactions with existing contract logic. A full re-audit may be necessary even if core contracts have stayed the same.

2. Periodic Full Protocol Audits

As protocols evolve, conduct regular comprehensive audits to ensure new vulnerabilities are not introduced by interacting with new and existing features.

3. Real-time Monitoring and Auto-pausing

Implement robust monitoring systems with auto-pausing mechanisms to respond to anomalies quickly.

4. R-eentrancy Protection

Consistently implement and thoroughly test re-entrancy guards, especially in functions handling token transfers or state changes.

5. Permissionless Features

Consider all potential attack vectors, including malicious contract interactions, when implementing permissionless features.

As Web3 security experts, we must learn from incidents like these to build more resilient and secure decentralized systems. This exploit is a stark reminder of the complexities involved in DeFi protocol development and the constant vigilance required to protect user funds.

Olympix: Your Partner in Secure Smart Contracts

Olympix provides advanced Solidity analysis tools to help developers identify and fix vulnerabilities before they become critical exploits.

Visit our website to learn more.

Join our beta program to fortify your smart contracts and proactively shield them from exploits in the evolving Web3 security landscape.

Connect with us on: