~$36M Lost: Summer.fi, Bonzo Lend & More

During the past week (2026/07/06 - 2026/07/12), a total of 3 notable security incidents were identified, resulting in approximately $36.29M in losses.

Date	Incident	Type	Estimated Loss
2026/07/06	Summer.fi	Misconfiguration	~$6.04M
2026/07/06	BonkDAO	Improper Governance	~$21.2M
2026/07/11	Bonzo Lend	Improper Signature Validation	~$9.05M

Summer.fi: Selected because it illustrates how, in multi-layer vault protocols, an incompletely offboarded downstream component can silently corrupt share prices at the top level, highlighting the critical importance of completing decommissioning before impaired positions become exploitable.
Bonzo Lend: Selected because it demonstrates how a subtle flaw in BLS verification at the oracle layer can completely bypass signature security, leading to forged price roots and systemic risk for protocols dependent on the affected verifier.

Weekly Highlight: Summer.fi

This incident is highlighted because it illustrates how, in multi-layer vault protocols, an incompletely offboarded downstream component can silently corrupt share prices at the top level. The pattern applies broadly to any system that aggregates values from nested or external sources without verifying that every contributor is still healthy.

On July 6, 2026, the Summer.fi FleetCommander vault on Ethereum was exploited for approximately $6.04M [1][2]. The root cause was that Summer.fi's FleetCommander still counted a strategy component (called an Ark) that had been capped for offboarding but not yet removed from the active set when computing its totalAssets(). The attacker accumulated large amounts of stale, overvalued vgUSDC tokens that the Ark still priced near par, then directly transferred them into the Ark to inflate the FleetCommander's share price and redeemed at the inflated price.

Background

Summer.fi is a DeFi yield aggregator built on a vault-of-vaults architecture. Users deposit assets into an ERC-4626 parent vault called FleetCommander, which routes funds through a set of strategy adapters called Arks into various underlying lending and yield protocols. The FleetCommander's total assets are aggregated from each Ark's self-reported value, and users can redeem their shares at any time based on this aggregate valuation.

One of the underlying yield sources is Morpho. The FleetCommander, via an Ark, deposits funds into a Morpho Vault and values itself by the shares it holds in that vault. When a user redeems FleetCommander shares, if the parent vault's cash buffer is insufficient, it pulls funds up the stack from the underlying vaults:

User redeems FleetCommander shares
   | (1) Burn the user's shares
   v
FleetCommander
   | (2) Pay from the buffer first; then pull from Arks
   v
Ark
   | (3) To raise cash, redeems its own shares in the underlying vault
   v
Morpho Vault
     (4) To pay out, withdraws from the underlying markets

Each Ark computes its totalAssets() by querying its own token balance in the underlying vault and converting those shares to assets. Because these shares are standard ERC-20 tokens, anyone can transfer additional shares directly into the Ark without going through the FleetCommander's deposit flow.

Vulnerability Analysis

The affected FleetCommanders are the LowerRisk USDC vault (0x98C4...cF17) and the HigherRisk USDC vault (0xE9cD...cB06). The manipulated Silo Varlamore Ark is 0x61d7...76c2.

Two conditions set the stage for exploitation:

A stale, overvalued asset. After Stream Finance collapsed in November 2025 [3] and its yield token xUSD lost over 75% of its value, the Silo "Varlamore USDC Growth" vault, which held positions backed by xUSD, became largely unrecoverable. However, the vault's on-chain accounting never reflected this loss: vgUSDC tokens continued to report a value near par through convertToAssets(), even as the underlying USDC remained stranded.
A partly removed Ark. The Ark holding this impaired exposure was being offboarded with its deposit cap set to 0. However, zeroing the cap only blocks new deposits through the FleetCommander. It does not remove the Ark from the totalAssets() calculation.

An Ark computes its totalAssets() by calling vault.balanceOf(address(this)) and then vault.convertToAssets(shares). Since those shares are transferable ERC-20 tokens, anyone can directly transfer more of the stale, overvalued vgUSDC into the Ark, inflating its totalAssets() with no new shares minted and no real withdrawable liquidity added. This inflation propagates up to the FleetCommander's share price.

Attack Analysis

The following analysis is based on the transaction 0x0db528...43da12.

Step 1: Over the preceding three months, the attacker accumulated approximately 19.08B vgUSDC through multiple wallets, then consolidated them into the attack contract shortly before the exploit.
Step 2: The attacker took a 1,000,000 USDT flash loan from Morpho Blue, then nested a second 65,419,171 USDC flash loan to fund the attack.
Step 3: The attacker called forceDeallocate() on multiple Morpho V2 vaults, pulling 4,318,535 USDC from Morpho Blue markets back into the vaults' idle balances. This ensured enough liquid capital was available to pay out the inflated redemption in a later step.

Step 4: The attacker swapped 20,000 USDT for approximately 68,421 xUSD on Uniswap V4, then swapped that xUSD for approximately 476.27M vgUSDC on Balancer V3. This accumulated additional stale tokens at minimal real cost.
Step 5: The attacker deposited 64,828,534 USDC into FleetCommander LVUSDC and received 60,787,156 shares.
Step 6: The attacker directly transferred approximately 19.55B vgUSDC shares to the vgUSDC Ark. Because the Ark's totalAssets() counts all shares it holds regardless of how they arrived, this inflated the Ark's reported value and correspondingly inflated the FleetCommander's totalAssets().

Step 7: The attacker redeemed 60,766,209 FleetCommander shares for 70,959,584 USDC, profiting from the difference between the inflated share price and the original deposit.

Step 8: Within the same atomic transaction, the attacker applied a similar inflation to the HigherRisk USDC FleetCommander. The HigherRisk leg used Term shares donated into the HigherRisk Term Ark rather than vgUSDC, but the underlying mechanism was the same: inflate totalAssets() via donation, then redeem at the inflated price. The combined profit across both vaults was approximately $6.04M.

Conclusion

This was a share price inflation attack caused by an operational failure rather than a code bug. A Silo Ark impaired by the Stream Finance collapse was still counted in the FleetCommander's totalAssets() while being offboarded [2]. The attacker donated cheaply accumulated but stale, overvalued vgUSDC into this Ark, inflated the share price, and redeemed more than deposited at other depositors' expense.

Zeroing a deposit cap does not offboard an Ark. For multi-layer vault systems, totalAssets() must exclude retired positions, and holdings should be priced by realizable value rather than stale on-chain quotes. Any component being offboarded should be fully removed from the aggregate valuation before it can serve as an inflation vector.

References

[1] Phalcon Alert on X
[2] Summer.fi Community Call Recap
[3] Stream Finance Faces $93 Million Loss (CoinDesk)

More Incidents This Week

Bonzo Lend

On July 11, 2026, Bonzo Lend, a lending protocol on Hedera, suffered an approximately $9.05M loss [1] after an attacker submitted a forged oracle update to Supra, the protocol's third-party price feed provider, for the SAUCE price feed. The oracle verifier accepted a zero-signature proof and wrote an inflated SAUCE/WHBAR price on-chain. Bonzo Lend then read the manipulated feed and allowed the attacker to borrow far more assets than the posted SAUCE collateral was worth.

Background

Bonzo Lend is a lending protocol on Hedera. Its market accounting depends on external price feeds, including Supra, a third-party oracle network, for ecosystem assets such as SAUCE. Bonzo Lend does not authenticate every oracle committee signature itself; it reads the latest value already stored in the oracle's on-chain feed and uses that value when calculating collateral value and borrowing capacity.

Supra's pull-oracle update path verifies a submitted root before writing feed data into storage. In the relevant code path, verifyOracleProofV2() iterates through submitted oracle data, calls requireRootVerified() for roots not already cached in merkleSet, verifies the Merkle leaves, and then writes newer feed rounds through packData().

if (merkleSet.contains(oracle.data[i].root)) {
    continue;
}
requireRootVerified(oracle.data[i].root, oracle.data[i].sigs, oracle.data[i].committee_id);
if (!merkleSet.set(oracle.data[i].root)) {
    revert RootIsZero();
}

The security of the feed update depends on requireRootVerified() rejecting roots that are not genuinely signed by the configured oracle committee.

Vulnerability Analysis

The buggy contract is the Supra oracle verifier (0.0.4323006).

The root cause was an invalid BLS verification path in the upstream Supra oracle verifier. The exploit transaction submitted a price update for pair 425 (SAUCE/WHBAR) with committee ID 2 and a zeroed signature value [0, 0].

For a normal BLS check, the verifier should validate that the signature and public key are non-zero, on-curve, and in the correct subgroup before calling the pairing precompile. The vulnerable verifier constructed a pairing check from a zero signature point and a zero committee public key point. The Hedera pairing precompile returned true because the pairing product for identity points is mathematically valid, not because a real committee signature existed.

The verifier must check input validity; the precompile only checks the pairing equation. By missing the zero-point rejection before pairing, the oracle accepted a forged root and allowed the manipulated price data to pass into storage.

function requireHashVerified_V2(
    bytes32 _message,
    uint256[2] calldata _signature,
    uint256 committee_id
) public view {
    bool callSuccess;
    bool checkSuccess;
    (checkSuccess, callSuccess) = BLS.verifySingle(
        _signature,
        committee_public_key[committee_id],
        BLS.hashToPoint(domain, abi.encode(_message)),
        blsPrecompileGasCost
    );
    if (!callSuccess) {
        revert BLSInvalidPublicKeyorSignaturePoints();
    }
    if (!checkSuccess) {
        revert BLSIncorrectInputMessaage();
    }
}

Attack Analysis

The following analysis is based on the transaction 0.0.995584-1783731093-686041919.

Step 1: The attacker deposited 250 SAUCE into Bonzo Lend as collateral.
Step 2: The attacker submitted the malicious oracle update to Supra's pull-oracle contract. The update set the SAUCE price to an extremely inflated value while using the zeroed BLS signature proof described above.

Step 3: verifyOracleProofV2() accepted the submitted root after requireRootVerified() returned successfully. The function verified the Merkle leaf data and called packData() for the newer feed round, causing the manipulated SAUCE/WHBAR value to become the latest stored oracle value.
Step 4: Bonzo Lend read the latest SAUCE price from the oracle. Since the stored feed value was already inflated, the protocol calculated the attacker's 250 SAUCE collateral as being worth far more than its market value.
Step 5: The attacker borrowed approximately 6.6M USDC and 34.5M WHBAR against the inflated collateral value. The abnormal price remained live until a later legitimate oracle update restored SAUCE to its normal range.

Conclusion

This incident was an oracle-verification failure, not a lending-pool accounting bug. The attacker did not need to manipulate the SAUCE market or bypass Bonzo Lend's internal collateral checks. The forged price was accepted by the upstream Supra oracle verifier, written into the feed, and consumed by Bonzo Lend through its normal price-read path.

Protocols consuming external feeds inherit the security assumptions of the entire oracle verification path. For BLS-based oracle updates, zero points must be rejected before the pairing precompile is called. Input validation at the cryptographic layer is not optional; mathematical validity of a pairing equation does not imply authenticity of the underlying signature.

References

[1] Bonzo Finance Incident Report

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.