Reproduced Exploit

Parallel 3.1 — processSurplus always reverts for managed collateral

1. Managed collateral lives on an external manager/strategy, never on the diamond. 2. getCollateralSurplus correctly uses manager.totalAssets(). 3. processSurplus self-swaps and transferFroms from the diamond. 4. Diamond balance is 0 → transfer reverts for any positive surplus.

Mar 2026Otheruntagged2 min read

Chain

Other

Category

untagged

Date

Mar 2026

Source

AuditVault

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: 65528-surplusprocesssurplus-always-reverts-for-managed-collateral. Standalone Foundry PoC and full write-up: 65528-surplusprocesssurplus-always-reverts-for-managed-collateral_exp in the evm-hack-registry mirror.


Vulnerability classes: frozen-funds · permanent · dos-resistance

Reproduction: self-contained Foundry PoC with only forge-std. Full trace: output.txt. PoC: test/65528-surplusprocesssurplus-always-reverts-for-managed-collateral_exp.sol.

AuditVault taxonomy: lang/solidity · sector/governance · sector/lending · sector/stable · platform/cyfrin · has/github · has/poc · severity/high · impact/dos/permanent · genome: frozen-funds · permanent · dos-resistance


Key info#

ImpactHIGH — permanent DoS of surplus capture for all managed collateral
ProtocolParallel Parallelizer
Vulnerable codeSurplus.processSurplusSwapper._swap transferFrom diamond
Bug classSurplus measured on manager; pull from diamond (balance always 0)
FindingCyfrin Parallel 3.1 v2.0, 2026-03-04 · #65528 · 0xStalin
ReportCyfrin report
SourceAuditVault
StatusFixed in 2dfad62
Compiler^0.8.24 (PoC)

TL;DR#

  1. Managed collateral lives on an external manager/strategy, never on the diamond.
  2. getCollateralSurplus correctly uses manager.totalAssets().
  3. processSurplus self-swaps and transferFroms from the diamond.
  4. Diamond balance is 0 → transfer reverts for any positive surplus.
  5. HARM: strategy yield can never be captured as distributable tokenP.

The vulnerable code#

SOLIDITY
IERC20(tokenIn).safeTransferFrom(
    msg.sender, // @> VULN: diamond has 0 managed collateral
    LibManager.transferRecipient(...),
    amountIn
);

Fix: LibManager.release surplus to the diamond before the self-swap.


Root cause#

Surplus accounting follows managed total assets, but the swap pull path assumes the diamond holds the tokens — true only for unmanaged collateral.


Preconditions#

  • Collateral configured as managed (isManaged).
  • Strategy has yield so surplus > 0.

Attack walkthrough#

  1. Mint tokenP with managed collateral (tokens go user → manager).
  2. Simulate strategy yield on the manager.
  3. getCollateralSurplus reports positive surplus.
  4. processSurplus reverts on transferFrom(diamond, manager, surplus).

Diagrams#

sequenceDiagram participant G as Governor participant D as Diamond participant M as Manager G->>D: processSurplus D->>M: totalAssets surplus D->>D: swapExactInput self-call D->>M: transferFrom diamond amount Note over D,M: REVERT diamond bal=0

Impact#

Permanent DoS on surplus processing for managed assets — the primary surplus source (strategy yield) is uncapturable.


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.