Mellow Flexible Vaults — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Mellow Flexible Vaults, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 12
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 12 closed, publicly disclosed Mellow Flexible Vaults 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, 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 Mellow Flexible Vaults
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Mellow Flexible Vaults: ETH redemptions via `SignatureRedeemQueue` are broken due to missing `receive` function
Mellow Flexible Vaults' SignatureRedeemQueue contract cannot complete ETH redemptions because neither it nor its base SignatureQueue implements a receive() or payable fallback function. When a user redeems native ETH, ShareModule.callHook() routes the assets through TransferLibrary.sendAssets(), which performs an empty-data Address.sendValue call to the queue contract; without a payable entry point that call always reverts. As a result, all ETH redemptions through signature queues permanently fail, a full functional break for ETH holders (though their funds are not at risk). The fix — adding a single receive() external payable {} to the shared base contract — was merged in the protocol's PR.
Mellow Flexible Vaults: RedeemQueue Accounting Mismatch Between Batch Creation and Claim Eligibility
The Mellow Flexible Vaults RedeemQueue has an inconsistent timestamp boundary between how batches are created and how claims are validated. When processing an oracle report, _handleReport decrements the latest eligible index (excluding the newest redemption request at or before the report timestamp) when building the batch, while the claim path allows redemption requests up to and including that same timestamp to be claimed from that batch. Consequently, a user whose redemption belongs to a later batch can withdraw assets from an earlier batch that never accounted for their shares, depleting the batch and causing other users' claims to fail or revert with division-by-zero. The affected shares then get baked into a subsequent batch the user can no longer claim from, producing permanent fund lockup. The protocol team fixed the issue in PR mellow-finance/flexible-vaults#11, and the report includes a reproduction test.
Mellow Flexible Vaults: Unable to withdraw native tokens because vault and redeem hooks do not handle native tokens
Mellow Flexible Vaults advertises native ETH as a supported asset token, but the entire redemption path assumes the asset implements ERC20. Both the vault's getLiquidAssets and BasicRedeemHook's getLiquidAssets and callHook query balances with IERC20(asset).balanceOf, which reverts when asset is the native-token sentinel 0xEeee... because that address has no balanceOf implementation. As a result, any withdrawal queued against a native-token asset always fails and deposited funds cannot be recovered. The bug needs no special privileges: depositing native ETH and then withdrawing reproduces it. The protocol team confirmed the issue and merged a fix that queries the native balance when the asset is the native token.
Mellow Flexible Vaults: Malicious Users Can Perpetually Lock `feeRecipient` Shares via Targeted Lockup Reset
Mellow Flexible Vaults mints fee shares to the feeRecipient during deposits, redemptions, and protocol fee collection, but ShareManager.mint applies the configured targetLockup to every recipient, including the feeRecipient. Because the lockedUntil timestamp resets on each mint, a malicious user can repeatedly deposit and redeem minimal amounts to keep re-triggering fee mints, perpetually extending the feeRecipient's lock. This greeds the feeRecipient's shares into a permanent TargetedLockupNotExpired revert, locking away protocol fees in a denial-of-service. The protocol team fixed it by skipping targetLockup application when minting to the feeRecipient.
Mellow Flexible Vaults: cancelDepositRequest() always reverts due to modifying FenwickTree with wrong index
Mellow Flexible Vaults' DepositQueue.cancelDepositRequest() mistakenly uses the latest oracle price checkpoint's index to remove a user's pending deposit from the Fenwick tree that is indexed by deposit timestamps. Because the price-trace array has a different length and indexing basis than the timestamp-based request trace, the derived index is out of bounds and modify() reverts with IndexOutOfBounds on every call. As a result, depositors cannot cancel queued deposits and their funds stay locked until the queue naturally processes them, breaking a core piece of expected behavior without stealing funds. The protocol resolved it by deriving the Fenwick index from the user's request timestamp via lowerLookup() instead of the price checkpoint.
Mellow Flexible Vaults: Flawed Logic in `ShareManager` Inverts Transfer Whitelist Behavior
Mellow Flexible Vaults' `ShareManager.updateChecks` function enforces its transfer-whitelist policy with reversed boolean logic. When the `hasTransferWhitelist` flag is enabled, the check reverts whenever the sender's `canTransfer` flag is true, which is the opposite of the documented contract interface stating that `canTransfer: true` permits an account to send or receive shares. As a result, a vault operator who whitelists accounts finds those accounts blocked from transferring, and only non-whitelisted combinations behave per documentation. A four-case Foundry test confirms the inversion, including a sender-whitelisted case that wrongly reverts and a receiver-whitelisted case that wrongly passes. The finding was adjudicated as a medium-severity logic error, and the protocol fixed it by changing the revert condition to fire only when both the sender and receiver are not whitelisted.
All reports in this group
- Mellow Flexible Vaults: Protocol Fee Multiple Accrual in Oracle.submitReportsLogic error$0
- Mellow Flexible Vaults: Redeems through RedeemQueue avoid paying management and performance fee.Logic error$0
- Mellow Flexible Vaults: Targeted-lockup bypass: freshly minted shares can be transferred immediately in the same `transfer()` or `transferFrom()` callLogic error$0
- Mellow Flexible Vaults: Protocol Fee Exponential Compounding in ShareModule.handleReportLogic error$0
- Mellow Flexible Vaults: Stuck `stETH` rewards in queue contractsLogic error$0
- Mellow Flexible Vaults: DoS in Redemption Due to Unchecked Asset Support in SubvaultsLogic error$0