Glossar
Reentrancy-Angriff
Aktualisiert 12. Juni 2026
Ein Reentrancy-Angriff ist eine Angriffstechnik auf Smart Contracts, bei der ein externer Aufruf die ursprüngliche Funktion erneut aufruft, bevor deren Zustandsänderung abgeschlossen ist – mit dem Ziel, Aktionen wie Auszahlungen beliebig oft zu wiederholen, obwohl der Vertrag dies nur einmal erlauben sollte.
Funktionsweise
Das Problem entsteht, wenn ein Smart Contract in der falschen Reihenfolge vorgeht: Er prüft zunächst eine Bedingung (z. B. ausreichendes Guthaben), führt dann den externen Aufruf durch (z. B. Ether-Überweisung) und aktualisiert erst danach seinen internen Zustand (z. B. Kontostand auf null setzen). Genau in diesem Zeitfenster greift der Angriff. Ein bösartiger Empfängervertrag besitzt eine sogenannte Fallback-Funktion, die automatisch ausgeführt wird, sobald er Ether erhält. Diese Funktion ruft die Abhebefunktion des Zielvertrags sofort wieder auf – bevor der Kontostand aktualisiert wurde. Der Vertrag glaubt noch, das Guthaben sei vorhanden, und überweist erneut. Dieser Kreislauf läuft so lange, bis der Vertrag leer ist.
Das korrekte Gegenmuster heißt Checks-Effects-Interactions: Zuerst alle Bedingungen prüfen, dann den internen Zustand aktualisieren, und erst zuletzt externe Aufrufe tätigen. Wird diese Reihenfolge eingehalten, findet ein erneuter Einsprung ins Laufzeitsystem stets einen bereits aktualisierten Zustand vor – der Angriff läuft ins Leere.
Historische Bedeutung und aktueller Stellenwert
Der bekannteste Fall ist der DAO-Hack von 2016: Angreifer nutzten eine Reentrancy-Schwachstelle aus und erbeuteten rund 60 Millionen US-Dollar in Ether. Das Ereignis war so gravierend, dass es zur Hard Fork führte, aus der Ethereum und Ethereum Classic hervorgingen.
Trotz der langen Bekanntheitsgeschichte dieser Schwachstelle bleibt Reentrancy akut: Die OWASP Smart Contract Top 10 (2025) führt sie unter SC05. In dezentralen Finanzprotokollen (DeFi) verschärft sich das Risiko zusätzlich, weil Protokolle modular und komponierbar aufgebaut sind – ein Vertrag ruft einen anderen auf, der wiederum einen dritten einbindet. Jede dieser Schnittstellen ist ein potenzieller Angriffspunkt.
Zu den etablierten Gegenmaßnahmen zählen neben dem Checks-Effects-Interactions-Muster auch Reentrancy Guards (Mutex-Locks, die einen zweiten Einstieg in eine Funktion blockieren) sowie der Verzicht auf call() zugunsten von transfer() in Solidity, das die weitergeleitete Gas-Menge begrenzt. Unabhängige Smart-Contract-Audits vor dem Deployment gelten als Standard, um solche Schwachstellen frühzeitig zu identifizieren.