Um 1 Uhr nachts habe ich das Dusk-Bridge-Vorfall-Recap und die AEGIS-Analyse hintereinander komplett durchgesehen. Bevor ich die Seite geschlossen habe, kam mir plötzlich etwas Angst: Vor ein paar Tagen stand ich auch kurz davor, so ein besonders bequemes Zwei-Aus-Wahlen-Ding zu akzeptieren – „kein L1-Fehler, also ist nicht viel“ oder „weil die Bridge passiert ist, ist die ganze Kette unsicher“.
Die Realität ist viel komplizierter als die Parolen. Am 16. Januar 2026 erhielt ein Angreifer die Berechtigung für eine signierende Wallet, die für den Dusk- bis EVM-Bridge-Service verwendet wird.
Das offizielle Recap stellt klar: Das ist kein Konsensversagen und auch nicht, dass das Dusk-Basissystem (das zugrunde liegende Protokoll) geknackt wurde, sondern dass der Signaturpfad der Bridge durchbrochen wurde. Das alte Design presste die signierende Wallet, die Ereignisverarbeitung und die Netzwerkverbindung in einer einzigen operativen Route zusammen. Wenn der Schlüssel in falsche Hände gerät, ist der für den Angreifer erreichbare Bereich viel zu groß.
Interessant ist, dass der Schwerpunkt der Reparatur nicht einfach „eine andere Schlüsseldatei austauschen“ ist. Das neue Design trennt Ereignisempfang, Task-Persistenz, das Freigeben von Mitteln und einen dedizierten Signierer. Die Transaktionen werden über einen Zustandsautomaten mit Zuständen wie seen, submitted, completed, failed und stuck verwaltet. Die Hot-Wallet enthält nur den für den aktuellen Zeitraum benötigten Saldo; reicht das Geld nicht, wird pausiert. Danach ergänzt die Cold-Wallet manuell.
Ich fasse es mal mit einem einfachen Bild zusammen: Aus einem Geldtransporter voller Bargeld wird ein System mit mehreren Abteilen, Limits und Freigabe in Stufen.
Und AEGIS ist noch einmal etwas anderes: Die interne Prüfung hat insgesamt 39 Maßnahmen vorangetrieben, von denen 7 als „kritisch“ eingestuft wurden. Dazu gehören unter anderem VM-Isolation, Schutz vor Deserialisierungsangriffen, die Kopplung von Phoenix-Gebühren und Rückerstattungen sowie Ursachen wie BLS-Fälschungen. Offiziell heißt es, man habe bislang keine Belege gefunden, dass diese kritischen Probleme zuvor ausgenutzt wurden. Bridge-Vorfall und AEGIS dürfen nicht zu derselben Schwachstelle vermischt werden, und selbst wenn beides behoben wurde, heißt das nicht, dass das Risiko auf null fällt.
Daher ist meine Einschätzung: Nicht nur ein Konsensproblem zu sein, heißt nicht, dass es kein Sicherheitsproblem für Nutzer ist. Das öffentliche Recap ist zwar anerkennenswert, aber es ersetzt keine langfristige Stabilität und auch keine unabhängige Verifizierung.
Wenn ihr eine Kette bewertet, nehmt ihr dann Bridge und Betrieb (Ops) in den Protokoll-Sicherheitswert mit hinein?
#dusk $DUSK @Dusk
Die Realität ist viel komplizierter als die Parolen. Am 16. Januar 2026 erhielt ein Angreifer die Berechtigung für eine signierende Wallet, die für den Dusk- bis EVM-Bridge-Service verwendet wird.
Das offizielle Recap stellt klar: Das ist kein Konsensversagen und auch nicht, dass das Dusk-Basissystem (das zugrunde liegende Protokoll) geknackt wurde, sondern dass der Signaturpfad der Bridge durchbrochen wurde. Das alte Design presste die signierende Wallet, die Ereignisverarbeitung und die Netzwerkverbindung in einer einzigen operativen Route zusammen. Wenn der Schlüssel in falsche Hände gerät, ist der für den Angreifer erreichbare Bereich viel zu groß.
Interessant ist, dass der Schwerpunkt der Reparatur nicht einfach „eine andere Schlüsseldatei austauschen“ ist. Das neue Design trennt Ereignisempfang, Task-Persistenz, das Freigeben von Mitteln und einen dedizierten Signierer. Die Transaktionen werden über einen Zustandsautomaten mit Zuständen wie seen, submitted, completed, failed und stuck verwaltet. Die Hot-Wallet enthält nur den für den aktuellen Zeitraum benötigten Saldo; reicht das Geld nicht, wird pausiert. Danach ergänzt die Cold-Wallet manuell.
Ich fasse es mal mit einem einfachen Bild zusammen: Aus einem Geldtransporter voller Bargeld wird ein System mit mehreren Abteilen, Limits und Freigabe in Stufen.
Und AEGIS ist noch einmal etwas anderes: Die interne Prüfung hat insgesamt 39 Maßnahmen vorangetrieben, von denen 7 als „kritisch“ eingestuft wurden. Dazu gehören unter anderem VM-Isolation, Schutz vor Deserialisierungsangriffen, die Kopplung von Phoenix-Gebühren und Rückerstattungen sowie Ursachen wie BLS-Fälschungen. Offiziell heißt es, man habe bislang keine Belege gefunden, dass diese kritischen Probleme zuvor ausgenutzt wurden. Bridge-Vorfall und AEGIS dürfen nicht zu derselben Schwachstelle vermischt werden, und selbst wenn beides behoben wurde, heißt das nicht, dass das Risiko auf null fällt.
Daher ist meine Einschätzung: Nicht nur ein Konsensproblem zu sein, heißt nicht, dass es kein Sicherheitsproblem für Nutzer ist. Das öffentliche Recap ist zwar anerkennenswert, aber es ersetzt keine langfristige Stabilität und auch keine unabhängige Verifizierung.
Wenn ihr eine Kette bewertet, nehmt ihr dann Bridge und Betrieb (Ops) in den Protokoll-Sicherheitswert mit hinein?
#dusk $DUSK @Dusk