Drift-Exploit löst Alarm aus: Berichte über Personalwechsel und massive Multisig-Änderung vor dem Angriff
Drift-Exploit löst Alarm aus: Berichte über Personalwechsel und massive Multisig-Änderung vor dem Angriff
Am 1. April 2026 erlebte Solana DeFi einen weiteren Schock für seine Glaubwürdigkeit, als Drift Protocol ( eine zentrale Plattform für Perpetual Futures im Ökosystem ) einen aktiven Sicherheitsvorfall bestätigte und kritische Funktionen pausierte, während Ermittler maßgeschneiderte Abflüsse untersuchten. Frühe Schätzungen von Sicherheitsexperten und Medienberichten beliefen sich auf $200 Mio. bis rund $285 Mio. an betroffenen Vermögenswerten, womit dies einer der größten DeFi-Exploits des Jahres 2026 bisher war. (decrypt.co)
Was diesen Vorfall besonders beunruhigend macht, ist nicht nur die Schlagzeilensumme, sondern auch die wachsende Liste von „ operativen “ Anomalien, die in der Community diskutiert werden: Admin-ähnliche Signierberechtigungen ohne Zeitverzögerung ( Timelock ), eine kurzfristige Migration des Multisig-Kontos und Gerüchte über Teamwechsel nahe dem Tatzeitraum. (tw.theblockbeats.news)
Dieser Artikel beleuchtet, was derzeit bekannt ist, was lediglich behauptet wird, und – am wichtigsten – was DeFi-Nutzer aus dieser weiteren Erinnerung lernen sollten, dass „ dezentrale “ Systeme auf der Ebene der Schlüsselverwaltung immer noch versagen können.
Was passiert ist ( und was wir heute verantwortungsvoll sagen können )
Öffentliche Berichte deuten darauf hin, dass Drift Einzahlungen und Auszahlungen pausierte, nachdem unautorisierte Vermögensbewegungen festgestellt wurden. Mehrere Quellen nannten Schätzungen von über 200 Mio. US-Dollar, einige sprachen von rund 285 Mio. US-Dollar. (techcrunch.com)
Zum Zeitpunkt der Verfassung dieses Artikels ( 2. April 2026 ) wurde die vollständige Ursache in diesen Berichten noch nicht abschließend geklärt. Diese Unsicherheit ist wichtig, da die Benutzerschutzmechanismen dramatisch unterschiedlich sind, je nachdem, ob es sich bei dem Vorfall um Folgendes handelte:
- eine Schwachstelle im Smart Contract
- eine kompromittierte Private Key / Signer-Gruppe eines Multisig-Kontos
- eine Übernahme der Governance oder Upgrade-Berechtigung
- oder eine Kombination aus den oben genannten Punkten.
In der Praxis „ preist “ der Markt tendenziell den schlimmsten Fall ein, wann immer es glaubwürdige Beweise für den Missbrauch mächtiger Schlüssel gibt – insbesondere wenn kein erzwungener Verzögerungsmechanismus zur Schadensbegrenzung vorhanden ist.
Das Kernproblem: Ein mächtiger Signierschlüssel ohne Timelock-Puffer
Laut einem Bericht von BlockBeats, der sich auf den Gründer von Chaos Labs, Omer Goldberg ( einen Risikoberater von Aave ), beruft, verfügte der Signierschlüssel des Drift-Protokolls angeblich über mehrere hochwirksame Privilegien und besaß entscheidenderweise keinen Timelock oder einen ähnlichen Verzögerungsmechanismus. (tw.theblockbeats.news)
Warum das wichtig ist:
- Wenn ein Signierschlüssel kritische Parameter ändern, Sicherheitsmodule deaktivieren oder Vermögenswerte umleiten kann, dann kann die Kompromittierung dieses Schlüssels weniger wie ein typischer „ Exploit “ und mehr wie eine schnelle, privilegierte Übernahme aussehen.
- Ohne Timelock verlieren Benutzer und Integratoren das eine defensive Fenster, das oft den Unterschied zwischen einem „ eingedämmten Vorfall “ und einem „ Totalausverkauf “ ausmacht.
Ein Timelock ist kein Schlagwort; es ist eine praktische Kontrolle, die eine Mindestverzögerung zwischen der Planung einer privilegierten Aktion und ihrer Ausführung einführt und es dem Ökosystem ermöglicht, die Aktion zu erkennen und darauf zu reagieren. (docs.openzeppelin.com)
Die Multisig-Migration „ eine Woche zuvor “: Warum die Details unnormal erscheinen
BlockBeats berichtete weiter, dass Drift eine Woche vor dem Vorfall zu einem neuen Multisig-Konto migrierte, das von einem Signer des ursprünglichen Multisig erstellt wurde. Der Bericht fügt ein besonders ungewöhnliches Detail hinzu: Der Ersteller fügte sich selbst nicht als Signer auf dem neuen Multisig hinzu, und die Signierschwelle wurde auf 2 von 5 ( 1 alter Signer + 4 neue Signer ) geändert. (tw.theblockbeats.news)
Aus Sicht der Governance und der operativen Sicherheit wirft dies mehrere Fragen auf, die Ermittler typischerweise sofort stellen:
-
Warum die Multisig-Verwaltung kurz vor einem größeren Vorfall migriert wurde? Manchmal ist es eine routinemäßige Signer-Rotation. Manchmal ist es eine Reaktion auf eine vermutete Kompromittierung. Manchmal ist es keines von beiden – und die Zeitwahl ist zufällig. Aber der Zeitpunkt verdient immer eine genaue Prüfung.
-
Warum sollte der Multisig-Ersteller sich selbst ausschließen? Es gibt harmlose Möglichkeiten ( z. B. ein Betriebsingenieur, der Infrastruktur für andere bereitstellt ), aber es ist ungewöhnlich genug, um die Notwendigkeit transparenter, überprüfbarer Erklärungen zu erhöhen.
-
Ist 2 von 5 eine angemessene Schwelle für „ protokollkritische “ Berechtigungen? Eine niedrigere Schwelle kann die operative Reibung verringern, aber sie reduziert auch die Anzahl der unabhängigen Fehler, die ein Angreifer ausnutzen muss. Multisig-Sicherheit ist nicht nur Mathematik; sie umfasst auch die Unabhängigkeit der Signer, die Praktiken der Schlüsselaufbewahrung und die Disziplin der Governance-Prozesse. (frameworks.securityalliance.org)
Einfach ausgedrückt: Wenn die mächtigsten Berechtigungen eines Protokolls mit nur zwei Bestätigungen ausführbar werden – und es keinen Timelock gibt –, wird die Sicherheit des gesamten Systems eng mit der menschlichen Schlüsselverwaltung verknüpft
Gerüchte über Personalwechsel bei Führungskräften / Kernteam: Warum „ Personenrisiko “ Teil des On-Chain-Risikos ist
Derselbe Artikel von BlockBeats erwähnt Community-Diskussionen, dass ein Kernmitglied des Drift-Teams im Vormonat möglicherweise gegangen sei, was Bedenken hinsichtlich des internen Managements, der Schlüsselübergabe und der Risikokontrollen hervorrief. (tw.theblockbeats.news)
Hier geht es nicht um Klatsch – es geht um eine bekannte Ausfallursache in der Krypto-Sicherheit:
- Rollenverschiebungen ( Personen wechseln die Rollen, gehen oder verlieren den Zugriff, während die Berechtigungen bestehen bleiben ) können unsichtbare Single Points of Failure create.
- Im schlimmsten Fall wird die Schlüsselverwahrung unklar, genau dann, wenn Klarheit am dringendsten benötigt wird ( Incident Response, Signer-Rotation, Entscheidungen über Notfallsperren ).
Selbst bei Verwendung von Multisig kann die „ Sicherheitsgrenze “ immer noch zusammenbrechen, wenn die Auswahl der Signer, die Dokumentation und das Offboarding nicht wie ein hochriskantes Betriebsverfahren gehandhabt werden.
2025 – 2026 Trend: DeFi’s wiederkehrender „ Admin Key Reality Check “
Im letzten Zyklus ist DeFi schneller, komponierbarer und stärker mit institutionellen Akteuren vernetzt – aber die Protollsicherheit wird immer wieder durch zentralisierte Upgrade-Berechtigungen und privilegierte Rollen untergraben. Insbesondere Solana-Programme behalten oft die Upgrade-Berechtigung, es sei denn, sie wird ausdrücklich eingeschränkt oder aufgegeben, weshalb „ Admin Key Risk “ ein zentraler Due-Diligence-Punkt für jeden ernsthaften DeFi-Teilnehmer bleibt. (solana.com)
Der Drift-Vorfall sollte daher am besten nicht als isoliertes Ereignis, sondern als Teil eines breiteren Musters verstanden werden:
- Smart Contracts können geprüft werden; die operative Schlüsselverwaltung ist von außen schwerer kontinuierlich zu verifizieren.
- Multisig ist nicht automatisch „ dezentral “; seine Sicherheit hängt von der Unabhängigkeit der Signer, der Wahl der Schwellenwerte und von Schutzmechanismen wie Timelocks und Überwachung ab.
- Da das TVL im Jahr 2026 zu Strategien mit höherer Geschwindigkeit zurückkehrt, folgen Angreifer der Liquidität – insbesondere dort, wo privilegierte Aktionen schnell ausgeführt werden können.
Was Nutzer nach Vorfällen wie Drift tun sollten ( praktische Checkliste )
Wenn Sie Drift direkt oder indirekt ( über Vaults, Integrationen oder Solana DeFi-Strategieprodukte ) genutzt haben, nehmen Sie die Situation als Anlass, ein strengeres Risikomanagement-Protokoll zu implementieren:
1) Indirekte Exposure erneut prüfen
Auch wenn Sie nie in Drift eingezahlt haben, haben Sie möglicherweise eine Exposure durch integrierte Vaults oder Strategieprodukte, die Gelder an Drittprotokolle weiterleiten. Öffentliche Erklärungen anderer Solana-Projekte zeigen, wie schnell die Unterscheidung zwischen „ nicht betroffen “ und „ teilweise betroffen über einen Vault “ abweichen kann. (tw.theblockbeats.news)
2) „ Immer aktive “ Genehmigungen und blindes Signieren reduzieren
Viele Ausleitungen eskalieren, wenn Benutzer ( oder Betreiber ) unter Druck Nachrichten oder Transaktionen signieren. Bevorzugen Sie Setups, bei denen Genehmigungen minimiert, zeitlich begrenzt und leicht widerrufbar sind.
3) Langfristige Gelder von Hot Wallets fernhalten, die für DeFi genutzt werden
Trennen Sie Wallets nach Verwendungszweck:
- eine „ Trading-Wallet “ für die routinemäßige DeFi-Nutzung
- und eine „ Vault-Wallet “ für die langfristige Aufbewahrung.
Dies verhindert keine protokollweiten Exploits, aber es reduziert die Explosionsreichweite von Phishing, bösartigen dApps und versehentlichen Genehmigungen während chaotischer Nachrichtenzyklen.
Wo eine Hardware-Wallet wie OneKey in diese Geschichte passt ( und wo nicht )
Eine Hardware-Wallet kann ein bereits kompromittiertes Protokoll nicht reparieren. Drifts gemeldete Warnsignale – mächtige Schlüssel, Multisig-Änderungen und die Möglichkeit eines Fehlers im Schlüsselmanagement – unterstreichen jedoch, warum die Disziplin bei der Schlüsselaufbewahrung für Benutzer und Teams gleichermaßen unverzichtbar bleibt.
Wenn Sie ein DeFi-Benutzer ( oder ein Multisig-Signer ) sind:
- Die Verwendung einer Hardware-Wallet hilft, private Schlüssel von kompromittierten Browsern, Erweiterungen und malware-belasteten Umgebungen zu isolieren.
- Die klare, geräteinterne Transaktionsprüfung kann die Wahrscheinlichkeit verringern, dass unter Stresssituationen mit hoher Belastung ( ein häufiger Faktor während der „ Live “ -Phasen eines Exploits ) die falsche Aktion genehmigt wird.
- Für Teams ist die Trennung von Signer-Geräten und die Durchsetzung konsistenter Signierverfahren eine Grundvoraussetzung, wenn Protokolle große Mengen an Benutzergeldern kontrollieren.
OneKey wird in Krypto-nativer Arbeitsabläufe für sicheres Signieren über große Chains hinweg häufig verwendet und ist somit eine praktische Option für Benutzer, die ihre Selbstverwahrung stärken möchten, ohne die grundlegende Funktionsweise von DeFi zu ändern.
Abschließender Gedanke: DeFi-Sicherheit ist zunehmend „ Governance-Sicherheit “
Der Drift-Exploit wird noch analysiert, aber die Lektionen sind bereits vertraut: Die gefährlichsten Schwachstellen sind oft keine exotischen kryptografischen Brüche – es sind hochprivilegierte Kontrollen, die zu schnell, mit zu wenig Reibung und zu wenig Zeit für die Öffentlichkeit zur Reaktion ausgeführt werden. (tw.theblockbeats.news)
Für Benutzer im Jahr 2026 ist die Frage „ Welche Chain? “ weniger wichtig als:
- Wer kann die Regeln ändern?
- Wie schnell können sie das tun?
- Welche Mechanismen geben den Nutzern Zeit zum Ausstieg, wenn etwas schiefgeht?
Bis Timelocks, transparente Multisig-Governance und überprüfbare Upgrade-Beschränkungen zum Standard werden, sollte jeder ernsthafte DeFi-Teilnehmer davon ausgehen, dass Protokollrisiko auch Schlüsselverwaltungsrisiko ist – und entsprechend planen. (docs.openzeppelin.com)
