Crypto Trainingblogweb3 security engineering
<- Back to hacks

Reproduced Exploit

Superform: A 1-wei SuperVault share transfer clones the sender's fulfilled-redeem state (maxWithdraw=

Jan 1970•Other•untagged•3 min read

Chain

Other

Category

untagged

Date

Jan 1970

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: 63075-malicious-actor-can-overwrite-others-user-state-via-1-wei-va. The historical source/toolchain is unavailable; this entry is documentation only and claims no executable Forge PoC.

Vulnerability classes: vuln/theft

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 1-wei SuperVault share transfer clones the sender's fulfilled-redeem state (maxWithdraw=100) onto the recipient via _update, letting the attacker double-withdraw and drain 100 STOLEN-ASSET of another user's escrowed funds to the attacker EOA (escrow drained 200->0; victim's 100 claim left unbacked).

SOLIDITY

// ─────────────────────────────────────────────────────────────────────────────
// VULNERABLE SuperVault: the ERC20 share token. `_update` is VERBATIM from the
// pre-fix audited source — it copies the sender's ENTIRE SuperVaultState onto
// the recipient on every real-user share transfer.
// ─────────────────────────────────────────────────────────────────────────────

Why it's exploitable here#

A 1-wei SuperVault share transfer clones the sender's fulfilled-redeem state (maxWithdraw=100) onto the recipient via _update, letting the attacker double-withdraw and drain 100 STOLEN-ASSET of another user's escrowed funds to the attacker EOA (escrow drained 200->0; victim's 100 claim left unbacked).

Attack path#

flowchart TD S0["SuperVault share token declared"] S1["Strategy holds redeem state"] S2["Wire vault to strategy and escrow"] S3["Transfer override clones redeem state"] S4["Fixed variant initializer"] H["A 1-wei SuperVault share transfer clones the sender's fulfilled-redeem"] 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 0xbd4fd5a3ce…:

  1. L230 — SuperVault share token declared: Setup: SuperVault is an ERC20 share token, so every share transfer is routed through its _update override.
  2. L231 — Strategy holds redeem state: Setup: strategy records each holder's fulfilled-redeem state (like maxWithdraw) that the transfer bug will clone.
  3. L234 — Wire vault to strategy and escrow: Setup: initialize links the vault to its strategy and escrow contracts.
  4. L246 — Transfer override clones redeem state: Every share transfer runs _update, which wrongly copies the sender's fulfilled-redeem state onto the recipient.
  5. L264 — Fixed variant initializer: Setup: the patched variant's initialize, wiring strategy and escrow ahead of the corrected transfer guard.
  6. L269 — Mint shares to a holder: Setup: mintShares issues share tokens to a holder — a mint (from==0) the fix must exclude from state-cloning.
  7. L275 — Fixed guard skips mint/escrow legs: The patched check clones redeem state only for real holder-to-holder transfers, excluding zero-address and escrow legs.

PoC#

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

BASH
cd 63075-malicious-actor-can-overwrite-others-user-state-via-1-wei-va_exp
forge test -vvv

The browser Playground replays the same synthetic opcode-for-opcode and measures the harm: A 1-wei SuperVault share transfer clones the sender's fulfilled-redeem state (maxWithdraw=100) onto the recipient via _update, letting the a. Both gates are green (registry forge test PASS + Playground _verify-poc VERDICT: PASS).

Sources & further analysis#

Reproductions & code

Alerts & third-party analyses

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.