Explained: The Penpie Hack (September 2024)

Penpie is a yield farming protocol hosted on Pendle Finance. In September 2024, the protocol was the victim of a $27 million hack.

Inside the Attack

The root cause of the Penpie hack was a reentrancy vulnerability in the _harvestBatchMarketRewards function of the project’s staking contract. This type of vulnerability allows an attacker to call a function multiple times before it is able to make important state updates. Since the vulnerable function lacked proper reentrancy defenses, the attacker was able to inflate the reward balances that would be assigned to them.

The Penpie exploited this vulnerability by creating a fake market on Pendle where fake versions of Pendle’s underlying Standardized Yield (SY) token were linked to Pendle Liquidity Provider tokens. With these fake tokens, the attacker was able to exploit the reentrancy vulnerability to claim rewards with these fake tokens. This was possible because the smart contract mistakenly assumed that pool contracts would be benign and didn’t perform proper validation.

By exploiting the vulnerability, the attacker was able to inflate their reward balance. As a result, they could drain an estimated $27 million from the protocol.

After the attack was identified, the Pendle and Penpie teams froze their protocols. Moments after Penpie’s freeze, another malicious contract was deployed, indicating that the attacker was likely targeting the remaining $105 million that could have been stolen by the attacker.

After the attack, Penpie sent a Twitter/X message to the attacker requesting that the stolen funds be returned in exchange for a bounty. However, the attacker elected not to return the funds and began laundering them via Tornado Cash.

Lessons Learned from the Attack

The Penpie hack demonstrated the potential impacts of common smart contract vulnerabilities. The Penpie attacker was able to deploy malicious markets on Penpie, exploit a reentrancy vulnerability, and drain millions from the protocol. This was all possible because the contracts lacked controls on who could deploy markets, reentrancy protection, and input validation on data provided by markets assumed to be trusted.

This incident underscores the importance of comprehensive smart contract security audits before launching code to the blockchain. While the protocol had undergone audits, these security issues were overlooked.

Reentrancy and similar vulnerabilities should no longer be a threat on the Ethereum blockchain due to the easy availability of defenses against these attacks. To learn more about protecting your smart contract against similar threats, reach out to Halborn.