Superform: A user who cancels a pending redeem has their per-controller accumulatorShares/accumulator

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 63081-cancelled-redeem-requests-make-shares-permanently-unredeemab. The historical source/toolchain is unavailable; this entry is documentation only and claims no executable Forge PoC.

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#

A user who cancels a pending redeem has their per-controller accumulatorShares/accumulatorCostBasis wiped by delete superVaultState[controller], so every subsequent fulfillRedeem reverts INSUFFICIENT_SHARES() and their 100 shares' full asset backing (100e18) is frozen in the strategy forever.

SOLIDITY

        uint256 pendingShares = state.pendingRedeemRequest;
        if (pendingShares == 0) revert REQUEST_NOT_FOUND();
        delete superVaultState[controller]; // @> BUG: wipes accumulatorShares/accumulatorCostBasis, not just the pending request
        emit RedeemRequestCanceled(controller, pendingShares);
    }

Why it's exploitable here#

Attack path#

flowchart TD S0["Per-controller state struct field"] S1["Accumulate shares on deposit"] S2["Request a redeem"] S3["Record pending redeem amount"] S4["Cancel guards zero controller"] H["A user who cancels a pending redeem has their per-controller accumulat"] S0 --> S1 S1 --> S2 S2 --> S3 S3 --> S4 S4 --> H

Marked-line walkthrough (Playground)#

The EVM Playground pins each step to the exact executed source line in 0x671d353a77…:

L90 — Per-controller state struct field: Setup: averageWithdrawPrice is one field of the per-controller state that cancel will wipe.
L111 — Accumulate shares on deposit: Deposit grows accumulatorShares, the cost-basis that backs the controller's future redeem.
L118 — Request a redeem: requestRedeem marks how many shares the controller intends to redeem.
L129 — Record pending redeem amount: Stores the request into pendingRedeemRequest for later fulfillment.
L137 — Cancel guards zero controller: Cancel-redeem rejects a zero controller address before proceeding.
L142 — Cancel wipes all controller state: Root cause: cancel runs delete superVaultState[controller], wiping accumulatorShares/costBasis — all backing, not just the pending request.
L147 — Fulfill now reverts forever: fulfillRedeem reverts INSUFFICIENT_SHARES after cancel, freezing the user's 100 shares' 100e18 backing.

PoC#

Registry (Foundry, local deploy — verbatim vulnerable source + harm-asserting test + negative control):

BASH

cd 63081-cancelled-redeem-requests-make-shares-permanently-unredeemab_exp
forge test -vvv

The browser Playground replays the same synthetic opcode-for-opcode and measures the harm: **A user who cancels a pending redeem has their per-controller accumulatorShares/accumulatorCostBasis wiped by delete superVaultState[control**. Both gates are green (registry forge testPASS + Playground_verify-poc` VERDICT: PASS).

Sources & further analysis#

Reproductions & code

No executable Forge reproduction is claimed; the historical source/toolchain was unavailable for this finding.
AuditVault finding: 63081-cancelled-redeem-requests-make-shares-permanently-unredeemab.
Upstream DeFiHackLabs PoC directory: src/test.

Alerts & third-party analyses

DeFiHackLabs incident explorer: search "Superform: A user who cancels a pending redeem has their per-controller accumulatorShares/accumulator".
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.

Source-level debugger — step opcodes and Solidity in sync