Wird die Sicherheit von DeFi-Protokollen durch die Verbreitung von „Vibe Coding“ gefährdet? – Eine Analyse des Moonwell-Hacks 2026

• Was ist beim Moonwell-Hack genau passiert?
• Handelt es sich um den ersten „Vibe-Coded“ Solidity-Hack?
• Warum ist dieser Fall besonders alarmierend?
• Wie reagiert die DeFi-Community?
• Was bedeutet das für die Zukunft von DeFi?
• Fragen und Antworten zum Moonwell-Hack

Die jüngste Sicherheitslücke im Moonwell-Protokoll, die zu einem Verlust von 1,78 Millionen Dollar führte, wirft ernsthafte Fragen über die Risiken von KI-generiertem Code in der DeFi-Branche auf. Dieser Vorfall markiert möglicherweise den ersten großen Hack eines durch „Vibe Coding“ erstellten Smart Contracts – eine Praxis, bei der Entwickler zunehmend auf KI-Tools wie Claude von Anthropic zurückgreifen. Während die Branche mit innovativen Lösungen experimentiert, zeigt dieser Fall, wie kritisch manuelle Code-Überprüfungen bleiben.

Was ist beim Moonwell-Hack genau passiert?

Am 19. Februar 2026 nutzte ein Angreifer eine Fehlkonfiguration im Oracle-System des Multi-Chain-Lending-Protokolls Moonwell aus. Der Preis des cbETH-Tokens wurde fälschlicherweise auf 1,12 Dollar statt 2.200 Dollar festgelegt. Diese Diskrepanz ermöglichte es dem Angreifer, erheblich mehr Mittel zu leihen, als sein hinterlegtes Collateral eigentlich erlaubt hätte – was zu einer nicht rückzahlbaren Schuld von 1,78 Millionen Dollar führte.

Handelt es sich um den ersten „Vibe-Coded“ Solidity-Hack?

Sicherheitsexperte Pashov bezeichnete den Vorstand auf X (ehemals Twitter) als möglicherweise „ersten Hack eines durch Vibe Coding erstellten Solidity-Codes“. Code-Audits zeigten, dass Teile des fehlerhaften Smart Contracts vom KI-Modell Claude Opus 4.6 generiert wurden. GitHub-Commit-Histories belegen, dass mehrere Pull Requests mit Unterstützung des KI-Tools erstellt wurden.

Warum ist dieser Fall besonders alarmierend?

Drei Faktoren machen diesen Vorstand besonders bedeutsam:

1. Es ist der erste dokumentierte Fall, bei dem KI-generierter Code direkt zu einem finanziellen Verlust führte
2. Der gleiche Angreifer hatte Moonwell bereits zuvor erfolgreich attackiert
3. Das Protokoll kontrolliert etwa 60% des Ethereum-basierten Lending-Marktes

Wie reagiert die DeFi-Community?

Das DeFi-Kollektiv YAM warnte öffentlich: „Moonwell ist kein seriöser Lending-Markt. Sie haben ihre Oracles zu oft falsch konfiguriert. Nutzt dieses Protokoll nicht.“ Solche Statements zeigen, wie sehr das Vertrauen in KI-unterstützte Entwicklung bereits erschüttert ist – besonders bei Protokollen mit hohem Total Value Locked (TVL).

Was bedeutet das für die Zukunft von DeFi?

Der Vorfall wirft grundlegende Fragen auf:

• Sollten KI-generierte Smart Contracts zusätzlichen Audits unterzogen werden?
• Müssen Protokolle ihre Nutzung von KI-Tools offenlegen?
• Wer haftet letztlich für durch KI-Code verursachte Verluste?

Während einige Entwickler argumentieren, dass KI letztlich die Code-Sicherheit verbessern wird, zeigt der Moonwell-Hack die aktuellen Risiken dieser Technologie. Bis ausgereiftere Lösungen existieren, bleibt manuelle Überprüfung unverzichtbar.

Fragen und Antworten zum Moonwell-Hack

Wie genau wurde der Oracle-Fehler ausgenutzt?

Der Angreifer nutzte die Preisdiskrepanz des cbETH-Tokens, um überhöhte Kredite aufzunehmen. Da das System den Token fälschlicherweise stark unterbewertete, konnte er mehr Mittel entleihen als sein Sicherheitenpool eigentlich zuließ.

Welche Rolle spielte Claude AI genau?

Laut Code-Analysen generierte Claude Opus 4.6 Teile der Oracle-Implementierung, einschließlich der fehlerhaften Preislogik. Die KI übersah dabei offenbar kritische Sicherheitsüberlegungen.

Gibt es Parallelen zu früheren DeFi-Hacks?

Oracle-Angriffe sind in DeFi nicht neu – der berüchtigte bZx-Hack 2020 funktionierte ähnlich. Das Besondere hier ist die Beteiligung von KI-generiertem Code, was eine neue Dimension der Verwundbarkeit schafft.

Wie kann man sich als Nutzer schützen?

Experten raten:

• Protokolle mit nachgewiesenen Sicherheitsaudits bevorzugen
• KI-generierte Codeanteile kritisch hinterfragen
• Nie mehr investieren, als man bereit ist zu verlieren