~36 Mio. $ verloren: Summer.fi, Bonzo Lend & mehr | BlockSec Weekly

In der vergangenen Woche (2026/07/06 - 2026/07/12) wurden insgesamt 3 nennenswerte Sicherheitsvorfälle identifiziert, die zu Verlusten von ca. 36,29 Mio. USD geführt haben.

• Summer.fi: Ausgewählt, weil es veranschaulicht, wie in mehrschichtigen Vault-Protokollen eine unvollständig abgeschaltete nachgelagerte Komponente den Anteilspreis auf der obersten Ebene unbemerkt verfälschen kann – und damit die kritische Bedeutung unterstreicht, die Stilllegung abzuschließen, bevor beeinträchtigte Positionen ausnutzbar werden.
• Bonzo Lend: Ausgewählt, weil es zeigt, wie ein subtiler Fehler in der BLS-Verifizierung auf der Oracle-Schicht die Signaturabsicherung vollständig umgehen kann, was zu gefälschten Preiswurzeln und systemischen Risiken für Protokolle führt, die auf den betroffenen Verifier angewiesen sind.

Wöchentliches Highlight: Summer.fi

Dieser Vorfall wird hervorgehoben, weil er veranschaulicht, wie in mehrschichtigen Vault-Protokollen eine unvollständig abgeschaltete nachgelagerte Komponente den Anteilspreis auf der obersten Ebene unbemerkt verfälschen kann. Das Muster gilt grundsätzlich für jedes System, das Werte aus verschachtelten oder externen Quellen aggregiert, ohne zu prüfen, ob jeder Beitragsgeber noch einwandfrei funktioniert.

Am 6. Juli 2026 wurde der Summer.fi FleetCommander Vault auf Ethereum für ca. 6,04 Mio. USD ausgenutzt [1][2]. Die Ursache war, dass Summer.fis FleetCommander eine Strategiekomponente (genannt Ark), deren Einzahlungslimit auf null gesetzt worden war, aber noch nicht aus dem aktiven Set entfernt worden war, bei der Berechnung von totalAssets() weiterhin berücksichtigte. Der Angreifer sammelte große Mengen veralteter, überbewerteter vgUSDC-Token an, die der Ark weiterhin nahe zum Nennwert bepreiste, und übertrug sie dann direkt in den Ark, um den Anteilspreis des FleetCommanders aufzublähen, und löste dann zum überhöhten Preis ein.

Hintergrund

Summer.fi ist ein DeFi-Yield-Aggregator, der auf einer Vault-in-Vault-Architektur aufbaut. Nutzer hinterlegen Vermögenswerte in einem ERC-4626-Eltern-Vault namens FleetCommander, der Mittel über eine Reihe von Strategie-Adaptern – sogenannten Arks – in verschiedene zugrunde liegende Lending- und Yield-Protokolle leitet. Die Gesamtvermögenswerte des FleetCommanders werden aus den selbst gemeldeten Werten jedes Arks aggregiert, und Nutzer können ihre Anteile jederzeit auf Basis dieser Aggregatbewertung einlösen.

Eine der zugrunde liegenden Ertragsquellen ist Morpho. Der FleetCommander hinterlegt über einen Ark Mittel in einem Morpho Vault und bewertet sich selbst anhand der dort gehaltenen Anteile. Wenn ein Nutzer FleetCommander-Anteile einlöst und der Kapitalpuffer des Eltern-Vaults nicht ausreicht, werden Mittel aus den zugrunde liegenden Vaults nach oben gezogen:

Nutzer löst FleetCommander-Anteile ein
   | (1) Anteile des Nutzers werden verbrannt
   v
FleetCommander
   | (2) Zahlung zunächst aus dem Puffer; dann Entnahme aus Arks
   v
Ark
   | (3) Zur Liquiditätsbeschaffung löst er eigene Anteile im zugrunde liegenden Vault ein
   v
Morpho Vault
     (4) Zur Auszahlung werden Mittel aus den zugrunde liegenden Märkten entnommen

Jeder Ark berechnet seinen totalAssets()-Wert, indem er sein eigenes Token-Guthaben im zugrunde liegenden Vault abfragt und diese Anteile in Vermögenswerte umrechnet. Da diese Anteile standardmäßige ERC-20-Token sind, kann jeder zusätzliche Anteile direkt in den Ark übertragen, ohne den Einzahlungsfluss des FleetCommanders zu nutzen.

Schwachstellenanalyse

Die betroffenen FleetCommander sind der LowerRisk USDC Vault (0x98C4...cF17) und der HigherRisk USDC Vault (0xE9cD...cB06). Der manipulierte Silo Varlamore Ark ist 0x61d7...76c2.

Zwei Bedingungen bereiteten den Boden für die Ausnutzung:

1. Ein veralteter, überbewerteter Vermögenswert. Nachdem Stream Finance im November 2025 kollabierte [3] und sein Yield-Token xUSD mehr als 75 % seines Wertes verlor, wurde der Silo-Vault „Varlamore USDC Growth", der durch xUSD besicherte Positionen hielt, weitgehend uneinbringlich. Die On-Chain-Buchführung des Vaults spiegelte diesen Verlust jedoch nie wider: vgUSDC-Token berichteten über convertToAssets() weiterhin einen Wert nahe dem Nennwert, obwohl der zugrunde liegende USDC faktisch blockiert war.

2. Ein teilweise entfernter Ark. Der Ark mit diesem beeinträchtigten Exposure wurde mit einem Einzahlungslimit von 0 abgeschaltet. Das Nullsetzen des Limits blockiert jedoch lediglich neue Einzahlungen über den FleetCommander. Der Ark wird dadurch nicht aus der totalAssets()-Berechnung entfernt.

Ein Ark berechnet seinen totalAssets()-Wert, indem er vault.balanceOf(address(this)) und anschließend vault.convertToAssets(shares) aufruft. Da diese Anteile übertragbare ERC-20-Token sind, kann jeder veraltete, überbewertete vgUSDC-Token direkt in den Ark übertragen, was den gemeldeten Wert des Arks aufbläht, ohne dass neue Anteile geprägt oder tatsächlich abhebbare Liquidität hinzugefügt wird. Diese Inflation überträgt sich auf den Anteilspreis des FleetCommanders.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0x0db528...43da12.

• Schritt 1: In den vorangegangenen drei Monaten sammelte der Angreifer über mehrere Wallets ca. 19,08 Mrd. vgUSDC an und konsolidierte diese kurz vor dem Exploit in den Angriffsvertrag.

• Schritt 2: Der Angreifer nahm einen Flash-Kredit über 1.000.000 USDT von Morpho Blue auf und verschachtelte einen zweiten Flash-Kredit über 65.419.171 USDC zur Finanzierung des Angriffs.

• Schritt 3: Der Angreifer rief forceDeallocate() auf mehreren Morpho-V2-Vaults auf und zog 4.318.535 USDC aus Morpho-Blue-Märkten in die Leerlaufguthaben der Vaults zurück. Dadurch wurde sichergestellt, dass ausreichend liquides Kapital für die Auszahlung der überhöhten Einlösung in einem späteren Schritt vorhanden war.

• Schritt 4: Der Angreifer tauschte 20.000 USDT gegen ca. 68.421 xUSD auf Uniswap V4 und tauschte dieses xUSD dann gegen ca. 476,27 Mio. vgUSDC auf Balancer V3. Damit wurden zusätzliche veraltete Token zu minimalen realen Kosten angesammelt.

• Schritt 5: Der Angreifer hinterlegte 64.828.534 USDC in den FleetCommander LVUSDC und erhielt 60.787.156 Anteile.

• Schritt 6: Der Angreifer übertrug direkt ca. 19,55 Mrd. vgUSDC-Anteile an den vgUSDC Ark. Da der totalAssets()-Wert des Arks alle gehaltenen Anteile zählt, unabhängig davon, wie sie eingegangen sind, blähte dies den gemeldeten Wert des Arks und entsprechend den totalAssets()-Wert des FleetCommanders auf.

• Schritt 7: Der Angreifer löste 60.766.209 FleetCommander-Anteile für 70.959.584 USDC ein und profitierte von der Differenz zwischen dem überhöhten Anteilspreis und der ursprünglichen Einzahlung.

• Schritt 8: Innerhalb derselben atomaren Transaktion wendete der Angreifer eine ähnliche Inflation auf den HigherRisk USDC FleetCommander an. Im HigherRisk-Zweig wurden Term-Anteile in den HigherRisk Term Ark gespendet statt vgUSDC, aber der zugrunde liegende Mechanismus war derselbe: totalAssets() durch Spenden aufblähen und dann zum überhöhten Preis einlösen. Der kombinierte Gewinn über beide Vaults betrug ca. 6,04 Mio. USD.

Fazit

Dies war ein Anteilspreis-Inflationsangriff, der durch einen operativen Fehler und nicht durch einen Code-Fehler verursacht wurde. Ein durch den Stream-Finance-Kollaps beeinträchtigter Silo Ark wurde während der Abschaltung weiterhin in den totalAssets() des FleetCommanders berücksichtigt [2]. Der Angreifer spendete günstig angesammelte, aber veraltete und überbewertete vgUSDC-Token in diesen Ark, blähte den Anteilspreis auf und löste mehr ein, als er eingezahlt hatte – auf Kosten anderer Einleger.

Das Nullsetzen eines Einzahlungslimits schaltet einen Ark nicht ab. Bei mehrschichtigen Vault-Systemen muss totalAssets() dekommissionierte Positionen ausschließen, und Bestände sollten zum realisierbaren Wert bewertet werden, nicht nach veralteten On-Chain-Kursen. Jede abzuschaltende Komponente sollte vollständig aus der Aggregatbewertung entfernt werden, bevor sie als Inflationsvektor dienen kann.

Referenzen

• [1] Phalcon-Warnung auf X
• [2] Summer.fi Community-Call-Zusammenfassung
• [3] Stream Finance erleidet Verlust von 93 Mio. USD (CoinDesk)

Weitere Vorfälle dieser Woche

Bonzo Lend

Am 11. Juli 2026 erlitt Bonzo Lend, ein Lending-Protokoll auf Hedera, einen Verlust von ca. 9,05 Mio. USD [1], nachdem ein Angreifer eine gefälschte Oracle-Aktualisierung für den SAUCE-Preisfeed an Supra, den Drittanbieter-Preisfeed des Protokolls, übermittelte. Der Oracle-Verifier akzeptierte einen Null-Signatur-Beweis und schrieb einen überhöhten SAUCE/WHBAR-Preis auf die Blockchain. Bonzo Lend las daraufhin den manipulierten Feed und erlaubte dem Angreifer, weit mehr Vermögenswerte zu leihen, als das hinterlegte SAUCE-Collateral wert war.

Hintergrund

Bonzo Lend ist ein Lending-Protokoll auf Hedera. Seine Marktbuchhaltung ist auf externe Preisfeeds angewiesen, darunter Supra, ein Drittanbieter-Oracle-Netzwerk, für Ökosystem-Assets wie SAUCE. Bonzo Lend authentifiziert nicht jede Oracle-Komiteesignatur selbst; es liest den zuletzt im On-Chain-Feed des Oracles gespeicherten Wert und verwendet diesen Wert bei der Berechnung von Sicherheitenwert und Kreditkapazität.

Der Pull-Oracle-Aktualisierungspfad von Supra verifiziert eine eingereichte Wurzel, bevor Feed-Daten in den Speicher geschrieben werden. Im relevanten Code-Pfad iteriert verifyOracleProofV2() durch eingereichte Oracle-Daten, ruft requireRootVerified() für noch nicht im merkleSet gecachte Wurzeln auf, verifiziert die Merkle-Blätter und schreibt dann neuere Feed-Runden über 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();
}

Die Sicherheit der Feed-Aktualisierung hängt davon ab, dass requireRootVerified() Wurzeln ablehnt, die nicht authentisch vom konfigurierten Oracle-Komitee signiert wurden.

Schwachstellenanalyse

Der fehlerhafte Vertrag ist der Supra Oracle Verifier (0.0.4323006).

Die Ursache war ein ungültiger BLS-Verifizierungspfad im vorgelagerten Supra-Oracle-Verifier. Die Exploit-Transaktion übermittelte eine Preisaktualisierung für Paar 425 (SAUCE/WHBAR) mit Komitee-ID 2 und einem auf null gesetzten Signaturwert [0, 0].

Bei einer normalen BLS-Prüfung sollte der Verifier validieren, dass Signatur und öffentlicher Schlüssel ungleich null, auf der Kurve und in der richtigen Untergruppe sind, bevor der Pairing-Precompile aufgerufen wird. Der anfällige Verifier konstruierte eine Pairing-Prüfung aus einem Null-Signaturpunkt und einem Null-Komitee-Public-Key-Punkt. Der Hedera-Pairing-Precompile gab true zurück, weil das Pairing-Produkt für Identitätspunkte mathematisch gültig ist – nicht weil eine echte Komiteesignatur vorlag.

Der Verifier muss die Eingabegültigkeit prüfen; der Precompile prüft nur die Pairing-Gleichung. Durch das fehlende Ablehnen von Nullpunkten vor dem Pairing akzeptierte das Oracle eine gefälschte Wurzel und ließ die manipulierten Preisdaten in den Speicher gelangen.

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();
    }
}

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0.0.995584-1783731093-686041919.

• Schritt 1: Der Angreifer hinterlegte 250 SAUCE als Sicherheit bei Bonzo Lend.

• Schritt 2: Der Angreifer übermittelte die schädliche Oracle-Aktualisierung an den Pull-Oracle-Vertrag von Supra. Die Aktualisierung setzte den SAUCE-Preis auf einen extrem überhöhten Wert, während der oben beschriebene auf null gesetzte BLS-Signaturbeweis verwendet wurde.

• Schritt 3: verifyOracleProofV2() akzeptierte die eingereichte Wurzel, nachdem requireRootVerified() erfolgreich zurückgekehrt war. Die Funktion verifizierte die Merkle-Blattdaten und rief packData() für die neuere Feed-Runde auf, wodurch der manipulierte SAUCE/WHBAR-Wert zum zuletzt gespeicherten Oracle-Wert wurde.

• Schritt 4: Bonzo Lend las den aktuellen SAUCE-Preis vom Oracle. Da der gespeicherte Feed-Wert bereits überhöht war, berechnete das Protokoll das SAUCE-Collateral des Angreifers von 250 SAUCE als weit mehr als seinen Marktwert.

• Schritt 5: Der Angreifer lieh ca. 6,6 Mio. USDC und 34,5 Mio. WHBAR gegen den überhöhten Sicherheitenwert. Der abnorme Preis blieb aktiv, bis eine spätere legitime Oracle-Aktualisierung SAUCE in seinen normalen Bereich zurückführte.

Fazit

Dieser Vorfall war ein Oracle-Verifizierungsfehler, kein Fehler in der Buchführung des Lending-Pools. Der Angreifer musste den SAUCE-Markt nicht manipulieren oder die internen Sicherheitenprüfungen von Bonzo Lend umgehen. Der gefälschte Preis wurde vom vorgelagerten Supra-Oracle-Verifier akzeptiert, in den Feed geschrieben und von Bonzo Lend über seinen normalen Preis-Lesepfad konsumiert.

Protokolle, die externe Feeds verwenden, erben die Sicherheitsannahmen des gesamten Oracle-Verifizierungspfads. Bei BLS-basierten Oracle-Aktualisierungen müssen Nullpunkte abgelehnt werden, bevor der Pairing-Precompile aufgerufen wird. Die Eingabevalidierung auf der kryptografischen Ebene ist nicht optional; die mathematische Gültigkeit einer Pairing-Gleichung impliziert keine Authentizität der zugrunde liegenden Signatur.

Referenzen

• [1] Bonzo Finance Incident Report

• Get Started with Phalcon Security

  Detect every threat, alert what matters, and block attacks.

  Try now for free