Reproduced Exploit
Accountable: An async-pending cancel leaves its redeem request queued with shares intact while pendingC
Chain
Other
Category
untagged
Date
Jan 1970
Source
AuditVault
EVM Playground
Source-level debugger — step opcodes and Solidity in sync
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.
Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 62970-critical-dos-in-queue-processing-if-async-cancellations-are. Standalone Foundry PoC and full write-up: 62970-critical-dos-in-queue-processing-if-async-cancellations-are_exp in the
evm-hack-registrymirror.
Vulnerability classes: vuln/locked-funds
Reproduction: a faithful minimal reproduction of the vulnerable finding — the vulnerable function is reproduced verbatim (marked
@>) with faithful minimal doubles; local deploy, no fork.
Root cause#
An async-pending cancel leaves its redeem request queued with shares intact while pendingCancelRedeemRequest=true, so processUpToShares() permanently reverts on the _fulfillRedeemRequest cancel guard and every queued share (150 shares here: A's 50 stuck at the head + B's 100 behind it) is frozen and unclaimable.
if (state.pendingRedeemRequest == 0) revert NoPendingRedeemRequest();
if (state.pendingCancelRedeemRequest) revert CancelRedeemRequestPending();
state.pendingCancelRedeemRequest = true;
bool canCancel = strategy.onCancelRedeemRequest(address(this), controller); // @> async strategy returns false: flag set true but the queued shares are left UN-REDUCED
Why it's exploitable here#
An async-pending cancel leaves its redeem request queued with shares intact while pendingCancelRedeemRequest=true, so processUpToShares() permanently reverts on the _fulfillRedeemRequest cancel guard and every queued share (150 shares here: A's 50 stuck at the head + B's 100 behind it) is frozen and unclaimable.
Attack path#
Marked-line walkthrough (Playground)#
The EVM Playground pins each step to the exact executed source line in 0x671d353a77…:
- L105 — Per-controller vault state map: Setup: maps each controller to its
VaultStateholding redeem and cancel flags. - L127 — Read pending-cancel flag: Returns whether a controller has an async cancel pending — the flag that later blocks queue processing.
- L146 — Cancel a queued redeem:
cancelRedeemRequestmarks a controller's queued redeem for async cancellation. - L152 — Flag set, request left queued: Root cause: sets
pendingCancelRedeemRequest=truebut leaves the request in the FIFO with shares intact, so processing later trips its own cancel guard. - L167 — Fulfill reverts on cancel guard:
_fulfillRedeemRequestreverts when it hits a request flagged pending-cancel — the guard that permanently jamsprocessUpToShares. - L191 — Read next queued request:
_processRequestpulls the head request's controller, shares, and price as the queue is walked. - L228 — Vault-state struct definition: Setup: declares the
VaultStatestruct, including the pending-cancel flag.
PoC#
Registry (Foundry, local deploy — verbatim vulnerable source + harm-asserting test + negative control):
cd 62970-critical-dos-in-queue-processing-if-async-cancellations-are_exp
forge test -vvv
The browser Playground replays the same synthetic opcode-for-opcode and measures the harm: An async-pending cancel leaves its redeem request queued with shares intact while pendingCancelRedeemRequest=true, so processUpToShares() pe. Both gates are green (registry forge test PASS + Playground _verify-poc VERDICT: PASS).
Sources & further analysis#
Reproductions & code
- Standalone PoC + full trace: 62970-critical-dos-in-queue-processing-if-async-cancellations-are_exp (evm-hack-registry mirror).
- AuditVault finding: 62970-critical-dos-in-queue-processing-if-async-cancellations-are.
- Upstream DeFiHackLabs PoC directory: src/test.
Alerts & third-party analyses
- DeFiHackLabs incident explorer: search "Accountable: An async-pending cancel leaves its redeem request queued with shares intact while pendingC".
- 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.