VII Finance — fees stolen from partially unwrapped `UniswapV4Wrapper` positions

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 61328-fees-can-be-stolen-from-partially-unwrapped-uniswapv4wrapper. Standalone Foundry PoC and full write-up: 61328-fees-can-be-stolen-from-partially-unwrapped-uniswapv4wrapper_exp in the evm-hack-registry mirror.

Vulnerability classes: fee-theft · frozen-funds · fee-accounting · dos-resistance

Reproduction: a self-contained Foundry PoC that compiles & runs in an isolated project with only forge-std — no fork, no RPC. Full trace: output.txt. PoC: test/61328-fees-can-be-stolen-from-partially-unwrapped-uniswapv4wrapper_exp.sol.

AuditVault taxonomy — lang/solidity · platform/cyfrin · has/poc · severity/high · sector/dex · sector/lending · sector/nft · genome: frozen-funds · fee-theft · fee-accounting · dos-resistance · liquidation-underwater

Key info#


Impact	HIGH — LP fees held for other ERC-6909 holders of a partially unwrapped Uniswap V4 position can be drained by re-wrapping a position whose stale `tokensOwed` was never decremented
Protocol	VII Finance — `UniswapV4Wrapper`
Vulnerable code	`UniswapV4Wrapper::_unwrap` — pays proportional fees from `tokensOwed` but never decrements it
Bug class	Stale fee accounting after partial unwrap / re-wrap
Finding	Cyfrin 2025-07-15 vii-v2.0 · AuditVault #61328 · reporter Giovanni Di Siena
Report	Cyfrin vii-v2.0
Source	AuditVault
Status	Fixed in commit 8c6b6cc
Compiler	`^0.8.24` (PoC)

TL;DR#

Partial unwrap of a V4-wrapped position accumulates fees into tokensOwed and pays a proportional share to the unwrapper.
tokensOwed is never decremented, so the same fee claim can be reused.
After full-via-partial unwrap → recover NFT → re-wrap, the stale claim still points at fee balances that belong to other partially unwrapped holders.
Attacker drains those fees; victims' subsequent unwraps revert (DoS / bad debt path).

The vulnerable code#

SOLIDITY

function _unwrap(address to, uint256 tokenId, uint256 amount, bytes calldata extraData) internal override {
    // ... accumulate fees into tokensOwed, decrease liquidity ...
    poolKey.currency0.transfer(to, amount0 + proportionalShare(tokenId, tokensOwed[tokenId].fees0Owed, amount)); // @> VULN
    poolKey.currency1.transfer(to, amount1 + proportionalShare(tokenId, tokensOwed[tokenId].fees1Owed, amount)); // @> VULN
}

Recommended fix:

DIFF

+       uint256 proportionalFee0 = proportionalShare(tokenId, tokensOwed[tokenId].fees0Owed, amount);
+       uint256 proportionalFee1 = proportionalShare(tokenId, tokensOwed[tokenId].fees1Owed, amount);
+       tokensOwed[tokenId].fees0Owed -= proportionalFee0;
+       tokensOwed[tokenId].fees1Owed -= proportionalFee1;
-       poolKey.currency0.transfer(to, amount0 + proportionalShare(tokenId, tokensOwed[tokenId].fees0Owed, amount));
-       poolKey.currency1.transfer(to, amount1 + proportionalShare(tokenId, tokensOwed[tokenId].fees1Owed, amount));
+       poolKey.currency0.transfer(to, amount0 + proportionalFee0);
+       poolKey.currency1.transfer(to, amount1 + proportionalFee1);

Root cause#

Unlike Uniswap V3 (where tokensOwed lives in the NPM and is reduced by collect), V4 settles fees into the wrapper. The wrapper must track residual fees for multi-holder ERC-6909 positions. Paying from tokensOwed without decrementing leaves a reusable claim that outlives the position's fee balance.

Preconditions#

At least one position is partially unwrapped (fees sit in the wrapper).
Attacker can fully unwrap (via partial overload), recover, and re-wrap a position.
Stale tokensOwed for the attacker's tokenId is non-zero from a prior cycle.

Attack walkthrough#

Victim wraps position V; attacker wraps position A; both accrue 100 fees.
Victim partial-unwraps 10% → receives 10 fees; tokensOwed[V] still 100.
Attacker full-via-partial unwraps A (takes own 100 fees); tokensOwed[A] still 100.
Recover + re-wrap A (no new fees); stale tokensOwed[A] = 100 survives.
Partial unwrap 90% of re-wrapped A pays 90 of stale claim from wrapper balance that still holds the victim's residual fees → 90 fee units stolen.
Wrapper is short for the victim's remaining fee claim.

Diagrams#

sequenceDiagram participant V as Victim participant W as UniswapV4Wrapper participant A as Attacker V->>W: partial unwrap 10% Note over W: pays 10 fees#59; tokensOwed still 100 A->>W: full via partial unwrap Note over W: tokensOwed[A] still 100 stale A->>W: recover + rewrap A A->>W: partial unwrap 90% Note over W: pays 90 from victim residual fees Note over V,W: victim fee claim underfunded

Impact#

ERC-6909 holders of partially unwrapped positions lose accrued LP fees. Full unwrap for remaining holders can revert, blocking liquidators from recovering collateral and allowing bad debt to accrue (see also #61327).

Sources#

AuditVault finding #61328
Cyfrin 2025-07-15 vii-v2.0 report
Vulnerable source: kankodu/vii-finance-smart-contracts — UniswapV4Wrapper::_unwrap (fixed in 8c6b6cc)

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 61328-fees-can-be-stolen-from-partially-unwrapped-uniswapv4wrapper_exp (evm-hack-registry mirror).
AuditVault finding: 61328-fees-can-be-stolen-from-partially-unwrapped-uniswapv4wrapper.

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.

Source-level debugger — step opcodes and Solidity in sync