Das Label „auditiert“ soll in der Kryptobranche Vertrauen schaffen. Für viele Anleger klingt es wie ein Gütesiegel: Der Code wurde geprüft, also müssten die Gelder sicher sein. Doch genau dieses Verständnis ist gefährlich. Der spektakuläre Bybit-Hack im Februar 2025 zeigt, dass ein Audit oft nur einen kleinen Teil eines viel größeren Systems abdeckt – während Angreifer gezielt die Bereiche attackieren, die gar nicht geprüft wurden.
Der Bybit-Fall zeigt die Grenze von Audits
Am 21. Februar 2025 transferierte Bybit wie üblich Gelder von einer Ethereum-Cold-Wallet in eine Hot-Wallet. Die verantwortlichen Unterzeichner prüften die Zieladresse auf ihren Bildschirmen und gaben die Transaktion frei. Das Problem: Die angezeigten Informationen waren manipuliert. Während die Signierer glaubten, eine normale interne Bewegung zu autorisieren, erhielten die Angreifer tatsächlich die Kontrolle über die Wallet.
Bybit bezifferte den Schaden später auf 1,46 Milliarden US-Dollar. Die US-Bundespolizei FBI machte Nordkorea für den Diebstahl verantwortlich. Nach bisherigen Erkenntnissen lag die Schwachstelle nicht in den privaten Schlüsseln selbst. Vielmehr reichten gültige Signaturen aus, weil Menschen eine falsche Beschreibung der Transaktion angezeigt bekamen.
Auch Safe erklärte später, dass wohl ein kompromittierter Entwickler-Rechner den Vorfall ermöglicht habe. Externe Prüfer fanden laut Safe keine Schwachstelle in den Smart Contracts selbst und auch keinen Fehler im veröffentlichten Frontend-Code. Genau hier liegt der Kern des Problems: Der Code kann sauber geprüft sein – und trotzdem scheitert das System an der Oberfläche, den Abläufen oder den beteiligten Personen.
Ein Smart-Contract-Audit bedeutet also nicht automatisch, dass auch Benutzeroberflächen, Cloud-Zugänge, Signaturprozesse, Entwicklergeräte oder Produktionskonfigurationen sicher sind. Dennoch wird das „auditiert“-Badge auf vielen Webseiten so dargestellt, als wäre das gesamte Projekt umfassend abgesichert.
Warum das „auditiert“-Badge oft mehr verspricht, als geprüft wurde
In der Praxis prüfen Auditoren meist sehr klar abgegrenzte Bereiche: bestimmte Dateien, bestimmte Commits, einen festen Zeitraum. Ein Audit-Bericht bezieht sich also häufig auf einen konkreten Stand des Codes – nicht automatisch auf spätere Änderungen, nicht auf die Live-Konfiguration und nicht auf die gesamte Organisation hinter dem Projekt.
Das Problem entsteht, wenn aus einem solchen begrenzten Prüfbericht im Marketing ein allgemeines Sicherheitsversprechen wird. Für Nutzer klingt „auditiert“ schnell wie: sichere Gelder, professioneller Betrieb, umfassend getestete Software. Tatsächlich kann dahinter nur eine punktuelle Codeprüfung stehen.
Eine aktuelle Vorabstudie von Stefan Beyer von Oak Security verdeutlicht diese Lücke. Er verglich 23.818 öffentliche Audit-Funde von 22 Sicherheitsfirmen mit 218 Sicherheitsvorfällen aus den Jahren 2022 bis 2026. Die dabei erfassten Schäden beliefen sich auf rund 7,764 Milliarden US-Dollar.
Die häufigsten Audit-Funde betrafen klassische Code-Probleme: Logikfehler, Codequalität, Eingabeprüfung und Zugriffsrechte. Doch bei den größten realen Verlusten dominierten ganz andere Ursachen: kompromittierte private Schlüssel, Phishing, Social Engineering, Infrastrukturprobleme und Governance-Angriffe.
Besonders auffällig: Private-Key-Kompromittierungen waren die teuerste Einzelursache. Phishing und Social Engineering lagen ebenfalls ganz vorne. Zusammengenommen entfiel ein großer Teil der gestohlenen Summen auf Bereiche, die außerhalb eines normalen Smart-Contract-Audits liegen.
Zwar muss man diese Daten vorsichtig lesen. Die Studie ist ein Preprint, also keine abschließend begutachtete wissenschaftliche Arbeit. Außerdem ist „zuvor auditiert“ kein Beweis dafür, dass Auditoren eine Schwachstelle übersehen haben. Manchmal wurde nur eine ältere Version geprüft, manchmal ein anderer Teil des Systems, manchmal führte der Angriff über Infrastruktur oder Benutzer statt über den geprüften Code.
Trotzdem ist die Aussage klar: Viele Verluste entstehen nicht dort, wo Audits typischerweise hinschauen. Angreifer prüfen nicht nur den Smart Contract. Sie analysieren das gesamte Unternehmen – vom Entwickler-Laptop bis zum Bildschirm des Signierers.
Was Anleger stattdessen sehen sollten
Das eigentliche Problem ist weniger das Audit selbst als die Sprache drumherum. Ein Audit kann wertvoll sein. Es wird nur oft als pauschales Sicherheitsversprechen verkauft, obwohl es in Wirklichkeit eine begrenzte technische Prüfung ist.
Statt eines simplen „auditiert“-Badges wäre ein standardisiertes Sicherheitslabel sinnvoller. Darauf sollte klar stehen, was genau geprüft wurde: welche Code-Version, welche Verträge, in welchem Zeitraum und ob kritische offene Punkte übrig geblieben sind.
Ebenso wichtig wäre die Angabe, ob der aktuell eingesetzte Code wirklich mit der geprüften Version übereinstimmt. Auch Produktionskonfiguration, Schlüsselverwaltung, Multi-Sig-Prozesse, Frontend-Infrastruktur, Build-Systeme und Cloud-Zugriffe sollten separat ausgewiesen werden. Denn genau dort entstehen in der Praxis oft die größten Risiken.
Für Anleger würde das ein deutlich realistischeres Bild schaffen. Ein Projekt könnte dann offen sagen: Die Smart Contracts wurden geprüft, aber die Deployment-Umgebung, die Signaturabläufe oder das Frontend nicht. Das wäre ehrlicher – und würde verhindern, dass Nutzer aus einem Teil-Audit auf die Sicherheit des gesamten Systems schließen.
Der Bybit-Fall ist dafür ein warnendes Beispiel. Die Börse konnte ihre ETH-Reserven rasch wiederherstellen, doch die finanzielle Erholung löst nicht das eigentliche Problem: Wenn das, was auf dem Bildschirm angezeigt wird, nicht mit der tatsächlichen Transaktion übereinstimmt, hilft ein Audit des Smart Contracts allein nur begrenzt.
Für Investoren bedeutet das vor allem eines: Das Wort „auditiert“ sollte nicht als Garantie verstanden werden. Es beschreibt bestenfalls eine begrenzte Prüfung. Wer Sicherheit bewerten will, sollte immer fragen, was geprüft wurde, was nicht und wie aktuell diese Prüfung noch ist.
