零時科技 || Equilibria 攻擊事件分析

背景介紹

2025年8⽉23⽇，我們監控到 Ethereum 上針對 Equilibria 的攻擊事件

https://etherscan.io/tx/0x185a16017fb4d9b2fefdf5935435253d53d4758238275426b507fe54eb4fe97a

攻擊共造成約 63k USD 的損失。

攻擊及事件分析

⾸先，攻擊者攻擊者創建了⼀個攻擊合約，轉入 0.1 ETH 後通過 Deposit 獲取了 0.1 WETH 。

然後，攻擊者使⽤了 0.1 WETH 兌換了 7.9 PENDLE ⽤於後續的攻擊。

接着，攻擊者通過 deposit 和 harvest 來將 PENDLE 存入 Equilibria 和獲取收益再投資，⽬的是獲取更多的 ePendle 。

接着，攻擊者⼜利⽤ flashloan 借了 17029 ePendle ，便開始真正的攻擊流程。

在攻擊者真正的攻擊流程中，⾸先通過 depositAll 來存入從 flashloan 借來的 ePendle 和之前使⽤ 0.1 ETH 兌換的 ePendle 獲得了 stake-ePendle 。隨後創建⼀個新的合約，將 stake-ePendle 轉給新合約，利⽤ getReward 獲取獎勵。

我們⾸先看⼀下 depositAll 函數：

function depositAll() external returns (uint256) {

    return deposit(ependle.balanceOf(msg.sender));

}

發現函數其實調⽤了 deposit ，那我們看⼀下 deposit 的具體實現：

function deposit(

    uint256 _amount

)

    public

    nonReentrant

    updateReward(msg.sender, userHarvest)

    returns (uint256)

{

    require(

        _amount > 0,

        "VaultEPendle deposit: amount must be greater than zero"

    );

    uint256 balanceBefore = balance();

    ependle.safeTransferFrom(msg.sender, address(this), _amount);

    uint256 shares = 0;

    if (totalSupply() == 0) {

        shares = _amount

    } else {

        shares = (_amount * totalSupply()) / balanceBefore;

    }

    _mint(msg.sender, shares);

    ePendleRewardPool.stake(_amount);

    emit Deposited(msg.sender, _amount);

    return shares;

}

可以看出，這個 deposit 邏輯比較簡單，通過 modifier 函數 updateReward 在 deposit 時更新⽤戶的 reward ，最後再 stake ，接下來我們看⼀下 updateReward 的具體實現：

modifier updateReward(address _account, bool needHarvest) {

    if (needHarvest) {

        harvest();

    }

    for (uint256 i = 0; i rewardTokens.length; i++) {

        address rewardToken = rewardTokens[i];

        UserReward storage userReward = userRewards[_account][rewardToken];

        userReward.rewards = earned(_account, rewardToken);

        userReward.userRewardPerTokenPaid = rewards[rewardToken]

        .rewardPerTokenStored;

    }

    _;

} 

function earned(

    address _account,

    address _rewardToken

) public view returns (uint256) {

    Reward memory reward = rewards[_rewardToken];

    UserReward memory userReward = userRewards[_account][_rewardToken];

    return

        ((balanceOf(_account) *

            (reward.rewardPerTokenStored -

                userReward.userRewardPerTokenPaid)) / 1e18) +

        userReward.rewards;

}

問題就出現在 earned 函數中，在該函數中，計算⽤戶的 reward 時，參數包含了⽤戶 stake-ePendle 的 balance 。所以，⽤戶可以通過 flashloan 獲取⼤量的 ePendle token 後，通過 stake 獲取 stake-ePendle ，再 transfer 給新的地址來獲取重複的 stake 收益。

攻擊者通過反覆進⾏ transfer stake-ePendle 到新地址，然後再 getReward 獲取收益，最終獲利 63k USD 。

總結

本次漏洞的成因是函數 updateReward 函數在計算 Reward 時， Reward 的值和⽤戶的 stake-ePendle 的 token 餘額有關，且stake-ePendle 可以通過 transfer 到另外⼀個地址。最終，導致攻擊者通過反覆進⾏ transfer stake-ePendle 到新的合約地址再 getReward 獲取獎勵，循環操作提取了項⽬所有資⾦。建議項⽬⽅在設計經濟模型和代碼運⾏邏輯時要多⽅驗證，合約上線前審計時儘量選擇多個審計公司交叉審計。

來源：金色財經