Crypto Trainingblogweb3 security engineering
<- Back to hacks

Reproduced Exploit

Mellow Flexible Vaults — RedeemQueue batch vs claim timestamp mismatch

1. Batch creation excludes the last request at/before the report timestamp (index--). 2. Claim eligibility still allows any request with ts ≤ priceTimestamp. 3. User2 claims from a batch funded only by User1; User1 cannot claim.

Jul 2025•Other•dos•2 min read

Chain

Other

Category

dos

Date

Jul 2025

Source

AuditVault

PoC & write-upPoC for your local evm-hack-analyzerAuditVault PoCs

EVM Playground

Source-level debugger — step opcodes and Solidity in sync

evm-hack-analyzer

The attack is replayed in an in-browser EVM preloaded with the exact dumped fork state. The execution tree shows every call; step by Solidity line or by opcode across all depths — source, Stack, Memory, Storage, Balances (native / ERC-20 / NFT), Transient storage and Return value stay in sync. Click a tree node, opcode, or source line to jump. No backend, no live RPC.

Loading fork state…

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 62107-h-2-redeemqueue-accounting-mismatch-between-batch-creation-a. Standalone Foundry PoC and full write-up: 62107-h-2-redeemqueue-accounting-mismatch-between-batch-creation-a_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/dos/frozen-funds · impact/loss-of-funds/direct-drain · locked-funds

Reproduction: self-contained Foundry PoC with only forge-std. Full trace: output.txt. PoC: test/62107-h-2-redeemqueue-accounting-mismatch-between-batch-creation-a_exp.sol.

AuditVault taxonomy: severity/high · sector/oracle · sector/token · platform/sherlock · frozen-funds · direct-drain

Key info#

ImpactHIGH — ineligible claimer drains batch; honest redeemer locked out
ProtocolMellow Flexible Vaults RedeemQueue
Vulnerable code_handleReport: latestEligibleIndex-- after upperLookupRecent
Bug classOff-by-one timestamp boundary mismatch
FindingSherlock 2025-07-mellow-flexible-vaults · #62107 · H-2
Reportsherlock-audit/2025-07-mellow-flexible-vaults-judging
SourceAuditVault
StatusFixed by protocol (PR #11). Reproduced as standalone local PoC.
Compiler^0.8.24 (PoC)

TL;DR#

  1. Batch creation excludes the last request at/before the report timestamp (index--).
  2. Claim eligibility still allows any request with ts ≤ priceTimestamp.
  3. User2 claims from a batch funded only by User1; User1 cannot claim.

The vulnerable code#

SOLIDITY
latestEligibleIndex = uint256(timestamps.upperLookupRecent(timestamp));
if (latestEligibleIndex == 0) return;
latestEligibleIndex--; // @> VULN
// FIX: remove the decrement

Root cause#

upperLookupRecent already returns the last checkpoint ≤ timestamp. Decrementing excludes that request from the batch while claim still treats it as eligible via the price timestamp.

Attack walkthrough#

  1. Redeems at T, T+100, T+200 (10M shares each).
  2. handleReport(T+150) batches only T (User1).
  3. User2 (T+100) claims and drains the batch assets.
  4. User1 claim reverts — funds locked / stolen.

Diagrams#

sequenceDiagram participant U1 as User1 participant U2 as User2 participant Q as RedeemQueue U1->>Q: redeem at T U2->>Q: redeem at T+100 Q->>Q: handleReport T+150 Note over Q: batch only U1 after index-- U2->>Q: claim T+100 Q-->>U2: full batch assets U1->>Q: claim T Note over U1: reverts empty batch

Impact#

Broken batch accounting permanently strands later-batched shares and lets ineligible claimers take funded assets.

Sources#

Sources & further analysis#

Reproductions & code

Alerts & third-party analyses

  • Web3Sec X hacked database: search.
  • Rekt leaderboard: search.
  • Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.