Le 16 janvier 2026, quelqu’un a compromis un portefeuille de signature lié au service de pont de Dusk Network et a commencé à siphonner des fonds. La façon dont un projet gère un moment comme celui-ci en dit plus long que n’importe quelle feuille de route.
D’après le post-mortem publié par Dusk lui-même, l’attaquant a obtenu l’accès au portefeuille qui gérait les événements de migration entre Dusk et une chaîne EVM à 21:28 UTC, en volant directement des DUSK et en en transférant une partie via le pont avant que l’équipe ne mette le service hors ligne à 23:12 UTC. Cette intervention a provoqué l’échec immédiat d’une dernière tentative de pont, bien plus importante. Les chiffres de Dusk indiquent qu’environ 10,9 millions de DUSK ont été volés sur plusieurs transactions, et qu’environ 1,9 million de ces fonds seulement a effectivement traversé le pont avant que la mise hors ligne ne coupe l’attaquant de la possibilité de déplacer le reste. Il ne s’agissait pas d’une défaillance de consensus ni d’une faille dans le protocole central de Dusk. C’était la compromission d’un seul chemin de signature, léger, qui combinait signature, gestion des événements et connectivité réseau dans une seule surface opérationnelle — un choix de conception fait au début pour la vitesse, qui a concentré trop de confiance en un seul endroit. Dusk a déposé une plainte auprès de la police, a conservé la trace des transactions sur les deux chaînes et a notifié immédiatement les échanges concernés.
La reconstruction qui a suivi n’a pas été un simple correctif. La signature a été entièrement séparée de la gestion des événements ; les transactions passent désormais par un cycle de vie explicite au lieu d’une logique de récupération ambiguë ; l’exposition des portefeuilles à chaud a été plafonnée avec des recharges de portefeuilles à froid réalisées manuellement ; et l’environnement hôte a été renforcé avec une isolation stricte des services.
Je pense que la leçon honnête ici n’a rien à voir avec la cryptographie et tout à voir avec la conception opérationnelle. La couche de règlement principale de Dusk n’a jamais cessé de produire correctement des blocs tout au long de l’incident, ce qui mérite d’être dit clairement plutôt que de laisser ces éléments se confondre.
Les détenteurs de DUSK ont ressenti ce risque directement, et c’est précisément pour cette raison que la refonte devait être aussi exhaustive.
@Dusk $DUSK #dusk
D’après le post-mortem publié par Dusk lui-même, l’attaquant a obtenu l’accès au portefeuille qui gérait les événements de migration entre Dusk et une chaîne EVM à 21:28 UTC, en volant directement des DUSK et en en transférant une partie via le pont avant que l’équipe ne mette le service hors ligne à 23:12 UTC. Cette intervention a provoqué l’échec immédiat d’une dernière tentative de pont, bien plus importante. Les chiffres de Dusk indiquent qu’environ 10,9 millions de DUSK ont été volés sur plusieurs transactions, et qu’environ 1,9 million de ces fonds seulement a effectivement traversé le pont avant que la mise hors ligne ne coupe l’attaquant de la possibilité de déplacer le reste. Il ne s’agissait pas d’une défaillance de consensus ni d’une faille dans le protocole central de Dusk. C’était la compromission d’un seul chemin de signature, léger, qui combinait signature, gestion des événements et connectivité réseau dans une seule surface opérationnelle — un choix de conception fait au début pour la vitesse, qui a concentré trop de confiance en un seul endroit. Dusk a déposé une plainte auprès de la police, a conservé la trace des transactions sur les deux chaînes et a notifié immédiatement les échanges concernés.
La reconstruction qui a suivi n’a pas été un simple correctif. La signature a été entièrement séparée de la gestion des événements ; les transactions passent désormais par un cycle de vie explicite au lieu d’une logique de récupération ambiguë ; l’exposition des portefeuilles à chaud a été plafonnée avec des recharges de portefeuilles à froid réalisées manuellement ; et l’environnement hôte a été renforcé avec une isolation stricte des services.
Je pense que la leçon honnête ici n’a rien à voir avec la cryptographie et tout à voir avec la conception opérationnelle. La couche de règlement principale de Dusk n’a jamais cessé de produire correctement des blocs tout au long de l’incident, ce qui mérite d’être dit clairement plutôt que de laisser ces éléments se confondre.
Les détenteurs de DUSK ont ressenti ce risque directement, et c’est précisément pour cette raison que la refonte devait être aussi exhaustive.
@Dusk $DUSK #dusk