Direkt zum Hauptinhalt

606 Mio. $ in 18 Tagen: Warum durch Upgrades eingeführte Bugs der neue Top-Angriffsvektor von DeFi sind

· 13 Min. Lesezeit
Dora Noda
Dora Noda
Software Engineer

In nur 18 Tagen im April dieses Jahres entwendeten Angreifer 606 Millionen Dollar aus dem DeFi-Sektor. Dieser einzige Zeitraum übertraf die Verluste des ersten Quartals 2026 um das 3,7-fache und machte den Monat zum schlimmsten seit dem Bybit-Raub im Februar 2025. Zwei Protokolle — Drift auf Solana und Kelp DAO auf Ethereum — machten 95 Prozent des Schadens aus. Beide waren auditiert worden. Beide bestanden die statische Analyse. Beide führten Routine-Upgrades durch, die im Stillen die Annahmen entkräfteten, die ihre Auditoren zuvor verifiziert hatten.

Dies ist das neue Gesicht des DeFi-Risikos. Die katastrophalen Exploits von 2026 sind keine Reentrancy-Fehler oder Integer-Overflows mehr, die Fuzzer in der CI aufspüren können. Es geht um durch Upgrades eingeführte Schwachstellen: subtile Änderungen an Bridge-Konfigurationen, Oracle-Quellen, Admin-Rollen oder Messaging-Standardeinstellungen, die zuvor sicheren Code in eine offene Tür verwandeln — ohne dass eine einzige Zeile Solidity offensichtlich falsch aussieht.

Wenn Sie DeFi-Anwendungen entwickeln, verwalten oder einfach nur Assets darin halten, ist die Lehre aus dem April 2026 unbequem: Ein sauberer Audit-Bericht von vor drei Monaten ist kein Beweis mehr dafür, dass ein Protokoll heute sicher ist.

Das April-Muster: Konfiguration, nicht Code​

Um zu verstehen, warum „durch Upgrades eingeführte Fehler“ eine eigene Kategorie verdienen, muss man sich ansehen, wie sich die beiden größten Exploits tatsächlich abgespielt haben.

Drift Protocol — 285 Millionen Dollar, 1. April 2026. Solanas größte Perp-DEX verlor mehr als die Hälfte ihres TVL, nachdem Angreifer sechs Monate lang eine Social-Engineering-Kampagne gegen das Team durchgeführt hatten. Sobald Vertrauen aufgebaut war, nutzten sie das Solana-Feature „durable nonces“ — eine UX-Erleichterung, die es Nutzern ermöglicht, Transaktionen für eine spätere Einreichung vorab zu signieren —, um Mitglieder des Drift Security Council dazu zu verleiten, Signaturen zu autorisieren, die sie für routinemäßige operative Vorgänge hielten. Diese Signaturen übertrugen schließlich die Admin-Kontrolle an die Angreifer, die einen gefälschten Collateral-Token (CVT) auf die Whitelist setzten, 500 Millionen Einheiten davon hinterlegten und 285 Millionen Dollar in echten USDC, SOL und ETH abhoben. Das Solana-Feature funktionierte wie vorgesehen. Die Contracts von Drift taten das, was ihre Admins befahlen. Der Angriff fand vollständig in der Lücke zwischen dem statt, was die Multisig-Unterzeichner zu genehmigen glaubten, und dem, was sie tatsächlich taten.

Kelp DAO — 292 Millionen Dollar, 18. April 2026. Angreifer, die von LayerZero der nordkoreanischen Lazarus-Gruppe zugerechnet wurden, kompromittierten zwei RPC-Nodes, die die Cross-Chain rsETH-Bridge von Kelp stützten, tauschten die darauf laufenden Binärdateien aus und nutzten einen DDoS-Angriff, um ein Verifizierer-Failover zu erzwingen. Die bösartigen Nodes meldeten dem Verifizierer von LayerZero daraufhin, dass eine betrügerische Transaktion stattgefunden habe. Der Exploit funktionierte nur, weil Kelp eine 1-von-1-Verifizierer-Konfiguration verwendete — was bedeutet, dass ein einzelner von LayerZero betriebener DVN die unilaterale Autorität hatte, Cross-Chain-Nachrichten zu bestätigen. Laut LayerZero ist dieses 1-von-1-Setup der Standard in ihrem Quickstart-Guide und wird derzeit von etwa 40 Prozent der Protokolle im Netzwerk verwendet. In 46 Minuten zog ein Angreifer 116.500 rsETH ab — etwa 18 Prozent des gesamten umlaufenden Angebots — und ließ gemappte Sicherheiten auf 20 Chains festsitzen. Aave, das rsETH listet, wurde in eine Liquiditätskrise gezwungen, als die Einleger um den Ausstieg kämpften.

Weder für den einen noch für den anderen Angriff war ein Smart-Contract-Bug erforderlich. Beide setzten das Verständnis voraus, wie eine Konfiguration — Multisig-Signaturabläufe, Standard-DVN-Anzahlen, RPC-Redundanz — stillschweigend von einem „operativen Detail“ zu einer „tragenden Sicherheitsannahme“ erhoben worden war.

Warum statische Audits diese Fehlerklasse übersehen​

Das traditionelle DeFi-Audit ist für das falsche Bedrohungsmodell optimiert. Firmen wie Certik, OpenZeppelin, Trail of Bits und Halborn sind exzellent in der Zeile-für-Zeile-Codeüberprüfung und im Ausführen von Invarianten-Tests gegen eine eingefrorene Contract-Version. Das fängt Reentrancy, Fehler bei der Zugriffskontrolle, Integer-Overflows und Versäumnisse im OWASP-Stil ab.

Doch die Klasse der durch Upgrades eingeführten Fehler weist drei Eigenschaften auf, die diesen Workflow unterlaufen:

  1. Sie existiert im zusammengesetzten Laufzeitverhalten, nicht im Quellcode. Die Sicherheit einer Bridge hängt von der Verifizierer-Konfiguration ihrer Messaging-Schicht, dem DVN-Set, der RPC-Redundanz dieser DVNs und dem Slashing-Risiko dieser Betreiber ab. Nichts davon steht in dem Solidity-Code, den ein Auditor liest.

  2. Sie wird durch Änderungen eingeführt, nicht durch die Erstbereitstellung. Kelps Bridge sah vermutlich gut aus, als LayerZero v2 zum ersten Mal integriert wurde. Die DVN-Anzahl wurde erst dann gefährlich, als der TVL groß genug war, um einen Angriff lohnenswert zu machen, und als Lazarus in die Kompromittierung der RPC-Infrastruktur investierte.

  3. Sie erfordert verhaltensbasiertes Differenzial-Testing — die Beantwortung der Frage: „Wurde Invariante X unter dem neuen Codepfad beibehalten?“ — was keine der großen Audit-Firmen als geplanten Post-Upgrade-Service anbietet. Man erhält ein einmaliges Audit für Version 1.0 und ein separates einmaliges Audit für Version 1.1, aber keine kontinuierliche Bestätigung, dass das Upgrade von 1.0 auf 1.1 keine Eigenschaften bricht, auf die sich 1.0 verlassen hat.

Die Statistiken für das erste Quartal 2026 verdeutlichen diese Lücke. DeFi verzeichnete im gesamten Quartal Verluste in Höhe von 165,5 Millionen Dollar bei 34 Vorfällen. Allein der April verursachte 606 Millionen Dollar in 12 Vorfällen. Die Bereitstellungsseite skalierte — im ersten Quartal kamen über 40 Milliarden Dollar an neuem TVL hinzu —, während die Audit-Kapazitäten, die Reaktion auf Vorfälle und die Validierung nach der Bereitstellung weitgehend stagnierten. Irgendetwas musste nachgeben.

Drei Kräfte , die 2026 zum Jahr machen , in dem dies massenhaft zuschlägt​

1 . Die Upgrade-Kadenz hat sich auf jeder Ebene beschleunigt​

Jedes L1 und L2 iteriert schneller . Das Pectra-Upgrade von Ethereum befindet sich im aktiven Rollout , Fusaka und Glamsterdam sind im Design , und Solana , Sui und Aptos liefern alle Änderungen an der Execution-Layer in mehrwöchigen Zyklen aus . Jedes Upgrade auf Chain-Ebene kann die Gas-Semantik , Signaturschemata oder die Transaktionsreihenfolge auf eine Weise subtil verschieben , die sich auf die Annahmen der Applikationsschicht auswirkt . Der Exploit von Drift ist ein klares Beispiel — ein Solana-Feature ( Durable Nonces ) , das für den UX-Komfort gedacht war , wurde zum Träger für eine Admin-Übernahme .

2 . Restaking vergrößert die Upgrade-Angriffsfläche​

Der Restaking-Stack — EigenLayer ( immer noch über 80 Prozent des Marktes ) , Symbiotic , Karak , Babylon , Solayer — fügt dem Problem eine dritte Dimension hinzu . Ein einzelnes LRT wie rsETH sitzt auf EigenLayer , das wiederum auf nativem ETH-Staking sitzt . Jede Ebene liefert ihre eigenen Upgrades nach ihrem eigenen Zeitplan aus . Eine Änderung der Slashing-Semantik von EigenLayer hat implizite Folgen für jeden Operator und jedes LRT , das die Validierung dieses Operators nutzt . Als die Bridge von Kelp geleert wurde , bedrohte die Ansteckung sofort den TVL von EigenLayer , da dieselben Einleger ein dreistufiges Rehypothekarisierungs-Risiko hatten , zu dessen Modellierung sie nie gezwungen worden waren . Die Roadmap von EigenCloud mit den bevorstehenden Erweiterungen EigenDA , EigenCompute und EigenVerify wird diese Angriffsfläche nur noch weiter vergrößern .

3 . KI-gesteuerte DeFi-Aktivitäten bewegen sich schneller als menschliche Überprüfungen​

Agent-Stacks wie XION , Brahma Console und Giza interagieren jetzt mit Maschinengeschwindigkeit mit aktualisierten Verträgen . Wo ein menschlicher Schatzmeister nach einem Vertrags-Upgrade vielleicht Tage warten würde , bevor er sich erneut engagiert , testet ein Agent es back , integriert es und leitet Kapital innerhalb von Stunden hindurch . Jedes Upgrade , das stillschweigend eine Invariante bricht , wird durch gegnerische Flows einem Stresstest unterzogen , bevor ein menschlicher Auditor es erneut prüfen kann .

Die entstehende Verteidigungsarchitektur​

Die ermutigende Nachricht ist , dass die Sicherheitsforschungsgemeinschaft nicht untätig war . Die Verluste vom April 2026 haben konkrete Vorschläge an vier Fronten katalysiert .

Kontinuierliche formale Verifizierung . Die langjährige Zusammenarbeit von Certora mit Aave — finanziert als Zuschuss für kontinuierliche Verifizierung statt als einmaliges Engagement — ist nun eine Vorlage . Der Certora Prover führt automatisch Invarianten-Beweise aus , jedes Mal , wenn sich ein Vertrag ändert , und lässt Brüche vor dem Merge auftauchen . Halmos und HEVM bieten alternative Open-Source-Wege zum gleichen Ziel . Als die formale Verifizierung kürzlich eine Schwachstelle in einer Integration mit dem Electra-Upgrade von Ethereum entdeckte , die herkömmliche Audits übersehen hatten , war dies kein Einzelfall ; es war eine Vorschau .

Upgrade-Diff-Audit-Dienste . Spearbit , Zellic und Cantina haben damit begonnen , kostenpflichtige Dienste zu pilotieren , die den Diff zwischen zwei Vertragsversionen prüfen , nicht die neue Version isoliert . Das Modell behandelt jedes Upgrade als neue Attestierung und prüft explizit , ob frühere Invarianten erhalten bleiben . Das 1-Million-Dollar-Audit-Subventionsprogramm der Ethereum Foundation , das am 14 . April 2026 mit einer Partnerliste gestartet wurde , zu der Certora , Cyfrin , Dedaub , Hacken , Immunefi , Quantstamp , Sherlock , Spearbit , Zellic und Zokyo gehören , zielt teilweise darauf ab , die Kapazitäten für genau diese Art von Arbeit zu erweitern .

Chaos Engineering und Runtime-Monitoring . OpenZeppelin Defender und neue Tools integrieren Simulationen auf geforkten Mainnets in CI-Pipelines , sodass Protokolle gegnerische Szenarien gegen jedes vorgeschlagene Upgrade durchspielen können . Die Disziplin ist direkt aus der Web2 SRE-Praxis entlehnt — und im DeFi-Bereich längst überfällig .

Time-locked Upgrade Escrows . Das Compound Timelock v3-Muster , bei dem jedes von der Governance genehmigte Upgrade für eine festgelegte Verzögerung in einer öffentlichen Warteschlange verbleibt , bevor es ausgeführt wird , gibt der Community Zeit , Probleme zu erkennen , die bei der internen Prüfung übersehen wurden . Es verhindert keine durch Upgrades eingeführten Bugs , erkauft aber Zeit , damit diese vor einer Ausnutzung entdeckt werden können .

Der TradFi-Vergleich : Kontinuierliche Audits sind außerhalb von DeFi die Norm​

Das traditionelle Finanzwesen hat das analoge Problem vor Jahrzehnten gelöst . SOC 2 Type II , der Standard , an den die meisten institutionellen Dienstleister gebunden sind , ist keine einmalige Bescheinigung ; es ist ein sechs- bis zwölfmonatiges kontinuierliches Audit-Fenster . Das Kontrahentenrisiko-Framework von Basel III verlangt von Banken , ihre Kapitalmodelle zu aktualisieren , sobald sich die Risiken ändern , nicht jährlich . Einer Depotbank , die ein Abwicklungssystem aktualisiert , wäre es nicht gestattet , auf der Basis von „ wir haben v1 geprüft ; v2 war nur eine kleine Änderung “ zu arbeiten .

Die vorherrschende Kultur im DeFi-Bereich — „ einmal prüfen , für immer bereitstellen , erneute Prüfung nur bei größeren Neuschreibungen “ — ist genau die Praxis , die TradFi nach der Krise von 2008 ausdrücklich abgelehnt hat . Bei der aktuellen Verlustrate ist die Branche auf dem Weg zu 2 Milliarden Dollar oder mehr an jährlichen Verlusten durch Upgrade-Exploits . Das ist groß genug , um Regulierungsbehörden anzuziehen , die DeFi-Audit-Standards ohnehin als unzureichend betrachten , und es ist groß genug , um eine kontinuierliche Validierung zur Voraussetzung für institutionelles Kapital zu machen .

Was das für Builder , Einleger und die Infrastruktur bedeutet​

Für Protokoll-Teams ist das operative Mandat einfach , auch wenn es nicht billig ist : Jedes Upgrade muss als neues Release behandelt werden , das seine Sicherheitsgarantien neu ableitet und nicht nur erbt . Das bedeutet geplante Re-Audits auf Diff-Basis , Spezifikationen zur formalen Verifizierung , die jedem Governance-Vorschlag beiliegen , und aussagekräftige Timelocks vor der Ausführung . Es bedeutet , — im Stil von Aave — ein quantifiziertes Kaskadenrisiko-Framework zu veröffentlichen , das benennt , von welchen Protokollen man abhängt und wie das Risiko aussieht , wenn eines davon ausfällt .

Für Einleger ist die Lektion , dass „ dieses Protokoll wurde geprüft “ für sich genommen kein nützliches Signal mehr ist . Die richtige Frage lautet : „ Wann fand der letzte kontinuierliche Verifizierungslauf gegen welche Invarianten und auf welcher Version des bereitgestellten Codes statt ? “ Protokolle , die das nicht beantworten können , sollten entsprechend bepreist werden .

Für Infrastrukturanbieter — RPC-Betreiber , Indexer , Custodians — ist der Kelp-Vorfall eine direkte Warnung . Die Kompromittierung fand in zwei RPC-Nodes statt , deren Binärdateien stillschweigend ausgetauscht wurden . Jeder , der Infrastruktur betreibt , die an der Cross-Chain-Verifizierung teilnimmt ( DVNs , Oracle-Nodes , Sequencer ) , ist nun Teil des Sicherheitsmodells , ob er sich dafür angemeldet hat oder nicht . Reproduzierbare Builds , attestierte Binärdateien , Multi-Operator-Quoren anstelle von 1-von-1-Standardeinstellungen und die Verifizierung signierter Binärdateien beim Start sind nicht länger optional .

Upgrades auf Chain-Ebene — Pectra und Fusaka auf Ethereum , Rollouts für parallele Ausführung auf Solana und Aptos , die Durchsatzziele von Glamsterdam — werden die Angriffsfläche weiter vergrößern . Die Protokolle und Infrastrukturbetreiber , die 2026 überleben , werden diejenigen sein , die die kontinuierliche Validierung früh genug eingeführt haben , sodass ihr nächstes Routine-Upgrade auch ihr nächster beweisbarer Sicherheits-Checkpoint ist .

BlockEden . xyz betreibt RPC- , Indexer- und Node-Infrastrukturen in Produktionsumgebungen für Sui , Aptos , Ethereum , Solana und ein Dutzend weiterer Chains . Wir behandeln jedes Protokoll-Upgrade — auf der Chain-Ebene oder der Applikationsebene — als neues Sicherheitsereignis , nicht als Wartungsaufgabe . Erkunden Sie unsere Enterprise-Infrastruktur , um auf einem Fundament aufzubauen , das darauf ausgelegt ist , die kommende Upgrade-Kadenz zu überstehen .

Quellen​

Share on Twitter