Kamoulox

Earlier today, ~392k USDC from @SiloFinance's managed soUSDC vault on Arbitrum was forcibly allocated into the wstUSR/USDC market, leaving bad debt. wstUSR was trading at ~$0.12 onchain, but the Silo market's oracle priced it at 1 wstUSR = 1.1329 USDC. Anyone who bought wstUSR cheaply could use it as collateral worth ~10x its real value. The exploiter called deposit() on the wstUSR market directly, donating the shares to soUSDC. The supply cap controlling how much soUSDC can actively allocate to this market was 0, but that cap only governs the vault's own outbound deposits. It does nothing to stop external parties from crediting positions to the vault. Once those shares landed in soUSDC's balance, totalAssets() counted them. It iterates every market in the withdrawal queue and reads the vault's actual share balance in each one, with no check on whether the position was voluntarily entered. Combined with the oracle gap, each attack loop worked like this: 1. Flash-loan USDC. 2. Deposit the bulk of USDC to soUSDC, which routes it to an existing market and mints soUSDC shares to the attacker. 3. Deposit a small amount of USDC to the wstUSR market directly, donate the shares to soUSDC. 4. Borrow that USDC back using cheap wstUSR as collateral at the inflated oracle price. 5. Redeem the soUSDC shares. soUSDC's totalAssets() now includes the gifted position, so the attacker's shares are worth more than when they deposited. Combined with the borrow proceeds, this covers the flashloan repayment. 6. Walk away with a small profit. wstUSR stays locked as collateral permanently. Each loop was limited by how much wstUSR the attacker had, so between loops they kept buying more on the open market. That pressure drove wstUSR from ~$0.12 to ~$0.75. The loop ran 32 times over ~75 minutes. Silo's allocator noticed and called reallocate() to move the remaining 154k to an idle holding vault. It didn't help. The idle vault was in soUSDC's withdrawal queue. Each flashloan loop inflated soUSDC's book value by depositing to the wstUSR market, but that market had nothing liquid to withdraw since it was immediately borrowed out. So soUSDC pulled the shortfall from the idle vault every single time. 154k gone in 40 seconds across 20 transactions. soUSDC depositors are now exposed to ~392k of undercollateralised debt at 100% utilisation. What could Silo have done? The oracle used by the wstUSR market is hardcoded as immutable in the SiloConfig contract. The only option available was removing the wstUSR market from soUSDC's withdrawal queue before anyone exploited it. That process requires three steps, each behind the vault's 48h timelock: enable the market with a nominal cap, set the cap back to 0, submit removal and wait for it to finalise. Six days total. They didn't start it. What can they do now? They can still run that same six-day process. It won't recover the 392k, but it prevents a repeat. They should also remove the soUSDC vault from the UI to prevent new deposits. SiloVault is forked from @Morpho's MetaMorpho contract (Silo's own source code says `Forked with gratitude from Morpho Labs`). Any MetaMorpho/SiloVault-style vault that (1) counts externally credited market balances in totalAssets(), (2) leaves the toxic market in the withdraw queue, and (3) relies on a stale or structurally incomplete pricing path can be exposed to this same class of attack. Example exploit tx: arbiscan.io/tx/0xd354389e6… Exploiter: debank.com/profile/0x8170… soUSDC Vault: v2.silo.finance/vaults/arbitru… wstUSR market: v2.silo.finance/markets/arbitr… Failed rescue tx: arbiscan.io/tx/0x3235decc8… Oracle: #readContract" target="_blank" rel="nofollow noopener">arbiscan.io/address/0x6BC7…