Malda — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Malda, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 13
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 13 closed, publicly disclosed Malda reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Bridge exploit, Integer overflow / underflow, Access control, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Malda
- Bridge exploit findings disclosed against Malda
- Integer overflow / underflow findings disclosed against Malda
- Access control findings disclosed against Malda
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Malda: Migrator severily underestimates slippage by using underlying instead of shares
Malda's migration module enforces a slippage floor when minting collateral mTokens into its v2 markets, but the minimum-output value is computed in underlying token units while the minted output is denominated in shares. Because the market's exchange rate sits near 0.02, the computed bound deviates from the intended share-based protection by roughly one-and-a-half to two orders of magnitude, so the guard can let a migrating user receive far fewer shares than the stated minimum without reverting. The finding was confirmed as a medium-severity Sherlock contest issue and fixed in malda-lending PR 120, which divides the minimum by the exchange rate before passing it to the mint call. The practical consequence is weakened slippage protection during migration, not direct theft.
Malda: Unenforced maxFee and ttl Parameters in sendMsg Function
Malda's EverclearBridge.sendMsg forwards decoded cross-chain intent parameters to everclearFeeAdapter.newIntent without enforcing that maxFee and ttl are both zero, which the Everclear netting pathway requires. A rebalancer (the privileged caller) can therefore create intents with non-zero maxFee/ttl that get misrouted to the solver pathway, which is unsupported at launch. The concrete consequences are potential denial-of-service on cross-chain liquidity rebalancing, unexpected solver fees, and forfeited netting cost savings, rather than direct token theft. Sherlock upheld the issue as medium and the protocol team fixed it in pull request #143 by adding require checks for both fields.
Malda: ```WrapAndSupply::wrapAndSupplyOnExtensionMarket``` preventes users from supplying on host
Malda's WrapAndSupply utility wraps native currency on extension markets by spending the entire msg.value in the deposit/wrap step, so when the mTokenGateway extension has a non-zero configured gasFee there is no value left to pay it and the subsequent supplyOnHost call always reverts with mTokenGateway_NotEnoughGasFee(). The single-transaction flow therefore only works when gasFee equals zero, breaking the protocol's own gas-fee feature for extension markets. Confirmed as a medium-severity denial-of-service and fixed in PR #111 by fetching and subtracting the gas fee from the wrap amount.
Malda: If Across Bridging fails, all funds intended for bridging will become locked
Malda's Rebalancer contract integrates the Across bridging protocol by setting itself as the depositor when calling depositV3Now. Across's documented behavior is to refund expired or unfilled deposits to the depositor back on the origin chain, which in this integration is the Rebalancer itself. Because the Rebalancer has no code path to route those returned tokens back into the lending market, any failed bridging attempt permanently strands the funds. The finding was validated by the Sherlock judge and fixed via a rescue helper in PR #126.
Malda: Rebalancer can steal funds from markets by sending to custom receiver through Everclear Bridge
Malda Lending's cross-chain rebalancer lets funds be stolen through its Everclear bridge integration because the receiver in the bridge intent message is never validated. The EverclearBridge contract forwards an IntentParams struct, including a caller-supplied receiver bytes32, verbatim into everclearFeeAdapter.newIntent(). Since the rebalancer is an EOA whose message content is not checked, a malicious rebalancer can set receiver to an address it controls and divert funds meant for market rebalancing to itself. The issue was confirmed and fixed in malda-lending PR #103, which forces params.receiver to equal the intended _market.
Malda: MixedPriceOracleV4.sol :: getUnderlyingPrice()/getPirce() will not work for some tokens because API3 and EO oracles return prices using different decimals, causing DOS scenario.
Malda's MixedPriceOracleV4 aggregates quotes from two independent feeds — API3, which returns 18-decimal prices, and the EO oracle, which returns 8-decimal prices — to price lending mToken underlyings in USD. Because _absDiff() compares the two raw price values without normalizing their decimal scales, the numeric delta is inflated by roughly ten orders of magnitude and always exceeds the PRICE_DELTA_EXP deviation threshold. The code consequently always selects the EO oracle's price; whenever that EO feed is stale while the healthy API3 feed is fresh, getUnderlyingPrice() reverts with MixedPriceOracle_eOracleStalePrice(), creating a denial of service for price retrieval across affected assets such as the in-scope wBTC/USD pair on Linea. The finding was acknowledged by the protocol team, which applied a fix (PR #134) that normalizes decimals before computing the deviation check.
All reports in this group
- Malda: Blacklist can be completely bypassed on outHere endpoint in mTokenGatewayLogic error$0
- Malda: Wrong direction of rounding in redeem may lead to drain if exchange rate grows largeInteger overflow/underflow$0
- Malda: Rebalancer can send to unallowed destination chains through EverclearBridgeBridge exploit$0
- Malda: There is no endpoint for triggering `liquidateExternal` from extension chain to be executed by proof forwarderLogic error$0
- Malda: First depositor can brick market by forcing very large borrow rateLogic error$0
- Malda: Rebalancer can drain market funds via excessive bridge feesAccess control$0
- Malda: mErc20Host: It is not possible to permissionlessly call "external" endpoints when source chain is Eth mainnet, because l1Inclusion flag cannot be set to trueLogic error$0