Meta Pool Hack Analysis

Meta Pool Hack Analysis

Overview:

On June 17, 2025, the Ethereum-based liquid staking protocol Meta Pool (@meta_pool) was exploited through a critical vulnerability in its Staking contract, which inherits from OpenZeppelin’s ERC4626Upgradeable standard. The vulnerability stemmed from the failure to override or restrict the publicly exposed mint() function, which allowed attackers to mint 9701 mpETH without providing any ETH. This vulnerability falls under OWASP SC01: Access Control Vulnerabilities and is indicative of SCWE-016.

The attack impacted multiple chains, including Ethereum, Optimism, and Linea, leading to a combined loss of approximately 56.35 ETH (~$142K) across these networks. The exploit was first front-run by an MEV bot called Yoink, and later reproduced manually by a separate attacker using a flash loan.

Meta Pool’s design enables users to stake ETH/WETH and receive a liquid staking token called mpETH, which is redeemable either instantly (via an internal liquidity pool) or with delay (via validator exits). The Staking.sol contract, built atop ERC4626, manages this staking logic — but a misconfigured function left the system open to free minting.

Smart Contract Hack Overview:

• Victim Contract:
   0x3747484567119592ff6841df399cf679955a111a
• Attack Transactions:
  0x57ee…fa69 (primary mint & swap)
  0x691c…f002
  0x4858…a747
  0x4f43…ef9 (MEV-Bot txn)
• Attacker Address:
   0x48f1d0f5831eb6e544f8cbde777b527b87a1be98
• Stolen funds Parked at: 0x45dd4
• OWASP SC Top 10: SC01: Access Control Vulnerabilities
• OWASP SCWE: SCWE-016.

Decoding the Smart Contract Vulnerability:

• The root cause of the vulnerability that led to Meta Pool exploit lies in the unrestricted exposure of a critical inherited function — mint()—from OpenZeppelin’s ERC4626Upgradeable standard, which was not correctly overridden or access-controlled in the Meta Pool staking contract-Staking.sol .
• As a result, attacker was able to mint a large amount of mpETH tokens without providing any ETH, violating the core economic invariant of the system—that each mpETH token must be backed 1:1 with ETH.

• The mint() function in the ERC4626 standard is designed to allow users to request a specific number of shares (in this case, mpETH) and have the contract calculate how much ETH needs to be deposited. Internally, mint() delegates this logic to _deposit(), which handles asset transfers, pool interactions, and share minting.
• However, in Meta Pool’s implementation, mint() was: Left fully exposed to the public, not marked as payable, and lacked any ETH transfer validation or access restrictions.
• This meant that any user could call mint() without sending ETH, and the contract would still proceed with the _deposit() logic, assuming ETH had been received.

• Inside _deposit(), the process is split into two phases:
  1. Swap ETH for mpETH from the internal liquidUnstakePool via _getmpETHFromPool().
  2. Mint new mpETH shares for any remaining unmet portion.
• Crucially, the swap logic in _getmpETHFromPool() is only triggered if both ETH is received and the pool has available mpETH. Since mint() is not payable, and no ETH is held by the contract at that point, the swap fails or is skipped entirely. The fallback logic kicks in and mints the full amount of shares, despite no ETH being provided.
• Recognizing this oversight, the attacker executed the exploit in two stages:

1. First, they used a flash loan to borrow WETH, converted it to ETH, and called the depositETH() function to drain all mpETH from the internal liquidity pool, ensuring that the _getmpETHFromPool() logic would be bypassed in future calls.

2. Then, they directly called the unrestricted mint() function, which minted thousands of mpETH for free due to the missing ETH validation and the empty pool

• Finally, the attacker swapped part of the minted mpETH for ETH, repaid the flash loan, and kept the rest as profit. The attack succeeded entirely within the bounds of the contract’s logic, due to unsafe reliance on inherited behavior and insufficient validation around economic invariants.

Attack Sequence:

Attacker flash-loaned 200 WETH from Balancer; converted 107 WETH to ETH.

Called depositETH() to drain all mpETH from the liquidUnstakePool.

Invoked mint() to mint ~9702 mpETH without providing any ETH.

Swap logic was skipped; fallback minting executed

Swapped some mpETH to ETH, repaid flash loan, and kept ~56.35 ETH profit.

• Upon identifying the exploit, Meta Pool swiftly disabled the mpETH token’s transfer functionality by upgrading the contract. This prevented further unauthorized movement of the exploited tokens across chains or into liquidity pools. Read more details here: https://x.com/meta_pool/status/1935119387486519582

• Meta Pool maintained open channels with the community through Discord and hosted a Twitter Space on June 17 to directly address user concerns. They committed to continuous updates and scheduled time during Governance Call 19 to ensure DAO members were informed and engaged in shaping the recovery and future safeguards.

Mitigation and Best Practices:

• Always review and override inherited public/external functions (e.g., mint(), redeem()) from standards like ERC4626, ERC20, or upgradeable contracts.
• Ensure that any function that depends on receiving ETH is marked payable and includes explicit value checks (require(msg.value > 0)) before executing asset logic.
• Avoid exposing the raw interfaces of standards like ERC4626 or ERC20 directly to users.
• Instead, expose custom facade functions (e.g., secureMint(), safeStake()) that include additional safety checks, protocol-specific validations, and allow fine-grained control. Also, deactivate or restrict base standard functions that are not meant to be user-facing in the protocol context.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord