MERC20Host.sol Vulnerability: Asset Drain & Mitigation

Aug 14, 2025 by Sebastian Müller 55 views

Decent Lemon Poodle: Mitigating Unbounded Asset Drain in mERC20Host.sol

Hey guys! Today, we're diving deep into a critical vulnerability discovered in the mERC20Host.sol smart contract. This is a serious issue that could potentially lead to a significant loss of funds, so let's break it down in a way that's super easy to understand.

Introduction

In the world of DeFi (Decentralized Finance), security is paramount. Smart contracts, the backbone of these systems, need to be rock-solid to protect user funds. Recently, a vulnerability was found in the extractForRebalancing() function within the mERC20Host.sol contract. This issue, dubbed "Decent Lemon Poodle" (yeah, the names can be quirky!), could allow a malicious actor to drain the entire liquidity pool. Let’s explore what went wrong and how we can fix it.

Understanding the Vulnerability

The heart of the problem lies in the extractForRebalancing() function. This function is intended to allow a designated REBALANCER_ROLE to withdraw ERC20 tokens to optimize liquidity across different chains. Think of it like this: sometimes, one chain might have too much of a particular token, while another has too little. The rebalancer's job is to even things out, ensuring smooth operations.

However, the extractForRebalancing() function has a critical flaw: it lacks any upper bounds or safety checks on the amount that can be withdrawn. This means that the rebalancer, if compromised or malicious, could withdraw all the ERC20 tokens held by the contract. Imagine emptying a bank account with no withdrawal limits – scary, right?

The function directly transfers the specified amount from the mERC20Host's balance to the caller (the rebalancer). There’s no sanity check to ensure the withdrawal is within reasonable limits, nor any mechanism to prevent a complete drain of funds. This is a direct violation of the protocol’s security model, which explicitly states that the rebalancer should not be able to transfer user funds.

The absence of these safeguards introduces a global solvency risk. A malicious rebalancer could irreversibly drain funds, making user deposits illiquid or even worthless. This vulnerability is rated as Medium severity because it directly contradicts the protocol's trust model and puts core assets at significant risk.

The Technical Details

Let's dive into the specific function that's causing the trouble:

// Affected function:
// https://github.com/sherlock-audit/2025-07-malda/blob/main/malda-lending/src/mToken/host/mErc20Host.sol#L139
function extractForRebalancing(uint256 amount) external onlyRole(REBALANCER_ROLE) {
    IERC20(_underlying).safeTransfer(msg.sender, amount);
}

See that safeTransfer call? It looks innocent enough, but because there are no checks on the amount parameter, it can be exploited to transfer the entire balance of the underlying ERC20 token from the mERC20Host contract. This is a big deal.

Impact: The Ripple Effect

The implications of this vulnerability are severe. An attacker with the REBALANCER_ROLE could call extractForRebalancing() and specify an arbitrary amount, effectively draining the contract's funds. This unbounded outflow of assets puts the entire protocol at risk.

While the rebalancer is considered a semi-trusted role, meaning they're not supposed to directly manipulate user balances, this vulnerability creates a global solvency risk. By draining the protocol’s treasury, the rebalancer can undermine user trust and the guarantee of liquidity. Imagine depositing funds into a platform only to find out that a rogue rebalancer has emptied the coffers – not a great experience, right?

This vulnerability isn't just a theoretical concern; it has the potential to cause real financial harm to users of the protocol. It's crucial to address this issue to maintain the integrity and trustworthiness of the system.

Proof of Concept: Seeing It in Action

To demonstrate the vulnerability, let's look at a Proof of Concept (PoC) written in Solidity. This PoC simulates how an attacker could exploit the extractForRebalancing() function.

function test_RebalancerCanDrainFundsUsing_extractForRebalancing() public {
    uint256 amount = 1_000 ether; // Let's try draining 1,000 tokens

    // Assign REBALANCER role to this contract (simulating malicious rebalancer)
    roles.allowFor(address(this), roles.REBALANCER(), true);

    // Pre-fund the mWethHost with WETH tokens
    deal(address(weth), address(mWethHost), amount);

    // Call the vulnerable function
    mWethHost.extractForRebalancing(amount);

    // Assert that funds were drained to the rebalancer
    assertEq(weth.balanceOf(address(this)), amount);
    assertEq(weth.balanceOf(address(mWethHost)), 0);
}

In this PoC:

We set an amount to withdraw (1,000 tokens in this case).
We assign the REBALANCER_ROLE to the testing contract, simulating a malicious rebalancer.
We pre-fund the mWethHost contract with WETH tokens.
We call the vulnerable extractForRebalancing() function.
Finally, we assert that the tokens were successfully drained to the rebalancer's address and that the mWethHost's balance is now zero.

This PoC clearly shows how easy it is for a malicious rebalancer to drain funds using the current implementation of extractForRebalancing(). This is why it's so critical to implement proper safeguards.

Recommended Mitigation: How to Fix It

Okay, so we've identified the problem. Now, how do we fix it? Here are several recommended mitigation strategies to prevent the unbounded asset drain:

1. Cap the Amount Withdrawable

The simplest and most effective solution is to cap the amount that can be withdrawn per epoch or block. This limits the potential damage from a malicious rebalancer and provides a predictable outflow of funds. Imagine setting a daily withdrawal limit on your bank account – it prevents someone from cleaning you out in one go.

2. Add Safety Checks

Implementing safety checks can add an extra layer of protection. These checks could include:

Minimum vault liquidity threshold: Ensure that the withdrawal doesn't drop the vault's liquidity below a certain level. This prevents the contract from becoming insolvent.
Maximum percentage outflow: Limit the withdrawal to a maximum percentage of the vault's total assets. This ensures that a large withdrawal doesn't destabilize the system.

3. Introduce Timelocks or Multi-Sig Approval

For large withdrawals, consider implementing timelocks or requiring multi-signature approval. Timelocks delay the withdrawal, giving the community time to react if a suspicious transaction is initiated. Multi-sig approval requires multiple parties to authorize the withdrawal, making it much harder for a single malicious actor to drain funds.

4. Log Usage with Clear On-Chain Audibility

Finally, it's crucial to log all usage of the extractForRebalancing() function with clear on-chain audibility. This provides a transparent record of all withdrawals, making it easier to detect and investigate suspicious activity. Think of it as having a detailed transaction history for the function.

Detailed Look at Mitigation Strategies

Let's dive a bit deeper into each of these mitigation strategies to fully understand how they can protect the protocol.

Capping Withdrawals: A Financial Firewall

Capping the amount withdrawable is like setting up a financial firewall. By limiting the outflow of funds, you contain potential damage. This strategy involves modifying the extractForRebalancing() function to include a check on the withdrawal amount.

For example, you could introduce a maxWithdrawalAmount variable that limits the amount that can be withdrawn in a single transaction or within a specific time frame (e.g., per epoch or block). The function would then check if the requested amount exceeds this limit and revert the transaction if it does.

This approach adds a crucial safety net. Even if a malicious actor gains access to the rebalancer role, they won't be able to drain all the funds at once. Instead, they'll be limited to the maximum withdrawal amount, giving the protocol and community time to respond.

Safety Checks: Guarding the Vault

Adding safety checks is akin to installing a security system in a vault. These checks help ensure that withdrawals don't jeopardize the overall health and solvency of the protocol.

Minimum Vault Liquidity Threshold

Implementing a minimum liquidity threshold is like setting a reserve balance. It ensures that the vault always has a certain amount of assets available. This is crucial for maintaining the protocol's ability to meet its obligations and handle normal operations.

To implement this, you would check the vault's balance before the withdrawal and ensure that it remains above the specified threshold after the transaction. If the withdrawal would drop the balance below the threshold, the transaction is reverted.

Maximum Percentage Outflow

Limiting the maximum percentage outflow is like setting a withdrawal limit based on the total balance. It prevents large withdrawals that could destabilize the system. This is particularly important for protocols that rely on liquidity pools or other shared resources.

This check involves calculating the percentage of the total assets that the withdrawal represents. If this percentage exceeds a predefined limit (e.g., 10% of the total assets), the transaction is reverted.

Timelocks and Multi-Sig: Collaborative Security

Introducing timelocks and multi-signature approval mechanisms is like adding a multi-layered security protocol. These measures ensure that significant actions, such as large withdrawals, require additional scrutiny and authorization.

Timelocks

A timelock is a mechanism that delays the execution of a transaction for a specified period. This gives the community or other stakeholders time to review the transaction and intervene if necessary. Think of it as a cooling-off period for important decisions.

Multi-Signature Approval

Multi-signature (multi-sig) approval requires multiple parties to authorize a transaction before it can be executed. This reduces the risk of a single point of failure and makes it much harder for a malicious actor to drain funds. It's like requiring multiple keys to open a vault.

Logging and Auditing: Transparency and Accountability

Implementing clear on-chain logging and auditing mechanisms is like having a security camera and audit trail for all financial transactions. This provides transparency and accountability, making it easier to detect and investigate suspicious activity.

By logging all usage of the extractForRebalancing() function, including the amount withdrawn, the timestamp, and the address initiating the transaction, you create a detailed record that can be used for analysis and auditing. This can help identify patterns of misuse or unauthorized activity.

Conclusion: Securing the Future of DeFi

The "Decent Lemon Poodle" vulnerability highlights the importance of robust security practices in smart contract development. The extractForRebalancing() function in mERC20Host.sol lacked crucial safeguards, potentially allowing a malicious rebalancer to drain the entire liquidity pool.

By understanding the vulnerability, its impact, and the recommended mitigation strategies, we can work together to build more secure and trustworthy DeFi protocols. Capping withdrawals, adding safety checks, introducing timelocks or multi-sig approval, and logging usage are all vital steps in safeguarding user funds.

Let’s continue to prioritize security and collaboration to ensure the long-term success and reliability of decentralized finance. Stay safe out there, and keep those smart contracts lemon-fresh (but secure!).