Silo Finance Exploit — Untrusted Swap/Silo Targets in `openLeveragePosition` Let Attacker Re-route a "Swap" into `Silo.borrow`

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2025-06-SiloFinance_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/SiloFinance_exp.sol.

Vulnerability classes: vuln/input-validation/missing · vuln/dependency/unsafe-external-call · vuln/access-control/missing-auth

Reproduction: this PoC compiles and runs in an isolated Foundry project at this project folder. It forks mainnet state at block 22_781_961 from a local anvil node (http://127.0.0.1:8545, state served from anvil_state.json, createSelectFork → 127.0.0.1); no public RPC is used at run time. The full verbose Foundry trace is in output.txt. No verified contract source is bundled under sources/ (the directory is empty), so the Solidity snippets in §"The vulnerable code" are reconstructed from observed on-chain behaviour (the trace's call ordering, calldata, and storage diffs) and are anchored with [output.txt:NNNN] line references rather than sources/...#L file links.

Key info#

TL;DR#

1. Silo Finance ships a public openLeveragePosition helper (the "Silo leverage helper", 0xCbEe4617…829DF9) that takes three user-supplied argument blobs: a FlashArgs (flashloanTarget, amount), an opaque swapArgs, and a DepositArgs (silo, amount, collateralType). The helper is designed to flash-borrow from a Silo, run a swap via an "exchange proxy", deposit the proceeds as collateral, and finally borrow on behalf of the caller.
2. The helper trusts every one of those addresses verbatim. It never checks that flashloanTarget is a registered Silo of the market, that exchangeProxy is an allow-listed DEX router, or that depositArgs.silo is the same market the user deposited into. It also re-decodes swapArgs and depositArgs from inside the flash-loan callback, so the attacker can rewrite them mid-flight.
3. The attacker deploys a single contract (SiloFinanceAttack) that impersonates the flash lender, the collateral Silo, the collateral token, and the swap exchange at the same time. flashLoan, asset, config, getSilos, balanceOf, allowance, approve, transferFrom, deposit, and borrow are all stubs on the attacker contract.
4. openLeveragePosition is called with flashArgs.flashloanTarget = <attacker> and amount = 0. The helper then calls flashLoan(receiver=helper, …) on the attacker output.txt:1609. Inside that callback the attacker re-supplies a SwapArgs whose exchangeProxy is the real WETH Silo and whose swapCallData is abi.encodeWithSelector(ISilo.borrow.selector, 224 ether, attacker, collateralBorrower) [output.txt:1610].
5. Because the helper then re-enters its own onFlashLoan with this attacker-chosen payload, it ends up calling WETH_Silo.borrow(224 ether, attacker, collateralBorrower) — i.e. it borrows 224 WETH from the real WETH Silo against the collateral borrower's position, and sends the WETH to the attacker output.txt:1613.
6. The WETH Silo honours the borrow because the helper holds a prior receiveApproval/borrow allowance from the collateral borrower (0x60BA…4860); the trace shows ShareDebtToken.mint(collateralBorrower, helper, 223_975_555_653_555_068_856) output.txt:1665 and WETH.transfer(attacker, 224 ether) output.txt:1675.
7. After the real borrow the helper continues its "happy path": it calls the attacker's fake deposit(1, …) and fake borrow(0, …) output.txt:1741 output.txt:1745, emits OpenLeverage(borrowerDeposit: 0, swapAmountOut: 1, totalDeposit: 1, totalBorrow: 0, …) output.txt:1749, and returns the ERC-3156 magic value — so its post-conditions pass.
8. Net result: the attacker's EOA balance grows from 0 WETH to 224 WETH (224_000_000_000_000_000_000 wei) output.txt:1757 output.txt:1768, exactly matching the PoC's assertEq; debtShares == 223_975_555_653_555_068_856 output.txt:1760. The collateral borrower is left owing the new debt.

Background — what Silo Finance does#

Silo Finance is an isolated-market money market. Each "market" is a pair of two silos: a collateral silo that holds the protected+collateral share token of one asset (here weWEETH, 0xCd5fE23C…59b7ee) and a borrow silo that holds the liquidity of the paired asset (here WETH, 0xC02aaA39…756Cc2). A SiloConfig links the two silos of a market and exposes getConfigsForBorrow output.txt:1659.

Silo.borrow(assets, receiver, borrower) lets an address that has been granted a borrow allowance draw liquidity from a borrow silo against collateral posted in the linked collateral silo, minting ShareDebtToken debt shares to borrower and transferring the underlying to receiver. The on-chain config for the weWEETH/WETH market (read in the trace) is:

The leverage helper is a convenience wrapper: it lets a borrower supply some collateral, swap the borrowed asset back into the collateral asset, deposit that, and re-borrow — all atomically. Its design flaw is that none of the addresses driving those steps are validated against the borrower's actual market.

The vulnerable code#

All snippets below are RECONSTRUCTED — matches observed on-chain behaviour, not verified source. They are reconstructed from the call ordering, calldata, and storage changes recorded in output.txt and are anchored to specific trace lines. No sources/...#L references are fabricated.

1. openLeveragePosition trusts attacker-controlled FlashArgs, swapArgs, and DepositArgs#

The PoC interface (ILeverageHelper1356) reconstructs the helper's entry signature from observed calldata output.txt:1604:

// RECONSTRUCTED — matches observed on-chain behaviour, not verified source
interface ILeverageHelper1356 {
    struct FlashArgs   { address flashloanTarget; uint256 amount; }          // [output.txt:1604]
    struct DepositArgs { address silo; uint256 amount; uint8 collateralType; } // [output.txt:1604]

    function openLeveragePosition(
        FlashArgs   calldata flashArgs,
        bytes       calldata swapArgs,        // opaque blob; re-decoded inside the flash callback
        DepositArgs calldata depositArgs
    ) external payable;
}

flashArgs.flashloanTarget is called as the ERC-3156 flash lender; swapArgs is decoded inside the callback into SwapArgs{exchangeProxy, sellToken, buyToken, allowanceTarget, swapCallData}; depositArgs.silo is called as the destination Silo. None of these addresses is checked against the market the caller actually has collateral in — they are simply used.

2. The helper calls flashLoan on the attacker, then re-decodes swap data inside its own onFlashLoan#

The trace shows the helper calling flashLoan(helper, attacker, 0, …) on whatever address the user supplied output.txt:1609, and then — inside the attacker-controlled flashLoan body — the attacker calls back onFlashLoan on the helper with a freshly forged (swapArgs, depositArgs) payload output.txt:1610. The reconstructed helper behaviour is:

// RECONSTRUCTED — matches observed on-chain behaviour, not verified source
function openLeveragePosition(FlashArgs calldata f, bytes calldata swapArgs, DepositArgs calldata d) external payable {
    // f.flashloanTarget is taken verbatim — no SiloConfig / market check
    IERC3156FlashLender(f.flashloanTarget).flashLoan(
        IERC3156FlashBorrower(address(this)), // receiver == helper itself
        f.flashloanTarget,                     // "token"
        f.amount,
        abi.encode(swapArgs, d)
    );
    // …after the flash: deposit + "borrow" against d.silo, again attacker-controlled (see §3)
}

// The helper IS the ERC-3156 receiver; it re-decodes swapArgs here:
function onFlashLoan(address initiator, address token, uint256 amount, uint256 fee, bytes calldata data)
    external returns (bytes32)
{
    (bytes memory swapArgsEncoded, DepositArgs memory d) = abi.decode(data, (bytes, DepositArgs));
    SwapArgs memory s = abi.decode(swapArgsEncoded, (SwapArgs));
    // s.exchangeProxy is taken verbatim — no DEX allow-list
    (bool ok) = IExchangeProxy(s.exchangeProxy).swap(  // <-- routed into WETH Silo::borrow at [output.txt:1613]
        s.sellToken, s.buyToken, s.allowanceTarget, s.swapCallData
    );
    require(ok);
    return keccak256("ERC3156FlashBorrower.onFlashLoan"); // [output.txt:1752]
}

Because swapArgs is decoded inside the callback, the attacker's flashLoan can supply a different swapArgs than the outer caller did. In the PoC the outer swapArgs is empty (0x, output.txt:1604); the dangerous payload is injected only inside the callback output.txt:1610.

3. The "swap" exchangeProxy is the WETH Silo and swapCallData is Silo.borrow#

The attacker's forged SwapArgs points the helper's "swap" at the real WETH Silo and packs Silo.borrow selector + args into swapCallData:

// From the PoC (test/SiloFinance_exp.sol:134-142) — the forged swap descriptor
SwapArgs memory swapArgs = SwapArgs({
    exchangeProxy:    WETH_SILO,                                  // 0x1602…4085
    sellToken:        address(this),                              // attacker
    buyToken:         address(this),                              // attacker
    allowanceTarget:  address(this),                              // attacker
    swapCallData:     abi.encodeWithSelector(
        ISilo1356.borrow.selector,
        BORROW_AMOUNT,           // 224 ether                      // [output.txt:1613]
        profitReceiver,          // attacker EOA = `receiver`       // [output.txt:1613]
        COLLATERAL_BORROWER      // 0x60BA…4860 = `borrower`        // [output.txt:1613]
    )
});

The trace confirms this verbatim: WETH Silo::borrow(224000000000000000000, Attacker: […fd62], Collateral borrower: […4860]) output.txt:1613, entered via Silo::borrow delegatecall output.txt:1614 and Actions::5937128b(…) output.txt:1615.

4. The post-flash "deposit + borrow" is routed at the attacker's fake Silo#

After the real borrow returns, the helper continues its flow and calls deposit and borrow on depositArgs.silo — which the attacker also set to address(this). The attacker's stubs only accept the exact (assets=1, receiver=attack, collateralType=1) and (assets=0, receiver=helper, borrower=attack) shapes output.txt:1741 output.txt:1745:

// From the PoC (test/SiloFinance_exp.sol:190-199) — attacker's fake Silo/token surface
function deposit(uint256 assets, address receiver, uint8 collateralType)
    external pure returns (uint256 shares) {
    require(assets == 1 && receiver != address(0) && collateralType == 1, "unexpected fake deposit");
    return 0;                                                              // [output.txt:1742]
}
function borrow(uint256 assets, address receiver, address borrower)
    external returns (uint256 shares) {
    require(assets == 0 && receiver == SILO_LEVERAGE_HELPER && borrower == address(this), "unexpected fake borrow");
    debtShares = HISTORICAL_DEBT_SHARES;                                   // [output.txt:1748]
    return 0;
}

So the helper's own accounting (OpenLeverage(borrowerDeposit: 0, swapAmountOut: 1, totalDeposit: 1, totalBorrow: 0) output.txt:1749) looks healthy and the function returns the ERC-3156 success magic value output.txt:1752. The damage was already done in §3.

Root cause — why it was possible#

The root cause is lack of destination-binding for user-supplied addresses. openLeveragePosition accepts three address-bearing blobs (FlashArgs.flashloanTarget, SwapArgs.exchangeProxy/sellToken/buyToken/allowanceTarget, DepositArgs.silo) and uses each of them as a trusted counterparty (flash lender, DEX, Silo) without any of these checks:

• No allow-list / no market binding. flashloanTarget, exchangeProxy, and depositArgs.silo should all be constrained to addresses derived from the borrower's own SiloConfig (the same market the collateral sits in). They are not. The PoC sets all three to an attacker contract and additionally points exchangeProxy at an unrelated real Silo.
• No re-entrancy guard on the swap payload. swapArgs is re-decoded inside the flash callback (onFlashLoan), so a malicious flash lender can substitute a completely different swap descriptor mid-flight. The outer caller cannot pin it.
• Treating opaque calldata as an external call. exchangeProxy.swap(swapCallData) is a generic caller → arbitrary address → arbitrary calldata primitive. With exchangeProxy = WETH Silo and swapCallData = borrow.selector…, the helper is turned into a borrow oracle.
• Borrower-side allowance was over-broad. The collateral borrower (0x60BA…4860) had granted the leverage helper a borrow allowance. Combined with the above, any caller could direct that allowance at WETH_Silo.borrow and choose the receiver. The trace shows ShareDebtToken.mint(collateralBorrower, helper, 223_975_555_653_555_068_856) output.txt:1665 — i.e. debt is booked to the collateral borrower while WETH goes to the attacker output.txt:1675.

It is not a re-entrancy bug in Silo.borrow itself (Silo does toggle reentrancy protection, output.txt:1622 / output.txt:1723); it is a misuse-of-trust bug in front of Silo, where the helper hands an attacker the pen.

Preconditions#

1. A leverage helper with the openLeveragePosition(FlashArgs, bytes swapArgs, DepositArgs) signature is publicly callable (no allow-listing of callers). ✅ in the PoC (Silo leverage helper).
2. At least one borrower has granted the helper a borrow allowance against a real Silo. ✅ — the collateral borrower 0x60BA…4860 is the borrower argument and the mint succeeds output.txt:1665.
3. That borrower has sufficient collateral to remain solvent at the chosen borrow size. ✅ — ~1386.18 weWEETH of protected collateral output.txt:1687 at oracle price 1.07039651 output.txt:1713 vs. 224 WETH borrowed, well inside the 85% maxLtv on the WETH silo output.txt:1660.
4. The helper does not validate flashloanTarget / exchangeProxy / depositArgs.silo against the borrower's market. ✅ — see §"The vulnerable code".
5. swapArgs is (re-)decoded inside the flash callback, so the flash lender controls it. ✅ — output.txt:1610.

Attack walkthrough (with on-chain numbers from the trace)#

Pool / silo state evolution (this tx):

Profit / loss accounting (WETH, raw wei)#

The 224 WETH profit is exactly the PoC's first assertion: assertEq(IERC20(WETH).balanceOf(ATTACKER) - attackerWethBefore, BORROW_AMOUNT) with BORROW_AMOUNT = 224 ether output.txt:1758. The corresponding debt (223_975_555_653_555_068_856 shares) is left on the collateral borrower's books, not the attacker's — that is what makes this theft rather than a loan.

Diagrams#

Sequence of the attack#

Pool / silo state evolution#

The flaw inside openLeveragePosition / onFlashLoan#

Why the drain is theft: who pays#

This is not an AMM constant-product bug, so instead of a k invariant diagram the relevant "before vs. after" is the balance sheet shift between the attacker and the collateral borrower:

Why each magic number#

Remediation#

1. Bind every address to the borrower's market. Derive flashloanTarget, exchangeProxy, and depositArgs.silo from the SiloConfig of the borrower's actual collateral silo (or from a protocol-owned registry) — never from calldata. Reject any user-supplied address that is not a registered silo / approved flash lender / allow-listed DEX router for that market.
2. Pin swapArgs before the flash and do not re-decode it inside onFlashLoan. Encode the swap descriptor in openLeveragePosition before calling flashLoan, pass it through as an immutable blob, and have onFlashLoan consume exactly that blob (hash-commit if needed). A flash lender must not be able to substitute the swap.
3. Constrain the "exchange proxy" call. Either route swaps through a fixed, audited router (e.g. a curated 0x Settler / Uniswap router) or, at minimum, validate swapCallData's selector against an allow-list of swap selectors before the external call. Silo.borrow (and any non-swap selector) must never be reachable through exchangeProxy.
4. Scope the borrow allowance. The helper should hold narrowly-scoped, per-market, per-action allowances from borrowers (e.g. EIP-3009-style receiveApproval with a destination and amount cap), so that even a fully-malicious helper cannot redirect borrows to an arbitrary receiver. The collateral borrower must never be on the hook for a borrow whose receiver they did not authorise.
5. Add a re-entrancy / call-target assertion on the helper. After the flash returns, assert that the only state changes are: collateral increased in depositArgs.silo, debt increased in the linked borrow silo, and the borrower's balance of the borrowed asset increased — nothing else. Reject if WETH left the borrow silo to any address other than the helper.
6. Revoke and re-issue the helper's allowances with the patched contract, and have existing borrowers re-grant only the scoped allowance described in (4). Until (1)-(3) ship, treat openLeveragePosition as a privileged, allow-listed call, not a public one.

How to reproduce#

# from the registry root
_shared/run_poc.sh 2025-06-SiloFinance_exp --mt testExploit -vvvvv

The script spins up a local anvil --load-state anvil_state.json on 127.0.0.1:8545 (no public RPC), then runs:

forge test --match-test testExploit -vvvvv

inside 2025-06-SiloFinance_exp/. Expected tail of output.txt (verbatim):

  Attacker Before exploit WETH Balance: 0.000000000000000000
  Attacker After exploit WETH Balance: 224.000000000000000000
…
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 11.87ms (6.67ms CPU time)

Ran 1 test suite in 4.54s (11.87ms CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)

Compiler: Solc 0.8.34, evm_version = cancun (from foundry.toml and output.txt:1). The fork pins block.number = 22_781_961 and block.timestamp = 0x685c038b (output.txt:1569 output.txt:1573) so the reproduced debt shares exactly equal HISTORICAL_DEBT_SHARES.

Reference: https://t.me/defimon_alerts/1356

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2025-06-SiloFinance_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: SiloFinance_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "Silo Finance Exploit".
• 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.